Protocol revenue

Three numbers, and only one of them gets quoted

Token Terminal's methodology draws the line the industry has largely settled on. Fees are what users pay to interact with a protocol. Revenue is the portion of those fees the protocol actually retains, determined by its take rate, with the balance going to whoever supplied the liquidity, the capital or the hardware.¹ Earnings is revenue net of expenses, and the expense line that matters most here is token incentives.²

The gap between fees and revenue is not a rounding error. On a marketplace or an exchange the supply side often takes most of the fee, by design, because that is what makes the market work at all. A protocol quoting fees as revenue is frequently quoting the number its dashboard displayed most prominently, and nobody in the room asked which one it was.

So the habit worth building is small: whenever you see a revenue figure, ask whether the supply side has been paid out of it yet. That one question resolves most of the disagreement about whether a protocol makes money.

Emissions dressed as revenue, in the three forms it takes

The first form is the crudest. Token incentives get counted as income because tokens moved. They did not come from a customer; they came from the supply schedule, and the methodology separating earnings from revenue exists to keep them out of the number.² Issuing your own token and booking it as revenue is the tokenomics equivalent of invoicing yourself.

The second is subtler and far more common: real fees from users who were paid more in emissions than they paid in fees. The revenue line is genuine. The customer acquisition cost, denominated in tokens, exceeds it. This shows up as a healthy fee chart attached to a business that loses money on every transaction, and the loss is invisible until you put emissions on the same page as fees.

The third is treasury activity. Selling tokens from the treasury produces cash. That is financing, not revenue, and it belongs in the same column as an equity raise. We have seen it presented as runway the protocol generated, which is true in the sense that a mortgage generates cash.

A fee switch is not the same decision as paying holders

The fee switch is the mechanism by which a protocol starts retaining a share of the fees flowing through it, usually gated behind a governance vote. Founders and holders routinely collapse two decisions into one here, and governance records show they are separable.

The Uniswap governance discussion on the fee switch design space makes the point explicitly, noting that turning on fee retention does not create any expectation that the retained tokens will be paid out to token holders.³ That is a governance body being careful, and the care is instructive: switching on retention decides that the protocol accumulates value. What happens to the accumulated value is a second decision, with its own vote, its own legal analysis, and its own consequences.

Treat those as two entries in your design document. Where the fee goes, and what the protocol may do with it once it is there. Teams that write only the first sentence meet the second in a governance forum eighteen months later, under pressure, with a price chart in the background.

What it looked like when a large protocol flipped it

Uniswap's UNIfication proposal, activated in late 2025, is the most fully documented recent example. Coin Metrics reported that it routes v2, v3 and Unichain protocol fees into a vault contract from which value can exit only through UNI burns via a separate burn contract, which converts UNI from a governance token into a fee-linked, burn-based value-accrual model.⁴

The figures, and they need their date attached: writing on 13 January 2026 from the first twelve days of data, the analyst reported an illustrative annualised protocol-fee run rate of roughly 26 to 27 million dollars, a retroactive one-off burn of 100 million UNI from the treasury, and roughly 4 million UNI per year in ongoing burns, against a UNI valuation of about 5.4 billion dollars.⁴ Those numbers were presented explicitly as early and illustrative rather than as a settled long-run figure, and twelve days of data annualised is exactly as fragile as it sounds.

What is worth taking from it is architectural rather than numerical. The fees route to a specific contract, the exit path from that contract is defined in code, and the value-accrual mechanism is therefore inspectable rather than promised. That is the difference between a revenue story and a revenue design.

Revenue is not margin, and margin is not distributable

Retained fees still carry costs. Security budgets, oracle fees, audits, insurance funds, grants, and the token incentives keeping the supply side present. A protocol with real revenue and a larger incentive bill has negative earnings and a growth story, which is a legitimate position to hold as long as everyone is holding it deliberately.

Where the residual goes changes the token model. Accumulate it in a treasury and you have an asset with a governance problem. Burn it and you have a supply-side mechanism whose effect on holders depends on demand doing something you do not control. Distribute it and you have a cash-flow claim, which is where the securities analysis gets materially harder and where your counsel needs to be in the room. None of these is right in general. They are right or wrong against a specific business and a specific jurisdiction.

Five questions we put to any revenue claim

Who paid, and would they still have paid without an incentive. In what asset, since fees paid in the protocol's own token are partly a supply-side event. What share the protocol kept, expressed as a take rate rather than a total. What it costs to earn, with token incentives on the same page rather than in an appendix. And what the protocol is permitted to do with the retained value, in code and under its governance rules rather than in intention.

Five answers gives you a number a diligence process can survive, and usually a smaller number than the one in the deck. That is the point. Tokenomics enhances value creation rather than substituting for it, and a protocol with real revenue and a modest mechanism is in better shape than one running an elaborate mechanism over fees that only exist while the incentives do.