What a protocol fee is, and who actually pays it

A protocol fee is a payment made by whoever uses a blockchain or an on-chain application, assessed and routed by software rather than billed by a company. There is no invoice and usually nothing to negotiate: the fee is attached to the transaction, and a transaction that does not pay it does not happen. What varies enormously between networks is who pays, what they pay in, and who ends up holding the money.

The payer is a user, and payment is a condition of service

Every fee starts with someone who wants something done: a transfer settled, a swap executed, a loan opened, a token minted. On a layer 1 network the fee is paid in that chain's native asset and priced in gas — a unit of computational work — multiplied by a price per unit that rises when blocks are full. The user cannot be invoiced later, because there is no relationship to invoice; every node that validates the transaction also validates that the fee was paid.

That pricing is an auction rather than a price list. Block space is finite per block, demand for it is not, and when demand exceeds supply the cost of inclusion rises for everyone in the queue. Ethereum's EIP-1559 change in 2021 is the clearest worked example: it split the gas price into a base fee that the protocol sets algorithmically according to how full recent blocks were, and a priority fee the user offers a block producer for better placement. The two halves have different recipients, which is the first sign that a fee is rarely one flow.

Applications charge on a different basis. A swap on a decentralized exchange normally costs a percentage of the amount traded; a lending protocol takes a share of the interest a borrower pays; a minting contract may charge a flat amount per item. Because applications run on chains, an application user generally pays twice — once to the chain for execution and once to the application for the service. Those two payments are recorded in different places by different data pipelines, and confusing them is among the most common errors in this subject.

Where the money actually goes

A fee has a destination, and the destination says more about a network than the size of the fee does. The usual ones:

• Block producers. Miners under proof of work and validators under proof of stake are paid for ordering and securing transactions, normally alongside newly issued tokens.
• Capital providers. On an automated market maker most of the swap fee goes to the liquidity providers whose assets were traded against; on a lending market most of the interest goes to depositors.
• Destruction. Some fees are burned, permanently removed from supply, as the base fee is on Ethereum. The mechanism is described under token burn.
• A treasury. Fees can accumulate in a protocol treasury that a governance process controls.
• Token holders. Where a fee switch has been enabled, some share is routed to holders or stakers of a governance token.

Only the last three are amounts the protocol itself has any claim on. The first two are payments for a service someone else performed, and treating them as if they belonged to the token is the error the next article in this track takes apart.

The currency of payment is part of the fact

Fees paid in a chain's own token behave differently from fees paid in a stablecoin. When the token's price falls, the dollar value of fee income falls with it even though usage has not changed; when it rises, identical activity produces a larger dollar figure. A fee series measured in dollars therefore mixes two moving parts — how much the network was used, and what its unit of account was worth at the time. Both matter, but they are different questions, and fee growth that comes entirely from one of them is a different observation from growth that comes from the other.

Most of a fee is compensation for a cost

Fee totals look like profit and almost never are. In most cases they are gross payments to a party who bore a real cost: a validator running hardware and locking capital that could have been used elsewhere, a market maker carrying inventory risk and exposed to impermanent loss, a depositor giving up the use of funds. The economically interesting quantity is what is left after the people who did the work have been paid, which is why fee data here separates supply-side revenue from protocol revenue.

The separation also explains why two applications with identical fee totals can be nothing alike. One may pass nearly everything through to capital providers and retain a sliver; another may retain most of it. The headline number matches and the take rate does not.

What a fee figure on this site counts

Fee figures here aggregate what users paid over a window, converted to dollars at the time of payment: fees 24h, fees 7d and fees 30d for fixed windows, annualized fees for a run-rate extrapolation, and average transaction fee for the cost of a single interaction. Annualization is arithmetic, not forecasting: a window containing one unusual week annualizes into a year that never existed, and the run rate is only as stable as the demand behind it.

Coverage is also incomplete by construction. Payments made off-chain, incentives a foundation pays to attract activity, and privately negotiated rebates leave no on-chain trace, so an aggregate is best read as a measured floor rather than a complete account. The per-network scope rules are written down in methodology, and they differ enough between chains and applications that reading them first changes what the numbers appear to say.

The fees section shows these figures by network and by application, and the metric catalog defines each window precisely. The next lesson separates the fee a user pays from the revenue a protocol keeps — the one distinction that makes everything else in this track readable.