Transaction Growth (30d)

This compares two adjacent monthly totals of confirmed transactions on the same chain. Because the unit is stable within a chain, month-over-month change is more reliable than the raw level for judging whether use of the network is expanding or contracting. It remains a count, so it weights a large settlement and a trivial transfer identically.

How it is computed

(transaction count over the last 30 days / transaction count over the 30 days before that - 1) x 100

Where it misleads

A protocol upgrade that changes what counts as a transaction, such as transaction batching, account abstraction bundling, or posting layer 2 data in blobs, creates a step change that has nothing to do with how much anyone used the chain. Spam and airdrop-farming campaigns can double a count for weeks and hand back the entire gain when they stop. Fee levels drive the count directly, since cheaper blockspace mechanically produces more transactions for the same underlying economic activity, and a fee increase does the reverse. Where a chain reindexed its history or a provider changed its inclusion rules, prior periods are restated and the growth rate changes without any on-chain event.

The equity comparison, and why it fails

Unit volume growth. The analogy fails because the unit is not held constant: a chain can redefine what a transaction is through an upgrade in a way a shipped product cannot.

Reading a high or a low value

A positive value means more transactions were confirmed this month than last and a negative value means fewer. Check for protocol upgrades inside the window before reading a step change as demand.