> For the complete documentation index, see [llms.txt](https://docs.tonadocash.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tonadocash.com/protocol-reference/tokenomics.md). # Tokenomics This is the docs-site summary. The authoritative parameter table and phasing live in [TOKENOMICS.md](https://github.com/tonadocash/monorepo/blob/main/TOKENOMICS.md) at the repo root. Read this for the overview, then go deep in the root doc when you need the per-decision rationale. ## What TONADO is for `$TONADO` is a TEP-74 jetton with four jobs. It captures protocol revenue. Every deposit pays a small fee (default 0.5% of denomination) into the `TreasuryRouter`. Governance periodically swaps that revenue to TONADO on STON.fi v2. Half the bought TONADO is burned and goes away permanently. The other half flows to veTONADO stakers as real yield. It runs governance. Locking TONADO in `veTONADO` for 1 day to 4 years gives you voting power proportional to `amount × lockDuration`. The `Governance` contract executes proposals weighted by that voting power behind a timelock. It subsidizes the anonymity set. A 30% supply allocation funds the `AmDistributor` contracts. Anyone with a commitment in a pool's merkle tree can claim a TONADO reward, without revealing which commitment. See [anonymity-mining.md](/protocol-reference/anonymity-mining.md). It bonds relayers. The `RelayerRegistry` requires relayers to lock TONADO to be listed in the dApp's relayer dropdown. Creates baseline demand from people who want to relay, independent of speculation. Total supply is 100,000,000 TONADO with 9 decimals. Fixed at genesis; no admin mint after the `AdminDisableMint` op fires. ## Distribution | Bucket | % | Tokens | Vesting | Contract | | --------------------------------- | ------- | -------------- | ---------------------------------------------------------- | --------------------------------------------- | | Anonymity-mining reserve | 30% | 30,000,000 | Released to AM Distributors over time, governance schedule | `LPLockVault` (AM-reserve instance) | | Protocol treasury | 20% | 20,000,000 | No lock; governance-controlled | `TreasuryVault` (multisig v1 → governance v2) | | **Team / contributors** | **20%** | **20,000,000** | **1-year cliff + 3-year linear vest** | `TeamVestVault` (one per beneficiary) | | Community / airdrop | 15% | 15,000,000 | Unlocked at TGE | `AirdropDistributor` (merkle-proof claim) | | LP-reserve (future CL migration) | 10% | 10,000,000 | 2-year cliff; governance can release earlier with quorum | `LPLockVault` (LP-reserve instance) | | LP bootstrap (STON.fi TONADO/TON) | 5% | 5,000,000 | 2-year hard lock, then released to governance | `LPLockVault` | LP bootstrap is intentionally small (5M TONADO paired with 10,000 TON at 0.002 TON/TONADO target). STON.fi v2 is a constant-product AMM, so the bootstrap needs paired TON. The 10% LP-reserve is held back to seed the STON.fi v3 concentrated-liquidity pool when it ships (target mid-2026). v3 allows a single-sided ask range, removing the need for paired TON. ## Protocol fees and how they benefit TONADO The deposit fee model is **deliberately uniform per pool**: every depositor to a 1-TON pool attaches the same total (`denomination + protocolFee + gas`), so the fee creates no per-user fingerprint on the pool boundary. This is the core privacy invariant - see [../how-it-works/commitments-and-nullifiers.md](/how-it-works/commitments-and-nullifiers.md). The flywheel: ``` user deposit → pool v2 sends fee to TreasuryRouter ↓ governance whitelists STON.fi swap recipe ↓ anyone calls TriggerSwap (cooldown-gated) ↓ STON.fi v2 → router → TONADO arrives at treasury wallet ↓ anyone calls Distribute (permissionless) ↓ 50% burned (TONADO master decrements totalSupply) 50% sent to veTONADO StakingRewards ↓ veTONADO stakers earn TONADO yield proportional to their locked voting power ``` Hard ceilings (committed to users via on-chain `MAX_*` constants): * `MAX_FEE_BPS = 200` (2% of denomination). Even governance cannot push the protocol fee above this without redeploying the pool. * `MAX_AM_RATE_BPS = 500` (5% of denomination per AM claim). * `MAX_BPS = 10000` for burn-split (0% = pure stake yield, 100% = pure deflation). These caps are trust-minimization commitments. Read more in [contracts-spec.md](/protocol-reference/contracts-spec.md). ## veTONADO (staking + voting) veTONADO is the on-chain staking contract. Lock TONADO for between 1 day and 4 years; receive voting power proportional to `amount × lockDuration / maxLockDuration`. The lock returns the TONADO at `lockEnd`; before that, the locker accrues TONADO rewards from the buyback distribute leg. Functionality: * **Lock** - send TONADO via TEP-74 transfer with a `LockPayload(duration)`. vp = `amount × lockDuration / maxLockSeconds`. * **IncreaseAmount** - add TONADO to an existing lock. vp recomputes with the lock's *remaining* duration. * **ExtendLock** - push `lockEnd` further out. vp recomputes. * **ClaimRewards** - pull accumulated TONADO rewards from the accumulator-pattern reward pool. * **Withdraw** - after `lockEnd`, return locked TONADO + any final accrued rewards. * **QueryVotingPower** - used by the `Governance` contract to verify a voter's vp asynchronously (TON's cross-contract reply pattern). The current model is **constant vp within a lock** (no continuous decay). A future revision can add Curve-style decay without breaking the storage layout. ## Governance The on-chain `Governance` contract is the destination of authority after the bootstrap multisig migrates ownership. Its job: execute proposals weighted by veTONADO voting power, behind a timelock. Lifecycle: 1. **Propose** - anyone submits an outbound message (dest, value, body). Proposal enters `ACTIVE` with `votingEnd = now + votingPeriod`. 2. **Vote** - voter sends `Vote(proposalId, for|against)`. Governance queries veTONADO for the voter's current vp; vp credited to the tally when the async reply arrives. 3. **Queue** - after `votingEnd`, anyone calls `Queue`. If `forVotes >= quorum && forVotes > againstVotes` → `QUEUED` with `timelockEnd = now + timelockSeconds`. Else → `REJECTED`. 4. **Execute** - after `timelockEnd`, anyone calls `Execute`. The queued outbound message fires. Governance owns: pool v2 contracts (revenue config), TreasuryRouter (buyback parameters, swap recipes), RelayerRegistry (bond params), AM Distributors (rate, root whitelist), and itself. The bootstrap path: deploy with `owner = multisig` for fast iteration; when the protocol is stable, send `AdminRenounce` from the multisig to transfer ownership to the governance contract itself (BURN\_ADDRESS in the contract's `owner` field). After that, all changes pass through propose → vote → queue → execute. ## Anonymity mining (one-paragraph version) The 30% reserve funds the `AmDistributor` contracts - one per pool denomination. Anyone with a commitment in a TONado pool's merkle tree can claim a TONADO reward by submitting a zero-knowledge proof. The proof uses a domain-separated nullifier that's distinct from the withdraw nullifier - so claiming AM does NOT prevent a future withdraw of the same deposit and vice versa. Full design in [anonymity-mining.md](/protocol-reference/anonymity-mining.md). ## Where to read next * [TOKENOMICS.md](https://github.com/tonadocash/monorepo/blob/main/TOKENOMICS.md) - authoritative parameter table + phasing * [anonymity-mining.md](/protocol-reference/anonymity-mining.md) - AM circuit + claim flow * [governance.md](/protocol-reference/governance.md) - proposal lifecycle in detail * [treasury-router.md](/protocol-reference/treasury-router.md) - buyback flywheel mechanics * [contracts-spec.md](/protocol-reference/contracts-spec.md) - on-chain contract surface * [../operations/pool-deployment.md](/operations/pool-deployment.md) - operator runbook for deploying pools + bootstrapping the buyback