Adapter-Dependent Fee Accounting
Fee and revenue figures come from code that reads each protocol differently, so a number can change because an adapter changed rather than because activity did.
How it happens
Analytics platforms compute protocol fees by writing an adapter for each protocol that maps contract events to a metric, and every adapter embeds judgment calls: whether to count gross fees paid by users or only the portion a protocol retains, whether to net out token incentives paid back to those users, whether to attribute a fork's activity to the original protocol, and whether to sum deployments across chains. Adapters are typically open source and maintained by contributors, including contributors employed by the protocols being measured, and they are revised as protocols change. A revision applied retroactively changes history as well as the present. These figures are not audited financial statements: no standard defines what counts, no auditor attests to the result, and nothing requires the method to stay constant between periods.
What you can actually observe
Read the adapter source for the specific protocol on whichever dashboard you are quoting, and note the exact definition of the metric, since fees, revenue, and earnings are used inconsistently across providers. Compare two independent providers for the same protocol and period and investigate the gap rather than choosing the more convenient number. Look for methodology change logs and for step changes in a series that align with a code commit instead of an on-chain event.
What makes it more or less material
Consider whether the metric is defined and documented, whether the adapter is maintained by an independent party, how much providers disagree, and whether the protocol's fee mechanism changed during the period examined.
Related factors
Assets this applies to
The largest assets we classify in the categories this factor applies to. Presence here means the factor is relevant to that kind of asset, not that it has occurred.