The spreadsheet always balances. Supply curves up smoothly, emissions taper on schedule, the treasury lasts four years, and the chart of circulating supply is a tasteful gradient. Then the token launches, and within a week the emissions are being farmed by a handful of addresses, the vesting cliff dumps on a market with no depth, and the "community incentive" pool is funding a wash-trading operation that exists only to harvest it.
The spreadsheet was not wrong. It was answering a different question. A spreadsheet models a token under the assumption that participants behave as designed. Production tokenomics meets participants who behave as incentivized, and the gap between those two is where projects die. The token model is not a financial document. It is a piece of software, deployed adversarially, with money on the line. It deserves the same engineering rigor as any other contract that holds value — and almost never gets it.
This is the decision document we walk clients through before any supply mechanic becomes immutable on-chain.
Decision one: what is actually enforced by code versus by promise
The first cut is brutal and clarifying. For every line in the token model, ask: is this enforced by the contract, or is it a promise the team intends to keep?
Max supply enforced by a cap in the mint function is code. "We won't mint more" stated in a blog post is a promise. Vesting enforced by a contract that releases on a schedule no one can override is code. "Team tokens are locked for two years" held in a multisig the team controls is a promise. The distinction is not pedantic. Promises are renegotiated under pressure, and a token's worst day is exactly when the team is under the most pressure to break one.
Our default: anything that protects holders from the team should be code, not promise. Vesting, emission caps, and treasury controls that a holder is relying on belong in contracts with no admin override, or behind a timelock long enough that holders can exit before a change takes effect. If the team can change the supply schedule with a transaction nobody sees coming, the supply schedule is decorative.
This decision alone reshapes most token models, because a lot of what looks like tokenomics turns out to be promises wearing the costume of mechanism.
Decision two: which incentives create a farm
Every emission is a bounty. The question is what behavior it pays for, and whether that behavior can be faked more cheaply than it can be performed.
Liquidity incentives pay people to provide liquidity. They also pay people to provide liquidity for exactly as long as the emissions exceed the fees, then leave — mercenary capital that was never a user. Worse, they pay people to provide liquidity to themselves, looping the same capital to harvest emissions while contributing nothing. If the reward for an action exceeds the cost of faking that action, the action gets faked at scale. This is not a moral failing of crypto users. It is the system working exactly as specified.
The engineering question for every incentive is: what is the cheapest way to capture this reward without doing the thing it is meant to reward? If you cannot answer it, an adversary will answer it for you, in production, with your treasury. We walk through each emission and try to break it before it ships. Referral rewards farmed with sybil wallets. Governance rewards captured by borrowing tokens to vote and returning them. Staking rewards collected by capital that would have staked anyway, so the emission bought nothing. The pattern is always the same: the reward pays for a signal of the behavior, and the signal is cheaper to forge than the behavior is to perform.
Decision three: distribution and vesting as adversarial schedules
Distribution decides who holds the token on day one and who can sell on day thirty. Both matter more than the total supply, and both are where engineering meets game theory.
A cliff is a coordination event for sellers. If the team, the investors, and the advisors all unlock on the same date, that date is a scheduled sell-off, and the market knows it is coming. Spreading unlocks, using linear vesting instead of cliffs, and staggering parties across different schedules is not generosity — it is removing a predictable adversarial event from the calendar. The vesting contract is where this lives, and it has to be the contract, not a multisig that releases manually, because a manually released lock is a promise again.
Initial distribution determines concentration. If three addresses hold half the supply after the sale, the float is fiction and the price is whatever those three decide it is. We model the holder distribution at launch and at each unlock, not as a chart for the deck, but as an input to: what is the largest coordinated sell this design makes possible, and can the market for this token absorb it. If the answer is no, the design has a built-in crisis on a known date, and we change the design before it is immutable.
Decision four: simulate before it is immutable
This is the step almost every project skips and the one that separates a token model from a token system. Supply mechanics are code. Code gets tested. There is no reason a contract that controls a nine-figure market cap should reach mainnet without ever having been run against adversarial behavior, and yet that is the norm.
We model the token economy as a simulation with agents that act on incentives rather than on the design's wishes. Mercenary liquidity that chases the highest yield and leaves. Sybil farmers that split capital across wallets to multiply rewards. Whales that time exits to unlock dates. Borrowers that rent governance weight for a single vote. Then we run the supply mechanics — emissions, vesting, sinks, sources — forward through time and watch what the agents do to the circulating supply, the treasury runway, and the price floor.
The simulation does not predict the price. It is not a forecast. It is a stress test that surfaces the failure modes the spreadsheet hides: the emission that gets fully farmed by sybils, the vesting cliff that overwhelms the float, the treasury that empties two years early because the incentive cost was modeled as designed instead of as gamed. ./chain simulate --adversarial is the difference between finding these in a model and finding them in production with real money leaving.
// Vesting that is code, not a promise: no admin override,
// linear release, cliff enforced on-chain.
function claimable(address account) public view returns (uint256) {
Grant memory g = grants[account];
if (block.timestamp < g.start + g.cliff) return 0;
uint256 elapsed = block.timestamp - g.start;
if (elapsed >= g.duration) return g.total - g.claimed;
return (g.total * elapsed) / g.duration - g.claimed;
}
The contract above has no function for the team to accelerate, pause, or revoke. That absence is the feature. A holder relying on this schedule can verify it will hold regardless of how much the team later wishes it would not.
The incentive failure modes that repeat
Across token launches, the same handful of failures recur, and all of them are engineering failures wearing economic clothes.
Emissions that exceed organic demand inflate supply faster than usage grows, and the price discovers that gap. Rewards detached from real activity fund wash trading and sybil farming, so the treasury pays for metrics instead of users. Synchronized unlocks create scheduled sell-offs. Concentrated initial distribution means a handful of holders set the price. Governance weight that can be borrowed means governance can be captured for the cost of a flash loan. And the quiet killer: a treasury whose runway was modeled on incentive costs as designed rather than as farmed, which empties years before plan.
None of these are surprises after the fact. All of them are findable before the contract is immutable, by anyone willing to model the participants as adversaries rather than as customers.
What fixed looks like
A token model we would sign off on draws a hard line between what the code enforces and what the team promises, and moves everything holders depend on to the code side. Vesting is a contract with no override. Emission caps are enforced in the mint path. Every incentive has a documented answer to "what is the cheapest way to farm this," and the ones without a good answer were cut. Distribution and unlocks are staggered so no single date is a coordinated sell-off. And the whole system has been run forward through an adversarial simulation before a line of it became immutable.
The launch is uneventful in the good way. The emissions go where they were meant to, the unlocks do not crater the float, and the treasury runway matches the plan because the plan accounted for adversaries, not just users.
This is for you if
You are launching a token that will hold real economic value, and a broken incentive or a mistimed unlock would be measured in seven figures of market cap and a credibility hit you do not recover from. You want the supply mechanics engineered and stress-tested as code before they are immutable on-chain. The scope for proper tokenomics engineering — mechanism design review, on-chain vesting and emission contracts, and adversarial simulation — runs $100k and up depending on the complexity of the incentive system.
This is not for you if you are launching a memecoin where the tokenomics are the joke and the supply mechanic is "there is a lot of it." That is a different exercise and it does not need an engineer.