The Pile

non-monetary data on Bitcoin, measured from a full node

tip · data FEED INTERRUPTED — showing the last data received
EVERY NON-MONETARY BYTE A NODE MUST STORE
THE PILE OVER TIME · CUMULATIVE SINCE THE FIRST INSCRIPTION
AS IT HAPPENS · THE LATEST BLOCKS FROM THIS NODE
CLEAN nothing new BELOW TYPICAL TYPICAL ABOVE TYPICAL
WHAT THE PILE IS MADE OF
HOW THIS IS COUNTED
every figure on this page comes from parsing each block on a Bitcoin Knots node — no indexers, no third-party APIs, no sampling

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.