How to build a comparison set that is not nonsense
A peer group only means something when fee mechanism, accounting boundary, supply definition and measurement window are held constant across it.
A ratio is only interpretable against something. For digital assets the reference is almost always a peer group, which means the quality of any comparison depends entirely on how the group was assembled. Most published peer groups are assembled by sector label alone, which is the weakest possible criterion and the easiest one to apply.
Four things have to match before a comparison carries information: the fee mechanism, the accounting boundary, the supply definition, and the measurement window.
Match the fee mechanism, not the sector name
Two protocols labeled as exchanges may earn money in unrelated ways. An automated market maker takes a percentage of swap volume and passes most of it to liquidity providers. An order book venue charges maker and taker fees at different rates and retains them. An aggregator may charge nothing at the point of trade and monetize order flow elsewhere. Their fee-based ratios are not on the same footing, and a table that sorts all three together is sorting by business model without saying so.
The same applies within lending. A protocol that charges a reserve factor on interest, one that charges an origination fee, and one that earns mainly through liquidation penalties will each show a different relationship between activity and revenue at the same scale of usage. Two of those revenue streams grow with calm markets and one grows with volatile ones.
Match the accounting boundary
Where a protocol runs on several chains, its fees can be attributed to the chain, to the deployment, or aggregated to the protocol. Where it has a front end charging its own fee, that fee can be inside or outside the protocol's revenue. Where a layer 2 earns fees from users and pays a base layer for data availability, its revenue can be stated gross or net of that cost, and the two differ substantially in both level and volatility.
Comparing a gross figure against a net one is a silent error with no visible symptom in the output. The methodology pages state the boundary applied to each protocol family here, and the first check on any comparison drawn from a different source is whether that source drew the boundary in the same place.
Match the supply definition
A group in which some members are measured on circulating supply and others on fully diluted valuation is not a group. Since the gap between the two can be large for young assets and negligible for mature ones, mixing them sorts the group by token age rather than by anything economic, and the resulting ordering will look meaningful because it is stable.
The practical rule is to run the comparison twice, once on market cap and once on the diluted figure, and to treat any conclusion that survives only one of the two as unproven. Showing FDV to market cap beside the ratio makes the divergence legible without a second table.
Match the window
Annualized figures built from 24-hour, 30-day and trailing-year windows are not comparable, and the gap between them is largest exactly when it matters most, during periods of unusual activity. A group compared on 30-day fees should use 30-day fees for every member, including the member for which a longer window would look more representative. Choosing the window per member is how a comparison becomes an argument.
| Grouping that looks reasonable | Why it breaks | A better grouping |
|---|---|---|
| All base-layer networks | Fee models, issuance and scaling architecture differ fundamentally | Networks with comparable fee markets and settlement roles |
| All decentralized exchanges | Pool-based and order-book economics have different take rates and capital needs | Same market structure, same fee model |
| Top twenty by market cap | Size is not a business model; the group shares no mechanism | Any of the above, with size as a filter rather than the criterion |
| Everything under one sector label | Labels are assigned by a provider and often cover unrelated designs | Sector label plus an explicit mechanism test |
| A base layer against its own rollups | Revenue is shared between them; one user fee appears twice | Rollups against rollups, base layers against base layers |
The double-counting trap in stacked systems
The last row deserves expansion. When a rollup charges users and pays its base layer for data, one user fee produces revenue lines in two places. Adding them across a sector overstates the total, and comparing the two directly compares a customer with its supplier. The introduction of blob space changed the price of that supplier relationship, which means any series spanning the change contains a structural break independent of usage. A comparison drawn across that break measures the change in pricing, not the change in the businesses.
Survivorship in the group itself
A peer group built from assets available today excludes those that failed, and this sector has a substantial record of failure. Groups constructed from current listings will show better historical statistics than the sector actually delivered, an instance of survivorship bias that no amount of care with ratios corrects. Where a historical comparison matters, the honest version names the members that no longer exist and states what happened to them.
A working checklist
- State the mechanism the group shares, in one sentence, without using a sector label.
- Confirm the fee boundary is identical for every member, including front-end and cross-chain treatment.
- Use one supply definition throughout, then repeat the exercise with the other.
- Use one window throughout, chosen before looking at any results.
- Check for stacked relationships where one member is another's customer or supplier.
- Note who is missing from the group and why they are missing.
The compare tool holds definitions constant across selected assets, and the screener allows a group to be built from mechanism filters rather than from a label alone. The sectors pages state how each label was assigned.