A revenue model, in a token context, states who pays, for what, how often, how much of that the protocol keeps, and how any of it reaches the token. The last clause is the one that gets skipped. A protocol can produce real fees for years while none of them accrue to holders, because collecting revenue and routing it to the token are separate mechanisms and usually only the first is built. In a simulation the revenue model is the deterministic base case that everything stochastic is run against.
If you cannot name the contract function or the governance action that moves a fee from the protocol to the token, then the protocol has a revenue model and the token does not. Those are different assets and only one of them is being valued in most decks.
Who pays, for what, and how often
Write each stream out separately with its own driver. A swap fee is driven by volume. A subscription is driven by seat count and renewal rate. A sequencer margin is driven by block space demand. A licence is a step function that moves when a deal closes. Blending them into one take rate destroys exactly the information a model needs, because the streams have different volatilities, different customers and different reasons to disappear.
The test is whether you can name the payer. Not the category, the payer. If every stream traces to someone outside the system paying for something they wanted, the model describes a business. If the main stream traces to new token buyers, it describes a transfer between participants, and no amount of mechanism design converts one into the other. That is why we start an engagement with the revenue model rather than the token.
Revenue collected is not revenue accrued
Uniswap is the most documented version of this gap. Swap fees flow to liquidity providers, while the protocol-level fee switch, and therefore any flow to UNI holders, has been a governance decision rather than an automatic one. The forum thread Making Protocol Fees Operational is the on-the-record version of that debate.1
The UNIfication proposal from Uniswap Labs sets out the other side of the gap, routing protocol fees and layer 2 sequencer fees into UNI burns so that collected revenue reaches the token by mechanism rather than by vote.2 Whatever you make of that specific design, the structure of the problem is general. Revenue exists at the protocol. Accrual is a second thing someone has to build, and every month it stays unbuilt is a month the token's value rests on the expectation that it eventually will be.
Gross fees, protocol revenue, and what a tracker is counting
The word revenue is used for at least three different quantities in this market: total fees paid by users, the share retained by the protocol after supply-side participants are paid, and the share that reaches token holders. Named data providers publish protocol revenue series, and each applies its own methodology to that split.3 A revenue figure quoted without saying which of the three it is has told you nothing.
Define all three in your own model and carry them separately through the horizon. The gap between line one and line three is the number a founder should be able to state from memory, because it is where the argument about the token's worth actually lives.
What the simulation needs from it
The revenue model is the deterministic spine. Monte Carlo does not replace it, it perturbs it: each stream gets a range around its driver, the model reruns thousands of times, and the output shows how often the economy covers its obligations. If the revenue model is one blended rate, the simulation inherits that and produces a confident distribution around a number with no structure underneath.
Two requirements follow. Every stream needs a unit of demand you could measure next quarter, not an addressable market percentage, because a parameter you cannot observe is one you cannot manage. And every stream needs a stated elasticity, since the fee rate is a design variable and raising it does not raise revenue proportionally where a user can route around you in one transaction.
The token does not replace the business
This is the firm's position and it shapes every model we build. Tokenomics enhances value creation, it does not manufacture it. A well-designed sink attached to a protocol nobody pays for is a well-designed sink for nothing, and the mechanism debate around it is a way of avoiding the harder conversation.
So the sequence is fixed. Establish who pays and for what. Establish how much the protocol keeps. Then design the accrual path and the sinks. Reversing that order produces the most common document we get asked to review: a detailed token mechanism sitting on a revenue line that was assumed rather than earned.
Common questions
What is a token revenue model?
It is the written statement of who pays the protocol, for what, how often, how much the protocol retains, and how any of that reaches the token. The final step is a separate mechanism from the first four. Many protocols collect real fees while nothing flows to holders, because routing revenue to a token requires a contract or a governance decision that has not been made yet.
What is the difference between protocol revenue and value accrual to the token?
Protocol revenue is what the system keeps after paying supply-side participants such as liquidity providers or node operators. Value accrual is the portion that reaches token holders through a burn, a buyback, a fee share or a claim. The two are independent. Uniswap's fee switch debate is the documented example of revenue existing at the protocol while accrual to the token stayed a governance question.1
How detailed does a revenue model need to be for a token launch?
Detailed enough that each stream has its own driver, its own unit of demand you can measure next quarter, and its own assumed elasticity. A single blended take rate is not a model, it is a placeholder, and any simulation run on top of it produces confident-looking output with nothing underneath. Three well-specified streams beat a twelve-tab spreadsheet built on one assumed growth rate.
See Tokenomics Design for how this applies in practice.
Sources
- Making Protocol Fees Operational (governance proposal thread)
Uniswap Governance Forum
The on-the-record governance debate over switching on protocol-level fees, evidence that collection and accrual to the token are separate decisions. - UNIfication
Uniswap Labs
Proposal routing protocol fees and layer 2 sequencer fees into UNI burns, a first-party example of closing the gap between revenue collected and value reaching the token. - Revenue metric explorer
Token Terminal
Named provider publishing protocol revenue series. Cited for the existence of methodology-specific revenue definitions; read the provider's own methodology before comparing figures across sources.
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.