docs/developers/faq-dev

Developer FAQ

Is there an official API?

There are HTTP endpoints exposed by the frontend at naka.exchange for indexer-style queries (/api/indexer/stats, /api/indexer/trades, /api/indexer/holders, /api/indexer/flows). These are convenience layers on top of eth_getLogs. The full architecture is documented in the indexer guide.

For production integrations, query the contract directly. The only canonical state lives on-chain.

Can supply exceed `K`?

No. Asymptotically, minted(eth) → K as eth → ∞, but it never reaches K. In practice the self-deprecation flag flips at 99% of K and minting permanently halts there. Total supply (including the dead-burn portion) approaches but does not exceed K.

Is minting always open?

No. Two conditions can close minting:

The selfDeprecated flag is set (after 99% of cap is minted).
ethIn > MAX_BUY_WEI (per-buy cap of 5 ETH). This is per-call, not a global limit.
ethIn < MIN_TX_AMOUNT (1 gwei minimum).

Once selfDeprecated == true, the buy path reverts permanently for any caller, any input.

Where can I find the ABIs?

In the frontend repo: lib/abis/NakaToken.json, lib/abis/NakaHook.json, lib/abis/NakaSwapRouter.json. For production use, pull them from a tagged GitHub release rather than copying from a running frontend, so you get the exact compiler metadata.

How do I quote a buy off-chain?

Use the JS helpers in lib/curve.ts:

import { supplyAt, priceAt } from "@/lib/curve";
const tokensFor = supplyAt(currentEth + ethIn) - supplyAt(currentEth);
const userTokens = tokensFor * 0.997;  // post 30 bps fee

Or call the on-chain view function directly. The hook exposes estimatedBuyOut(ethIn) and estimatedSellOut(tokensIn) for accurate post-fee, post-cap estimation.

How do I quote a sell?

Same, but in the inverse direction. The on-chain estimatedSellOut(tokensIn) is the most accurate path because it accounts for current reserve state.

Why does the first sell from a wallet require two transactions?

ERC-20 approve model. The router needs allowance to pull NAKA from the user's wallet. The frontend detects the missing allowance and shows approve naka first, then sell naka afterward. Subsequent sells from the same wallet skip approval if the prior one wasn't fully consumed.

What happens if the reserve runs out?

The reserve cannot run out under normal operation, because every wei withdrawn corresponds to a curve sell at curve rates and the curve guarantees solvency by construction. If the reserve were somehow drained (e.g., through a bug), sells would revert until the balance recovers via new buys.

Can I deploy NAKA on another chain?

The contracts compile and deploy on any EVM chain that supports Uniswap V4. The canonical NAKA, however, is mainnet Ethereum. Cross-chain deployments are forks of the protocol with separate token supplies. They are not the same NAKA.

Use viem's watchContractEvent or wagmi's useWatchContractEvent:

useWatchContractEvent({
  address: contracts.hook,
  abi: nakaHookAbi,
  eventName: "Buy",
  onLogs(logs) { /* ... */ },
});

Or, for backend services, use a websocket RPC and eth_subscribe with logs topic.

Is there a bug bounty?

A formal bug-bounty program will be announced on @naka_exchange. In the meantime, report any issue you find via the same channel.

Can I list NAKA on my DEX / aggregator?

Yes. The token is a standard ERC-20 with no transfer hooks or fees on transfer. The bonding curve is exposed via the hook → router contract pair documented in the contracts page. Aggregators can wrap the router as a standard swap source.

How do I run the frontend locally?

Clone the repo, install deps with Node 20+, and npm run dev. The Sepolia RPC is configurable via NEXT_PUBLIC_SEPOLIA_RPC in .env. The default falls back to a public RPC, which works for read calls but is rate-limited.