Data
What protocol fees and revenue tell you
A protocol’s fee figure is DefiLlama’s top line: what users paid for using it and, for staking and yield protocols, what the deposited assets earned. DefiLlama, the source of the fee columns on this site’s data pages, defines two more numbers below it, what the protocol kept and what reached its token. Which window the figure covers then decides how much a single day can move it.
Three numbers, one word
“Revenue” is the word that causes the trouble, because off-chain accounting and DefiLlama use it for different lines. Every definition below is DefiLlama’s own, taken from the Fees and Revenue section of its data definitions page unless another page is named. Like every source cited here, the page was read on 3 October 2026. DefiLlama says it models protocol fees and revenue as an income statement inspired by GAAP accounting, so each number maps onto the next.
Fees are the total paid by users when they use the protocol. In DefiLlama’s words they are equivalent to what would traditionally be called revenue in most off-chain businesses, and they count regardless of where the money ends up. The principle is that fees include everything the protocol could theoretically keep if it took the whole flow. A lending protocol’s fees are therefore all the borrow interest, not just the share the protocol retains, and a liquid-staking protocol’s are all the staking rewards the staked assets generate, not just the protocol’s cut. Block rewards and token emissions are not fees: DefiLlama treats them as incentives, a cost the protocol pays.
Supply-side revenue is the part of fees paid on to those who supply the capital or resources the protocol runs on: liquidity providers, lenders, stakers and node operators, along with integrators, referrers and creators. DefiLlama likens it to the cost of revenue.
Revenue is fees minus supply-side revenue, the subset the protocol collects for itself, which DefiLlama likens to gross profit. It says that money usually goes to the treasury, the team or token holders. Holder revenue is therefore not a third number beside revenue: in DefiLlama’s terms it is a subset of it, with one exception, below.
Protocol revenue is the subset of revenue allocated to the treasury or the
core team. Token holder revenue (dailyHoldersRevenue in DefiLlama’s API,
holder revenue for short) is the subset distributed to token holders by buyback
and burn, by burning fees or by direct distribution to stakers, which DefiLlama
likens to dividends. Only value reaching the protocol’s own governance token
counts, so a protocol without a token has none, and burns count only when funded
by actual receipts: the page excludes treasury-funded buybacks. It also adds
value reaching holders from outside the protocol, such as airdrops from other
protocols and bribes paid by other protocols to the token’s voters, so the
figure can include money that never passed through the protocol’s own fees.
DefiLlama’s other pages word some of this differently. The adapter
guide, written for
teams listing a protocol, defines dailyFees as all fees and value collected
from all sources, with dailyUserFees for the part end-users pay directly. This
piece follows the data definitions page.
The fee columns on the data pages carry the first of the three numbers only. DefiLlama’s API documentation describes the fees endpoints as returning fees by default, with revenue and holder revenue as the other two data types, and the site takes the default. The protocols table shows fees over 30 days, and each protocol’s page shows them over 24 hours, 30 days and a year where DefiLlama has them. Revenue and holder revenue exist in DefiLlama’s data and are not shown, so a fees column cannot say what a protocol kept.
Who gets the fee
The split between the recipients is a design decision, and it differs by protocol type. The adapter guide has a classification table for teams unsure how to file their numbers; it classifies examples and measures no protocol, but it shows how the recipients differ by type. For a DEX, supply-side revenue is the liquidity providers’ share and revenue is the percentage of swap fees going to protocol governance, which the guide says covers the treasury and token holders together. For lending, supply-side revenue is interest paid to lenders and revenue is the percentage of interest going to governance. For liquid staking, supply-side revenue is the revenue earned by stETH holders. The row for holder revenue has an entry in three of the nine columns (DEXs, derivatives and synthetics), and the guide marks the other six as typically not applicable or zero.
Uniswap’s own fee
documentation,
as the page stood on 3 October 2026, shows several recipients in one design. A
swap fee accrues to the liquidity providers whose liquidity was active at the
time. Protocol fees are a portion of the swap fee directed to the protocol
instead, and the page says a governance vote in December 2025 switched them on
for all v2 pools and some v3 pools. The page also separates code from vote: for
v2 it says the rate is fixed in the pair contracts at 1/6 of the swap fee, and
governance switches protocol fees on or off, globally, by setting the feeTo
address on the v2 factory. Collected fees sit in on-chain contracts that, the
page says, searchers can claim from by burning a required amount of the UNI
token. One fee reaches the liquidity providers, the protocol’s fee contracts
and, through the burn, the token.
The same gross fee can therefore leave very different amounts behind. An illustration with invented numbers, not a reading of any protocol. Two lending protocols each collect $1,000,000 of borrow interest in a month, so each reports $1,000,000 in fees. The first pays $950,000 of it to lenders and keeps $50,000. The second pays $600,000 to lenders and keeps $400,000. Fees are identical and revenue differs eightfold, and the fees figure alone cannot tell them apart. Supply-side revenue is the same money seen from the other side: where crypto yield comes from follows who pays it, borrowers for lending and traders for liquidity provision.
Windows and noise
A fee figure is a sum over a window, and the window decides what the sum can show. The documentation pages read here do not define the boundaries of the 24-hour, 30-day and one-year windows the data pages carry. They do state two rules that bear on any window. Fees count on the day they accrue, not the day they are paid or claimed, and realised losses, such as a vault drawdown, are recorded as negative fees rather than clamped to zero, so a window can net out below zero.
An illustration with invented numbers. A protocol collects $100,000 in fees on each of 364 days and $2,900,000 on the latest day.
| Window | With the large day | With an ordinary last day | Difference |
|---|---|---|---|
| 24 hours | $2.9m | $0.1m | +2,800% |
| 30 days | $5.8m | $3.0m | +93% |
| 1 year | $39.3m | $36.5m | +7.7% |
The 24-hour figure is that one day, 29 times an ordinary one. The 30-day figure still carries it, as half the total. The year dilutes it to under a tenth of the total. The long window has the opposite weakness. A protocol that collected $200,000 a day for 300 days and $20,000 a day for the last 65 shows $61.3m over the year, which spread evenly is about $5.0m for a 30-day period, against $0.6m in its latest 30 days. The year reports the earlier regime and the short windows the later one, each with its own noise.
“Annualised” can mean any of these windows expressed per year, and which window was used matters. The invented protocol above annualises to $1,058.5m from its latest day, $70.6m from its latest 30 days scaled by 365/30, and $39.3m as a trailing year, against $36.5m with no large day. DefiLlama’s documentation uses the word without defining it. Its custom-columns page lists fee fields for 24 hours, 7 days, 30 days and one year, and a field that divides market cap by annualised fees. Its worked example for annualised fee yield divides the one-year fee field by TVL, and another tests 7-day fees against 30-day fees scaled to seven days, which it calls the prior run rate. The page does not say how the annualised fees behind that field are derived or how the one-year field is built, and neither it nor the data definitions page defines annualised.
None of these is a forecast. Each is a sum of days already past, or those days repeated, and whether the coming days resemble them is not something the figure holds. The same hazard appears in DefiLlama’s yield data: the yield piece notes that the guidelines for the adaptors behind its yield table ask for fee-based yield over a 24-hour window, so one unusual day can set an annualised figure.
Fees against TVL
Fees divided by total value locked compares a flow with a balance. DefiLlama’s custom-columns page offers it as worked examples, 30-day revenue over TVL and one-year fees over TVL, and the traps sit on both sides of the division.
The denominator is deposits valued at the prices of one date. What TVL measures, and what it does not sets out how it moves with price and counts the same capital again at each layer. The numerator has a rule against that: DefiLlama says the same fees are never counted under two listings. Across protocols the denominator has only a flag, used when summing to chain and global totals, and a protocol’s own TVL still includes a receipt token deposited in it from elsewhere, so the ratio can read low without the fees being any lower. A 30-day fee sum over the TVL on the snapshot date also mixes a period with a date, so if deposits arrived or left during the month, the balance in the denominator is not the one that earned the fees.
The numerator has its own traps. The first is incentives. DefiLlama excludes token emissions from fees by definition, but fees that users really paid on activity the emissions attracted are still fees. Its definition of earnings (revenue minus the value of incentives the protocol emitted over the same period) describes the case: a protocol paying for usage with its own token can show high revenue and deeply negative earnings. The data pages show neither earnings nor incentives. The second is category. The adapter guide’s table gives the fees row as swap fees paid by users for a DEX, interest paid by borrowers for lending, staking rewards for liquid staking and yield for yield protocols, so a ratio compared across categories compares unlike quantities.
Where the token’s claim is written, or not
Token holder revenue, as DefiLlama defines it, records value distributed to a token’s holders: bought back and burned, burned as fees, or paid out to stakers. It is a measured flow, not an entitlement. The difference is the question the tokenomics piece puts to every supply figure: enforced by what? A routing built into a contract binds as far as the contract does, and a routing in replaceable code lasts until the upgrade key says otherwise, the case that piece describes for supply caps. A routing set by governance binds until the next vote. The Uniswap page cited above shows two of these in one design: a v2 rate fixed in the pair contracts, and a vote that switches protocol fees on or off. A routing described in a forum post or a roadmap binds nothing on-chain.
Whether a holder has any legal or contractual claim to a share of revenue is a different question again, and neither a fees table nor DefiLlama’s definitions answer it. The definitions count only value that reached holders, and say that a protocol with no token has no token holder revenue, whatever its fees. This piece makes no statement about the legal position of any token.
The boundary of what counts needs care too. The adapter guide’s template lists treasury buybacks as a holder flow, while the data definitions page excludes treasury-funded ones, as noted above, and neither says whether the two are the same thing. The adapter guide tells teams to include a methodology text explaining how their metrics are calculated, so which buybacks a figure includes has to be read from the protocol’s own methodology, which these pages do not show.
Reading a fees table
Five checks, in this order.
- The window. Is the figure 24 hours, 30 days or a year? A 24-hour figure is one day’s fees, not a rate. Comparing the 30-day figure with the year scaled to 30 days (multiplied by 30/365) shows whether the last month looks like the year.
- The definition in use. Fees, revenue or holder revenue; the data pages carry only the first.
- The recipient. DefiLlama’s category, shown on each protocol’s page, suggests which column of the adapter guide’s table to read, where the table has one. Then ask who is on the supply side, whether there is a token, and how the split is set: in a contract, by a vote, or only in a document.
- The trend over the long window. A gap between the year and the latest month, as in the 300-day example above, marks a spike or a change of regime. Telling them apart needs the daily series, which DefiLlama’s per-protocol summary is documented as carrying and these pages do not show.
- The ratio to TVL, last. With its caveats: a flow over a balance, recycled capital in the denominator, incentives in the numerator, and categories that mean different things by fees.
A fees table settles something narrow: what DefiLlama counted as a protocol’s fees over a window, under that protocol’s methodology. It does not settle what the protocol kept, what reached holders, or what the next window holds, and each of those needs a different number or a different document. The table from the latest snapshot is at DeFi protocols, and each row opens a page that shows the three windows together.