A tokenomics audit of a live token should answer one question: in a bad but plausible year, does the supply arriving outrun the demand the project can show, and does any mechanism break? The question is not academic. Tokenomist counted about $97.4 billion in token unlocks during 2025 alone.
Who decides this
The foundation council and the CFO own the audit. The council is accountable for the token’s rules and for any change that follows from the findings, since changes to a live token’s rules go back through governance. The CFO is accountable for the inputs: revenue, treasury, market-maker terms and the real unlock calendar. The auditor should report to both, and should be independent of whoever designed or deployed the model.
Should the audit start from the model or from the chain?
Start from the chain. A live token has been running for months or years, and what it actually does has drifted from the model in the token paper. The audit has to rebuild the current state before it can test anything.
That means four reconciliations. First, every allocation bucket against the wallet or contract that holds it. Second, every vesting schedule as deployed, not as published. Third, every emission source, including staking rewards, liquidity incentives and grants, with the person who can change each one. Fourth, every off-paper commitment: market-maker loans, exchange programmes, partner allocations.
The output is a current supply calendar for the next 24 to 36 months, by recipient and by month. If the team cannot produce one, that is the first finding. A pre-launch review starts from a clean design. Our guide to what an outside adviser checks before TGE covers that earlier stage. A live audit starts from whatever the token has become.
Which scenarios should a token model stress test run?
Run a small number of scenarios that a council could actually face, each with a stated trigger and a stated test. We use five. The table sets out what each one changes and what it is designed to reveal.
| Scenario | What changes in the model | What it reveals | Inputs the CFO must supply |
|---|---|---|---|
| Usage falls by half for two quarters | Fee revenue, buyback spend, real staking yield | Whether value accrual depends on a bull market | Revenue by source, 24 months of history |
| The largest unlock month arrives in a weak market | Sell-side supply against current depth | Whether the calendar can be absorbed | Unlock calendar by recipient, order-book depth |
| A market maker exits or returns its loan | Liquidity and float | How much of visible depth is rented | Market-maker agreements and loan terms |
| Price falls 70% | Collateral, staking, any reflexive mechanism | Feedback loops that turn a fall into a run | Mechanism specifications, collateral data |
| A holder or coalition buys governance | Voting power and treasury control | Capture paths and the cost of an attack | Holder distribution, delegation, quorum rules |
The 70% figure is our test level, not a market standard. Pick a level the council regards as plausible, and keep it fixed between audits so results are comparable.
The scope used by specialist auditors overlaps with this list. ImmuneBytes, for example, describes a tokenomics audit covering emission schedules, vesting cliffs and liquidity shocks, governance capture paths, bribeability and parameter sensitivity. Its listed deliverables include failure scenarios and parameter danger zones.
Run the scenarios in combination as well as alone. Bad events arrive together. Usage falls, the price drops, a market maker pulls back and a large unlock lands in the same quarter. A model that survives each shock separately can still fail when two of them coincide. We would always run at least one combined case: the weakest revenue quarter in the token’s history, repeated, with the largest scheduled unlock landing inside it.
Write down each assumption next to the result it produced. When the council asks why a scenario failed, the answer should be a line in the model, not a recollection.
Which numbers should the audit report?
Report a small set of ratios the council can track every quarter, not a single score. Three matter most.
The first is a coverage ratio: the value of tokens leaving circulation through buybacks, burns or long locks, divided by the value of newly unlocked and emitted supply. CryptoSlate’s January 2026 analysis uses this ratio to judge buybacks. Above 1, net supply shrinks. Below 1, the sinks only slow dilution. We apply it to every sink, not only buybacks.
The second is the unlock calendar weighted by recipient. Keyrock’s study of more than 16,000 unlocks, as reported by BeInCrypto, found 90% created negative price pressure. Team unlocks were the most damaging, with average drops of up to 25%. Larger unlocks produced drops up to 2.4 times sharper, and declines often began before the unlock date. A month with a large team unlock should carry a higher weight than its raw size suggests.
The third is the insider share of upcoming supply. Tokenomist found insiders received about 19% of 2025 unlocks, with most of the rest coming from community, ecosystem, treasury, rewards and liquidity allocations. The figure for a single token can be far higher, and it is the number we would put in front of the council first.
Spreadsheet or simulation?
Use a scenario spreadsheet for every live token, and add agent-based simulation only where the model has feedback loops. Most supply and demand questions are arithmetic. A spreadsheet that every council member can read is worth more than a model only the auditor understands.
Simulation earns its cost where behaviour drives outcomes: staking that responds to yield, collateral that responds to price, incentives that respond to other incentives. Auditors use open tools such as cadCAD for system simulation and Mesa for agent-based modelling, according to ImmuneBytes. A worked example from Space and Time, using a hypothetical game token, modelled four types of holder. Its baseline showed a drop of about 80% after launch and a break-even month of 15, improving to month 10 when the user base tripled.
That example is illustrative, not a forecast. Its value is the method: separate the parameters the protocol controls, such as fees, burns and vesting, from the behaviour it cannot control, and test both.
The case for simulating reflexive designs is well documented. An NBER working paper on the Terra collapse describes about $50 billion in value lost over three days in May 2022. The authors found the system’s complexity made it hard, even for insiders, to see risk building. A live audit exists to make that risk visible while there is time to act.
What should the council do with the findings?
Sort every finding into one of three actions: fix through governance, disclose, or monitor with a trigger. A finding with no action attached is not useful to the council.
Fixes to a live token are expensive. They need proposals, votes and often contract changes, and holders read every change as a signal. Our guide to fixing the token model after launch covers that process. Disclosure is cheaper and often enough: a published, accurate supply calendar removes surprise even when it cannot remove supply. Monitoring needs a named owner and a threshold, such as a coverage ratio that triggers a review if it falls below a set level.
Decide in advance who sees the report. The council and the CFO need the full version. Holders need the supply calendar and the actions taken, not the attack paths. If an exchange or investor asks for evidence of an audit, a shareable summary saves weeks.
Re-run the audit once a year, and whenever a parameter that moves supply or demand changes.
What goes wrong: tokenomics the contractor rewrote
The council approved a model at launch. Over the following year, a dozen people changed it without ever calling it a change.
A contractor raised a staking reward rate to defend total value locked. A grants team paid out from the ecosystem wallet faster than the schedule. A market-maker loan was renewed on new terms. A new chain deployment minted a bridged supply that no one added to the calendar. Each change was reasonable. None went back to the council, and the token paper still describes the original model.
An audit run on that paper passes. An audit run on the chain finds a different token. The defence is the order of work: rebuild the live state first, then stress-test it, and make any future change to a supply parameter a written council decision.
How Alcyone approaches it
Alcyone starts a live-token engagement with the current state, not the original design. As set out in how an Alcyone engagement runs, the first step after an intro call is a fixed-scope, fixed-fee assessment, with the fee credited against further work. Where the findings call for change, a plan follows over three to six weeks, with a named owner for every part. After that, the same partners report quarterly, so the stress test becomes a recurring check rather than a one-off document. Clients are under no obligation to use TrustSwap products.