Revenue Growth (30d vs Prior 30d)

Revenue growth applies the same two-window comparison to the retained portion of fees rather than to total fees. Because revenue is a residual, this series moves more violently than fee growth and responds to changes in the fee split as well as to changes in usage. It is most useful when read directly against fee growth over the identical period.

How it is computed

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

Where it misleads

Revenue is the difference between two much larger numbers, so it inherits the measurement error of both and can swing sharply on a small change in either. A governance vote that raises or lowers the take rate produces a step change that has nothing to do with demand, and turning a dormant fee switch on can generate a percentage that is arithmetically infinite from a zero base. Protocols that accumulate fees and settle them to a buyback or burn contract on a schedule report revenue in lumps, so the window boundary decides the answer. Where a provider reclassifies what counts as revenue for a chain, the historical series is restated and the growth rate changes retroactively.

The equity comparison, and why it fails

Earnings growth. The analogy fails because there are no expenses, no tax and no share count behind the figure; it is a routing rule applied to fee flows and can be rewritten by a vote.

Reading a high or a low value

A positive value means more fee income was retained this month than last, and a negative value the reverse. Compare it with fee growth to see whether the change came from usage or from a change in the fee split.