The Pile
non-monetary data on Bitcoin, measured from a full node
Inscriptions
Data written into a part of a transaction that can never run — a script branch that is always skipped. It cannot affect whether a payment is valid, which leaves it one purpose: carrying bytes.
OP_FALSE OP_IF <data> OP_ENDIF
Consensus changes made them practical, not a relaxed default: the witness discount in 2017 made this data cheap to include, and Taproot in 2021 removed the limit on how large a script could be. Bitcoin Core never refused inscriptions — there was no rule to relax.
Finding them needs no list of protocols and no guess at intent. The shape of the script is the whole test, so it caught the first inscription in 2022 and will catch whatever is invented next.
OP_RETURN
A deliberate way to attach data to a transaction, added in 2014. Every node still downloads it, verifies it and stores it forever, exactly like inscription data. What it avoids is the second cost: because the output is provably unspendable, it never joins the list of coins a node has to keep on hand.
Its size was capped at 83 bytes by a relay default until Bitcoin Core raised the limit in late 2025.
Only the OP_RETURN outputs are counted, not the transactions carrying them. Unlike an inscription, a transaction with an OP_RETURN is usually moving money as well, and charging the whole thing to the data would count that as non-monetary too.
Chainstate
Every inscription sits on a tiny output, usually a few hundred satoshis. That output stays in every node's working state until somebody spends it — and spending it costs more in fees than it holds, so it stays.
This is the part pruning cannot remove. A node can delete old blocks and keep validating; it cannot delete its record of what currently exists. It is the smallest number on this page and the only permanent one.
Where the numbers differ
Everything above counts all OP_RETURN, because storage does not care which rule let the bytes in.
The live block section is the one exception. There each block is graded on what the pre-2023 defaults would have refused — inscriptions, plus only the OP_RETURN beyond the old 83-byte cap. Ordinary OP_RETURN is left out because it was a deliberate, uncontroversial channel, and including it would put a constant background on every block and hide the thing worth seeing.
So the percentages on the blocks, the colour bands and the clean-block count all use that narrower measure. Nothing else on the page does.
What this does not measure
"Would have blocked" is softer than it sounds. The OP_RETURN cap was a relay default, and miners taking transactions directly could always ignore it. Inscriptions were never refused by Bitcoin Core at all. Neither would have been impossible — both would have been harder or dearer.
Data can move. Witness bytes are cheaper than output bytes, so data blocked from one route may take another rather than disappear.
Some carriers are not detected. Protocols that hide data in fake public keys are counted here as ordinary spending.
The total is a floor. Blocks between the last full scan and the live feed are not counted yet, so the figure understates rather than overstates.
Every block since the first inscription is parsed on a Bitcoin Knots node — no indexers, no third-party data, no sampling. The classifiers are covered by tests that run without a node, and every block is checked against a measure the node reports independently. Source, tests and the full method: github.com/bretstu/thepile.