naka
disconnected
docs/smart-contracts/security-model

Security Model

NAKA's security model is "no operator". The protocol's economic mechanics are immutable and pure. Every state transition is a function of on-chain inputs. This drastically reduces the attack surface relative to upgradeable, admin-controlled, or governance-managed protocols, but it does not reduce it to zero.

What Is Eliminated By Design

  • Upgrade risk. No proxy. No delegatecall-based upgrade path. Bytecode is final at deployment.
  • Admin key compromise. No admin role on any NAKA contract. There is nothing for an attacker to compromise that would give them control over reserves, parameters, or mint authority.
  • Treasury extraction. There is no treasury. The 0.30% fee is burned to 0xdEaD, not stored.
  • Pause / freeze risk. No pause function. The protocol cannot be halted by anyone.
  • Parameter governance attack. No setter for K, S, fee, or limits. No vote can change them.

What Remains

  • Smart-contract bug risk. The bytecode is final, which means a bug in the bytecode is also final. Independent audit reports will be linked from this page when available. Sepolia runs the same bytecode as mainnet for ongoing testing.
  • MEV / sandwich attacks. Every public-mempool transaction is exposed to reordering and frontrunning. Mitigations:
    • Hardcoded 2% slippage on minTokensOut / minEthOut from the frontend's swap forms (see BuyForm.tsx and SellForm.tsx).
    • Cooldown blocks between same-account buy and sell, mitigating sandwich-style flip exploits.
    • Per-buy cap of 5 ETH, capping how much value any single transaction can move the curve.
  • Frontend / DNS spoofing. A malicious clone of naka.exchange could intercept user signatures. Mitigations:
    • The contracts page documents canonical addresses; users should always check the token address against this page before signing.
    • The frontend is open-source; running it locally or from a verified hosted version eliminates the trust-in-frontend problem.
  • Wallet compromise. Standard Ethereum wallet hygiene applies.

What You Should Verify

For any interaction with NAKA, before signing anything:

  1. The token address resolves to the one on the addresses page.
  2. The router/hook addresses you're signing approvals for resolve to the ones on that page.
  3. Etherscan shows verified source on the contract.
  4. The wallet's transaction simulation matches what you intended to do.

Reporting

Vulnerabilities can be reported via the contact channels on @naka_exchange. A formal disclosure program will be announced there.