Fee Growth (30d vs Prior 30d)

This compares two adjacent one-month windows built with the same adapter, which removes most definitional noise and isolates the change in fee payments. It is the simplest way to see whether demand for a protocol's blockspace or services is expanding or contracting. It is a comparison of two totals, not a trend line, so it says nothing about the path between them.

How it is computed

(protocol fees over the last 30 days / protocol fees over the 30 days before that - 1) x 100

Where it misleads

Because both windows are measured in US dollars, a token price move changes this number even when transaction counts are identical: a chain whose native token halved can print falling fees on rising usage. Young or small protocols have tiny denominators, so an ordinary week produces percentages in the hundreds that carry almost no information. Incentive campaigns, airdrop farming seasons and a single congested week lift the recent window and guarantee a negative reading once they end, which is a calendar effect rather than deterioration. Retroactive adapter revisions change both windows after publication, and a protocol that added a new chain deployment mid-period shows growth that is coverage, not demand.

The equity comparison, and why it fails

Revenue growth. The analogy fails because reported corporate revenue growth is currency-adjusted and audited against a stable definition, while this figure mixes activity, token price and adapter scope in one percentage.

Reading a high or a low value

A positive value means more was paid in fees over the recent month than the month before, and a negative value the reverse. Check whether the token price moved over the same period before attributing the change to usage.