Never add a chain's economics to an application's
Chains and the applications running on them are separate layers with separate tokens, and summing their fees counts the same activity twice.
A chain sells block space. An application sells a service that consumes block space. A user of the application pays both, which means one economic event produces two fee records at two layers with two different recipients. Adding those records together counts the same activity twice and attributes the result to nobody in particular.
The layers and their claims
The layers differ in what each one sells, whom it charges and which token, if any, has a claim on the proceeds.
| Layer | What it sells | Who pays | Who receives |
|---|---|---|---|
| Layer 1 chain | Block space, ordering, settlement | Anyone submitting a transaction, including applications | Validators, plus burns or a treasury under protocol rules |
| Rollup | Cheaper execution, settled on a layer 1 | Users of the rollup | The sequencer, minus what the rollup pays the layer 1 |
| Application | A service: swap, loan, mint, bridge | Users of the application | Its liquidity providers, plus its own protocol share |
Each row has a distinct asset behind it. The chain's fees relate to its native asset; the application's protocol share relates to its governance token, which is a different instrument with a different holder base. No relationship makes one a claim on the other. An application can generate enormous chain fees and retain nothing, and a chain can host enormous application revenue and capture none of it beyond gas.
Where the double count enters
A trade on a decentralized exchange illustrates it. The trader pays gas to the chain and a swap fee to the venue. The chain records fee income; the venue records fee income; both are correct. An "ecosystem revenue" figure that sums them describes a quantity no participant received and no token has a claim on.
The rollup case is sharper, because there the double count involves a cost. A layer 2 charges its users for execution and then pays the underlying layer 1 to publish its data, historically as calldata and, after the introduction of blobs, through a separate data availability market. That payment is revenue to the layer 1 and a cost of goods sold to the layer 2. Summing "layer 1 fees plus layer 2 fees" counts the same user payment at both layers and simultaneously ignores that one is the other's expense. The correct treatment for the layer 2 is a net figure: what the sequencer collected minus what it paid for settlement and data.
The same structure appears in miniature elsewhere. An aggregator charging a routing fee on top of a venue's swap fee is a second layer on the first. A liquid staking provider taking a commission on validator rewards is a layer on top of the chain's issuance. In every case the deeper layer's revenue is partly the shallower layer's cost.
A further flow sits inside the first layer and is easy to overlook. Value extracted through transaction ordering, the subject of MEV, is paid by users and captured by participants in the block production pipeline, sometimes shared with validators and sometimes not. It is neither the chain's fee income nor the application's, although activity at both layers generates it, and it enters fee aggregates only where a payment happens to pass through a field that a data pipeline records. Counting it as part of either layer's revenue credits one party with a flow a different party received.
Why the sum is tempting anyway
Ecosystem totals exist because they are useful for advocacy. A large aggregate makes a network appear more substantial, and there is no accounting standard forbidding the construction. It survives partly because the layers are technically related — the application would not exist without the chain — and relatedness gets mistaken for consolidation.
Consolidation in corporate accounting has a rule behind it: an entity consolidates what it controls, and intercompany transactions are eliminated so that internal payments do not inflate the group. Neither condition holds here. A chain does not control the applications deployed on it; nobody eliminates the payments between layers; and there is no group, only separate assets held by separate people. The vocabulary of consolidation has been borrowed without the mechanism that makes it valid.
How to compare across layers without adding
The layers can be compared, and the comparison is often the interesting part. Set a chain's fees next to the fees of the applications running on it and the ratio describes how value is divided between execution and services — a division that has shifted as execution costs fell. Set a layer 2's gross fees against what it remits to its layer 1 and the difference is its actual margin on block space arbitrage. Set an application's retained revenue against the gas its users paid and the result shows whether the service or the settlement layer captured more of the user's spend.
All of these are ratios and differences between clearly labeled layers. None of them is a sum. The rule that makes the whole set safe is simple: only aggregate flows that a single asset has a claim on, and state which asset that is. Where the answer is that no single asset has a claim, the aggregate should not exist.
The same discipline applies to valuation ratios. Market cap to fees compares one token's valuation to the fees relevant to that token. Using a chain's market capitalization against an ecosystem fee total mixes a single asset's price with flows accruing to dozens of other assets, and the resulting figure cannot be interpreted at all. FDV to fees has the same requirement, with the added condition that fully diluted valuation counts tokens that do not yet exist.
Asset pages here keep chain-level and application-level figures on separate rows with the layer named, and compare refuses to add across them. The last lesson in this track addresses the assumption underneath all of it: that the word revenue means here what it means on an income statement.