Examining revenue and the business model

Who pays, for what, and where does it stay — three questions separating fees from revenue and both from the token.

This lesson has had no expert review. It was written for this platform and against the evidence it cites; nobody has gone through it independently.

Learning objectives

You can keep fees and protocol revenue apart and say who receives what.
You can check whether a token shares in revenue — or merely sits beside it.
You can identify a business model that does not sustain itself without incentive distribution.

Check your prior knowledge

Answer these for yourself before reading on. Wherever you hesitate is where this lesson pays off.

In a trading venue, who pays the fee and who receives it?
What distinguishes turnover from profit in an ordinary company?
What is a governance token actually needed for?

Core concept

Fact

Fees are not revenue

The fee is what users pay. Protocol revenue is the part of it that stays with the protocol itself. In between sit the recipients: liquidity providers, depositors, operators. In many protocols most of the fees go to those groups, and revenue is a small remainder. Conflating the two routinely overstates what economically sustains the protocol.

Fact

A token does not automatically share

Whether a token shares in revenue is a matter of design, not of name. Three cases are common: the token grants voting rights and nothing else; it grants a claim on part of the revenue; or it is bought back out of revenue. Only the latter two connect usage and token. In the first the token is a voting right whose price depends on something other than usage.

Assessment

The coverage question

The single most useful question to ask a business model is: does the incentive distribution exceed revenue? If it does, capital is currently being bought, and in this form the model does not sustain itself. That is not a condemnation — build-up phases look like this. But it is a statement about what has to happen for it to sustain itself, and by when.

Uncertainty

Numbers with care: the aggregator question

Fee and revenue figures usually come from a secondary reading rather than from the protocol's accounts — which mostly do not exist. Different sources draw the line between fee and revenue differently, and a change of methodology looks in the time series like a change in the business. So a comparison across sources belongs after the question of how each source drew the line.

Definitions

Fee: The amount users pay for an interaction, regardless of who receives it.
Protocol revenue: The part of the fees that stays with the protocol itself.
Value capture: The mechanism by which a token shares in a protocol's revenue.

Model

User pays — that is the fee
Share to liquidity providers, depositors, operators
Remainder with the protocol — that is revenue
Does any of it reach the token? A claim, a buyback, or nothing
Set against: value of the incentive tokens issued

The path of a fee — Steps two and four are the most frequently skipped — and they decide the statement.

Formulas

Incentive coverage

coverage = protocol_revenue / incentive_distribution

protocol_revenue: Part of the fees staying with the protocol in the period
incentive_distribution: Value of incentive tokens issued in the same period

Limit: The distribution is valued at the prevailing price and therefore moves with it — as the price falls coverage looks better without anything in the business having changed. The metric is a ratio of two estimates, not an accounting figure.

Worked example

High fees, small revenue

Fees, 30 days: USD 8.4m
Of which to liquidity providers: USD 7.6m
Protocol revenue: USD 0.8m
Incentive distribution, 30 days: USD 2.6m at the current price
Token design: voting right, no revenue share

Coverage = 0.8 / 2.6 = 0.31. For every dollar distributed the protocol takes in 31 cents. The token has no share in those 31 cents; it carries a voting right.

The business exists but is covered to roughly a third — and the token does not share in it.

Reading: Two separate findings that often get merged. The first concerns the protocol's viability, the second the reason anyone holds the token. Rising fee income improves the first and says nothing about the second.

Retrieval

USD 8.4m.Only the part not passed on to liquidity providers, depositors and operators.Half, as a usual rule of thumb.

The business has become more viable.The price of the distributed token fell, so the distribution is worth less.Revenue was redefined.

Exercise on real data

Work through the guiding questions for one protocol and record where a figure is missing.

Dimension 2: business model →

Compare the entries for fees and revenue: which boundary does the catalog state?

Metric catalog →

Application

Write the “business model” section of a protocol analysis in four sentences.

Related case studies

Institutional reading

Bank: Which number from this chain would appear in a credit assessment — and against whom?
Asset management: Does your reporting currently separate fees from revenue?
Advisory: How do you explain that a protocol has revenue while its token does not share in it?

Metrics in this lesson

Key takeaways

The fee is what users pay; revenue is what stays.
Value capture is a design choice — a voting right alone does not connect token and usage.
Coverage below one means capital is being bought; that is describable, not condemnable.

Evidence

EVD-2026-0008
DeFiLlama — DeFiLlama yields endpoint (/pools)