A tokenomics audit is an independent review of a token's economic model: supply and emissions, allocations and vesting, incentive loops, fee flows, governance thresholds and treasury runway. It tests each of those on its own and then against each other, and it delivers a severity rated risk register with quantified exposure and a ranked set of fixes. It is a different review from a smart contract audit, which checks whether code does what it says. This one checks whether what it says is a good idea.
A contract can be free of bugs and still run a model in which the rational move for every participant is to leave at the same moment. Code review cannot see that, because nothing is broken.
Scroll to see the full diagram
The boundary with a smart contract audit
The two reviews answer different questions and neither substitutes for the other. A practitioner guide published in July 2026 states the split cleanly: a smart contract code audit verifies that the protocol's code executes its stated logic correctly, and cannot evaluate whether that logic creates dangerous economic incentives.1
Look at how a leading code auditor describes its own work and the scope is visible in the metrics it chooses. OpenZeppelin reports more than $110 billion in total value locked secured, more than one million lines of code reviewed, and more than 700 critical and high severity vulnerabilities uncovered.2 Those are code quantities. Nothing in that list is a claim about whether an emission schedule is survivable.
The first question we ask in an economic review is the one that decides everything downstream: does this model run on the business or on emissions? A design where participation only pays while new tokens are being printed has a fixed expiry date, and no amount of contract quality changes it. The token is infrastructure. The revenue underneath it is the engine, and the audit exists to test whether the engine is actually attached.
Five questions a code review never asks
The same July 2026 guide enumerates what economic security review covers, and the list is a fair statement of scope. Whether emission schedules create inflationary cliffs that destroy collateral value. Whether incentive structures leave participants with dominant strategies misaligned with protocol health. Whether governance quorum thresholds are calibrated so that capturing voting control costs more than what can be extracted. Whether oracle price dependent functions assume enough liquidity to make manipulation unprofitable. And whether bribery markets for governance votes are economically viable at current prices.1
Every one of those is a mechanism design question rather than a correctness question, and every one of them has a number attached to it. They get answered with simulation and stress testing, not with a reading of the contract.
In our work the cross component tests find more than the single component tests do. An emission rate that looks survivable in isolation becomes lethal when it sits next to a short cliff on a large insider allocation, and a governance threshold that looks conservative becomes cheap the moment the token is listed as collateral somewhere with deep borrow liquidity. Auditing the parts separately and stopping there is the most common way a review misses the thing that eventually happens.
Three exploits, and which review would have caught each
Beanstalk is the clearest economic case. Its own post mortem records that the protocol was attacked on 17 April 2022 at roughly 12:24pm UTC, resulting in a theft of about $77 million in non-Beanstalk user assets, and that the perpetrator used a flash loan to exploit the protocol's governance mechanism.3 The contract executed exactly as written. Voting power could be rented for the duration of a single transaction, and the parameter set never priced that possibility.
Mango Markets is the collateral valuation case. The SEC states that beginning on 11 October 2022, Avraham Eisenberg engaged in a scheme to steal approximately $116 million of crypto assets by manipulating the price of the MNGO perpetual futures contract to inflate the value of his collateral, then borrowing against it and withdrawing.4 No bug. A pricing function reading a real market that was too thin to defend.
Then the case that runs the other way. On Saturday 21 November 2020 an attacker drained 19 million DAI from Pickle Finance's pDAI jar, in an incident the security researchers who documented it named Evil Jar.5 That was a code level validation flaw. An economic model review would not have found it, and saying so is the point: the argument here is not that economic review is the important one, it is that the two reviews cover disjoint failure sets and teams routinely buy one and assume the other.
Worked example: what does capture actually cost
Take an illustrative design, with numbers chosen to show the arithmetic rather than to describe any real project. Circulating supply of 400 million tokens at $0.20, a treasury holding $40 million, governance quorum at 35% of circulating supply, and votes counted from a snapshot taken when the proposal executes. Quorum is 140 million tokens, a notional $28 million of buying against a $40 million prize.
A code audit sees nothing wrong, because nothing is wrong at the code level. An economic review asks a different question: does the attacker have to own $28 million, or borrow it? Where voting power is read at execution time, the capital can be borrowed and returned inside one transaction, which drops the real cost from $28 million to a fee, and Beanstalk is the documented precedent for exactly that.3
Now change two parameters and nothing else. Count votes from a snapshot taken before the proposal was published, and put a time lock between a passed vote and its execution. The attacker now has to hold the tokens in advance, in public, and wait through the delay while everyone watches. Same treasury, same quorum, and the attack has gone from a fee to a multi week campaign with a warning attached. That is what the review is buying: not a verdict, a change to the arithmetic.
Severity, and what residual risk means in the report
The output that matters is a register, not a rating. Each finding carries what breaks, under what conditions, how much is exposed if it breaks, and what the fix costs. Ranking those by exposure rather than by ease of fixing is the whole discipline, because the cheap findings always get closed first when nobody is enforcing an order.
Findings that are accepted rather than fixed do not disappear. EY's token due diligence framework treats residual risk as what remains after mitigants are in place, to be evaluated against the risk appetite of whoever is deciding.6 In practice that means every accepted risk in a register should name three things: who owns it, what signal would show it turning live, and what the trigger is for acting. Without those, acceptance is just deferral with better paperwork.
Governance permissions belong in the register too, and across the models we review they are the most under reported part of the design. Mature lending protocols publish named administrative roles that can pause markets, list assets and change risk parameters after launch. Every one of those is a capability that can be used correctly, used badly, or stolen. A review that documents what the contract does but not who is allowed to change it has left out the largest single variable.
What the review cannot do
It does not prevent exploits. It prices known failure modes with the information available on the day it is written, which is why the exit condition of an audit should be a monitoring plan rather than a certificate. Models drift, liquidity moves, and a parameter that was safe at one market depth is not safe at another.
It is also not a compliance product. A tokenomics audit does not determine whether a token is a security in any jurisdiction, does not make a design compliant with any regulation, and is not a legal opinion. Those calls belong to counsel, on the specific facts and the specific jurisdiction. What the review can do is document the mechanism clearly enough that counsel's analysis starts from something accurate.
And it is not a substitute for code review. Evil Jar is the reminder.5 Commission both, sequence them so the economic review lands before the parameters are frozen in a contract, and treat a disagreement between the two reports as information rather than an inconvenience.
When to run it
Before the numbers become promises. Allocation percentages, vesting terms, emission curves and governance thresholds are close to costless to change in a model and expensive to change once they sit in an investor agreement, a public token document or a deployed contract. A review that arrives after the raise can only tell a team which commitments were mistakes.
Two other moments justify a fresh pass. The first is any material mechanism change, since a fee switch, a new emission source or a new collateral integration invalidates the assumptions the earlier register was built on. The second is the point where an outside party is about to run their own diligence, whether that is an investor, an exchange or a lending market listing committee. Finding the problem in your own report is a different conversation from having it found for you.
Nothing here is advice on buying, selling or holding any asset, and no review makes a design safe. It makes the failure modes explicit, priced and ranked, so that the ones a team decides to live with are decisions rather than surprises.
Common questions
What is a tokenomics audit?
It is an independent review of a token's economic model rather than its code, covering supply and emissions, allocations and vesting, incentive loops, fee flows, governance thresholds and treasury runway. The output is a severity ranked risk register with quantified exposure and prioritised fixes. The questions it asks are mechanism design questions, such as whether capturing governance costs more than what can be extracted from it.1
How is a tokenomics audit different from a smart contract audit?
A smart contract audit verifies that code executes its stated logic correctly and cannot evaluate whether that logic creates dangerous economic incentives.1 A tokenomics audit tests the incentives themselves. Beanstalk lost about $77 million to a flash loan governance exploit in which the contract ran exactly as written.3 Pickle Finance lost 19 million DAI to a code level validation flaw no economic model would have caught.5 Different failure sets.
What does a tokenomics audit cover?
Emission schedules and whether they create cliffs that destroy collateral value, incentive structures and whether dominant strategies stay aligned with protocol health, governance quorum calibration against the value controllable, oracle dependent pricing against real liquidity depth, and the economics of vote bribery markets.1 A serious review also documents admin capabilities, because named roles that can change risk parameters after launch are part of the economic model.
When should a project run a tokenomics audit?
Before allocation percentages, vesting terms and governance thresholds are written into investor agreements or public documents, because those are cheap to change in a model and expensive to change afterwards. Two later triggers matter as well: any material mechanism change, such as a fee switch or a new collateral integration, and the point just before an investor, exchange or lending market runs its own diligence.
Does a tokenomics audit prevent exploits?
No, and any review promising that is overselling. It prices known failure modes using the information available on the day it is written, then ranks them by exposure. Market depth, liquidity and integrations all move afterwards, which is why the correct exit from an audit is a monitoring plan with named triggers rather than a certificate. Accepted risk stays risk, evaluated against the risk appetite of whoever accepted it.6
See Tokenomics Audit Services for how this applies in practice.
Sources
- DeFi Tokenomics and Economic Security Audit Guide 2026
smartcontractaudit.com, 2026
Published 13 July 2026. States that a code audit cannot evaluate whether logic creates dangerous economic incentives, and enumerates the five economic security scope items: emission cliffs, dominant strategy misalignment, quorum calibration against extractable value, oracle dependence against liquidity depth, and vote bribery market economics. - Smart Contract Security Audits
OpenZeppelin, 2026
Self reported scope metrics read 3 August 2026: more than $110 billion total value locked secured, more than one million lines of code reviewed, more than 700 critical and high severity vulnerabilities uncovered. Cited as evidence of what a code centric review measures. - Beanstalk Governance Exploit
Beanstalk Farms, 2022
The protocol's own post mortem: attacked on 17 April 2022 at roughly 12:24pm UTC, theft of about $77 million in non-Beanstalk user assets, carried out with a flash loan against the governance mechanism. Widely circulated secondary figures of about $182 million measure total value destroyed rather than user assets stolen. - SEC Charges Avraham Eisenberg with Manipulating Mango Markets' Governance Token to Steal $116 Million of Crypto Assets (press release 2023-13)
U.S. Securities and Exchange Commission, 2023
States that beginning 11 October 2022 the defendant stole approximately $116 million by manipulating the MNGO perpetual futures price to inflate collateral value and borrowing against it. The regulator's figure, not the rounder $110 million reported secondhand. - evil-jar: Pickle Finance pDAI exploit post mortem
banteg, samczsun, emilianobonassi and lehnberg (GitHub), 2020
Technical post mortem recording that on Saturday 21 November 2020 an attacker drained 19 million DAI from Pickle Finance's pDAI jar. Cited as the code level failure that economic review would not catch. - Token due diligence: a structured approach to evaluate digital asset risk
EY, 2024
February 2024. Frames residual risk as what remains after mitigants such as audits and controls, to be evaluated against the risk appetite of the party accepting it.
Last reviewed 2026-08
Know the terms but not sure how they apply to your project? That is what an engagement is for. We design, document, and stress-test the whole token economy inside the Tokenomics Data Room.
100+ projects advised. Complete tokenomics in 4 to 6 weeks.