Detected Embedded Data, Volume
Daily average data bytes per block by protocol, each format including its own framing
Short ranges plot one point per block, about one every ten minutes. Longer ranges plot one point per day, computed from every block in that day. How it is computed depends on the chart: some average, some total the day up, some are a ratio of the day's sums, and each chart says which. Either way a brief spike inside a day is smoothed away.
About this metric
Definition
Everything the site detects as embedded data, by size rather than by count. About 63% of blocks carry an OP_RETURN output and about 20% carry a detected inscription, and the two are measured on different bases, which the bands say.
How it is measured
The OP_RETURN bands are measured: they are the script bytes themselves. BRC-20 is folded into the inscription band rather than drawn beside it, so the bands here are not the same split as the count chart, where BRC-20 has a band of its own.
The inscription band is an estimate. Inscriptions are a convention rather than a consensus rule, so there is no field to read: they are found by looking for the marker bytes that open an Ordinals envelope. The band then counts the whole witness item that matched, envelope and content-type included, so it over-states payload rather than under-stating it: an item carrying an inscription alongside unrelated data is counted in full.
Across the whole chain that is about 6.6 GB measured against about 44 GB estimated. Most of this stack's height therefore rests on an estimate rather than a count.
Two limits on the per-protocol split, both of which matter more than the totals. The Runes band is a size test, outputs of six bytes or fewer from height 840,000, and it now takes in most post-840,000 OP_RETURN outputs, so read it as a lower bound on a category rather than a count of Runes. And Stamps is named nowhere here because the site does not currently detect it. Coinbase OP_RETURN outputs are excluded throughout.
Measured from my own Bitcoin node. Methodology