Upgradeability
NAKA contracts are non-upgradeable. There is no proxy, no upgrade path, no migration script, and no admin role with authority to change bytecode or parameters.
Definitive Answers
| Question | Answer |
|---|---|
| Is a proxy used? | No. All NAKA contracts are deployed as direct bytecode. |
| Is there an admin key? | No. No onlyOwner, no Ownable, no role grants. |
| Is there a timelock? | No. Nothing to delay because nothing is changeable. |
| Is there an emergency pause? | No. No pause modifier on any state-changing function. |
| Can the deployer change anything post-deploy? | No. Deployer EOA has no privileged role on any contract. |
| Can mint authority be reassigned? | No. MinterLocked is emitted at deployment and the lock flag is one-way. |
What This Means in Practice
- The bytecode you read on Etherscan today is the bytecode that will run forever.
- A bug in the deployed code cannot be patched in-place. The mitigation path for any discovered issue is independent. For example, a community-deployed alternative or off-chain integrations that adapt around it. The original contract continues to do exactly what it was deployed to do.
- Nobody can drain reserves, pause buys/sells, change the curve parameters, or mint outside the curve.
Why No Upgradeability
NAKA's design treats the curve itself as the protocol. Adding upgradeability means adding off-chain trust (who decides? who controls the timelock? who recovers if the timelock-controller key is compromised?). That trust is precisely what the no-operator model is meant to remove.
How to Independently Confirm
For each of the four addresses on the addresses page:
- Open the address on Etherscan.
- Confirm the "Contract" tab shows verified source (not bytecode-only).
- Search the source for
delegatecall,upgradeTo,Ownable,AccessControl. Should not be present in NAKA contracts (the standard Uniswap V4 PoolManager is excluded; that is canonical infrastructure). - Confirm there is no proxy admin event in the contract's event history.