The conservation identity
claimed + carriage + burned + unclaimed = block size: the four categories every byte falls into, why the identity is the meter's trust anchor, and how block.space shows the check.
Every byte of every block lands in exactly one of four categories, and the four add up to the block's exact size:
claimed + carriage + burned + unclaimed = block size
block.space's BTI documentation calls this partition "the Meter's trust anchor: the categories are complete, they are exclusive, and anyone can add the numbers themselves." This page explains the four terms, why the identity matters, and what the site prints when it does or does not close. The glossary entry is conservation.
The four categories #
The definitions, from the BTI documentation and the renderer's own labels:
| category | meaning |
|---|---|
| claimed | bytes at least one token bought; they back a living token |
| carriage | whole transactions tokens moved through without buying them |
| burned | bytes whose every claiming token was provably destroyed |
| unclaimed | bytes no token claimed: "the majority of every block" |
Claimed bytes are what the three books divide among tokens. Carriage is measured in full and never counted as backing; see carriage and the free-ride index.
The Shared Claim Axiom draws one line sharply: "Unclaimed is not burned. Burned blockspace exited the market; unclaimed blockspace never entered it." Ordinary payments, consolidations and exchange sweeps make up most unclaimed bytes. They were consumed as permanently as any inscription, but no token is attributed to them.
Why it is an identity, not an estimate #
BTI's design asks for a measurement "that does not depend on knowing any protocol: every byte of every block lands in exactly one category, and the categories sum to the block." It explains why: "This is the only way 'account for every byte' is checkable — 'find every carrier' never is."
The layers make it checkable:
- The census (T1) counts every transaction's size and reconciles it against the block's exact serialized size. Its totals are "the ground truth everything above must conserve against".
- The books (T3) are pure arithmetic over the claims, and can be deleted and recomputed.
- The design lists invariants checked on every increment: census buckets sum to block bytes; computed sizes equal those bitcoind reports; the sum of shares equals the sum of claimed bytes in each co-claim group; conservation holds across burns and successions.
So a byte cannot quietly go missing or be counted twice. If it did, a sum would fail.
Unclaimed is an upper bound #
Blockspace Value Theory (§2.2a) adds a caution. A protocol that hides its marker cannot be found by a census of markers, so its bytes look like bytes that belong to nothing. "Unclaimed bytes" is therefore "an upper bound, not a residue", better stated as "not attributable by marker detection". The identity still holds; what moves, as recognition improves, is the line between claimed and unclaimed. See null is never zero.
How block.space shows it #
The front page draws a bar for the latest block in the books and another for the whole written range, with the four figures and their sum printed beneath, so the reader can add them. The renderer compares the four figures with the size. If they differ by a byte or more, it prints a chip after the line: "the four figures sum to …".
A read of the front page at 2026-10-20 09:44 UTC showed both cases worth knowing:
- The latest block, 972,299: claimed 845,128.73, carriage 29,795.27, burned 0, unclaimed 798,540, against a block size of 1,661,109 bytes. The check chip was showing: "the four figures sum to 1,673,464".
- The whole written range, books to block 972,299: claimed 133,742,038,926.52, carriage 12,095,314,148.34, burned 9,449,113.19 and unclaimed 637,459,791,991, printed as summing to 783,306,594,179.05 bytes. The same line said the census had counted 777 GB so far.
On that read the block-level identity did not close, and the site said so in its own words. The documents do not explain the gap, and this page does not guess at it. The point of the identity is that a gap like this is visible to anyone who adds the numbers.
Fractional bytes are expected. Where several tokens share bytes, the axiom divides them, so a token's claimed share need not be a whole number.
Related #
Sources #
- block.space docs: BTI · block.space/docs/bti
- block.space docs: the axiom · block.space/docs/axiom
- The Shared Claim Axiom · block.space/docs/axiom
- block.space docs: Blockspace Value Theory · block.space/docs/bvt
- block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · block.space
- block.space meter and summary APIs · block.space/api/summary
- Blockspace Holdings records
Updated 2026-10-20 · This page as Markdown