Fees versus revenue, and who keeps the money
One payment splits into a supply-side share, a protocol share and sometimes a holder share; reporting only the first number describes almost nothing.
A fee is what the user pays. Revenue is what somebody keeps. Between the two sits the supply side — the validators, liquidity providers and depositors who actually performed the service — and in most on-chain businesses the supply side takes the larger part.
One payment, three layers
Start with a single swap. The trader pays a fee measured as a percentage of the trade. Most of it is credited to the liquidity pool and belongs to the liquidity providers who supplied the assets; that portion is supply-side revenue. A smaller portion, if the design has one and governance has switched it on, is diverted to the protocol; that portion is protocol revenue. Of the protocol's share, some may be paid onward to token stakers or used for a buyback, which is holder revenue, and some may sit in the protocol treasury.
These are nested, not additive. Holder revenue is a subset of protocol revenue, which is a subset of total fees. Adding them produces a number with no meaning, and yet aggregate figures assembled from mixed sources sometimes do exactly that. Whenever a figure is quoted without saying which layer it belongs to, the layer is the first thing to establish.
The same structure across four businesses
| Business | What the user pays | Who takes the supply side | What the protocol can keep |
|---|---|---|---|
| Layer 1 chain | Gas fee per transaction | Validators or miners, for security and execution | Whatever is burned or directed to a treasury by protocol rule |
| Automated exchange | Percentage of trade size | Liquidity providers, who bear inventory risk | A fixed fraction of the swap fee, if governance enables it |
| Lending market | Interest on the borrowed amount | Depositors, who give up use of capital | A reserve factor skimmed from the interest |
| Liquid staking | Nothing directly; a cut of staking rewards | Node operators running the infrastructure | A commission on rewards, split with operators |
Read down the third column and the pattern is plain: in every case someone had to put capital or hardware at risk, and the fee is first of all their compensation. A network with very large fees and a very small protocol share is not failing at anything; it may simply be a business where the supply side is expensive and competitive.
Why the supply side is not a leak
It is tempting to treat supply-side payments as friction to be engineered away. They are usually the cost of the product existing. Cut the reward to liquidity providers on an exchange and depth falls, slippage widens and traders leave; cut the yield to depositors on a lending market and borrowable supply shrinks. The supply side is competitive across venues, and capital moves when the pay changes.
For a chain the argument is stronger still. Payments to validators pay for the property that makes the ledger worth using at all. Reducing them reduces the cost of attacking the chain. Supply-side revenue on a layer 1 is closer to a security budget than to a cost of goods sold, which is one reason the protocol revenue of a chain is a strange concept even when it can be computed.
What "protocol revenue" actually claims
Protocol revenue is the share that accrues to the protocol as an entity — burned, held in a treasury, or distributed to a token. It is not audited, not recognized under any accounting standard, and not owed to anyone by contract. Its most important property is that it is a policy variable. A governance vote can raise it, lower it or switch it off, and the change takes effect as soon as the contract is updated. A firm cannot rewrite its revenue overnight; a protocol can, and several have.
That is also why holder revenue deserves its own line. Value reaching a treasury has reached an entity that may spend it on grants, salaries, incentives or nothing at all. Value reaching stakers has reached holders directly. The gap between the two is a governance question rather than an economic one, and a network can look very different depending on which of the two a summary quotes. The term real yield was coined to describe distributions funded by fees rather than by newly issued tokens, and it only means something once the layers are separated.
Where the split goes wrong in the data
Three failures recur. The first is a fee total presented as revenue, which overstates by whatever the supply side takes — often most of it. The second is the reverse: a protocol share quoted with no fee context, so a small absolute number looks like weak demand when it may reflect a deliberate decision to keep the take low. The third is inconsistent scope, where one venue's figure includes incentives paid back out to users and another's does not, making a comparison meaningless without reading methodology for both.
The site keeps the layers apart on purpose. Fees 30d is the top line; supply-side revenue 30d is the portion paid out to providers; revenue 30d is the portion the protocol retained; holder revenue 30d is the portion reaching token holders. Revenue yield and holder revenue yield restate the last two against market capitalization so that networks of different sizes can be lined up.
One caveat travels with all of them. A retained share is not free cash: a treasury holding its own governance token holds an asset whose value depends on the same demand that produced the revenue, and selling it at scale affects the price. Treasury composition is part of the picture, not a footnote to it.
The fees section shows all four layers side by side for each network and application, and the next lesson compresses the relationship between them into a single ratio — the take rate — along with the reasons a high one and a low one are both ambiguous.