The three books

BTI gives three answers to the question "how many bytes back this token?", from the widest to the narrowest. They are Book A, the inclusive book; Book B, the regional book; and Book C, the content book. The site documentation says they answer three different questions about the same token: how much blockspace was consumed by transactions that touched it, how much was consumed for it, and how much of that is substance. No single number answers all three, which is why there are three books.

The three books #

• Book A, inclusive. The whole transactions bought for the token, shared where shared. When several tokens share a transaction, its bytes divide among them under the Shared Claim Axiom. Book A is the backing measure.
• Book B, regional. The measured regions the token's operations wrote, read or moved through: the transaction's relevant structure and nothing else.
• Book C, content. The artifact bytes alone: the body of the file or message, with all framing removed.

Every entry is kept in both bytes and vbytes, and fees follow the bytes: a token's share of a transaction's fee follows its share of the transaction's bytes.

How they are stored: the partition #

Each book entry, one row per transaction and token, stores three disjoint components:

The books are running sums over them:

Book C = content
Book B = content + structure
Book A = content + structure + overhead

Because each book adds a non-negative component to the one before, C ≤ B ≤ A holds by construction. The books document notes some consequences. A rider shows itself, because its overhead is 0 and so A = B. Fees follow Book A, one fee share per row. Overhead is always published next to structure, because the two are columns of one row.

Live totals #

Across all protocols BTI measures, the books hold (as of block 972,299, 2026-10-20 09:30:48 UTC):

The share is of the 777.04 GB of chain bytes in the attributed range.

Worked examples #

Bitcoin Stamp #0 (from the BTI case studies, 2026-08-10). A 534-byte transaction that existed for the stamp, with the stamp as its only claimant: content 116, structure 418, overhead 0. So C = 116, B = 534 and A = 534. Overhead appears only when an enabler's bytes join the pool or co-claimants leave a remainder to share.

A 3.9 MB jpeg inscription (case 7). The reveal transaction is 3,911,459 bytes and its body is 3,888,767 bytes. The commit transaction that enabled it, 419 bytes mined 56,161 blocks earlier, joins the pool. So C = 3,888,767, B = 3,911,459 and A = 3,911,878. The commit's bytes reach Book A only.

The first BRC-20 mint (case 10). One 338-byte reveal is claimed by two tokens, the sat and the tick ordi. The tick shares only the envelope it was written in, so it takes 53.5 bytes in Book B. The sat takes 284.5. Book C belongs to the sat alone (71 bytes, the mint JSON), because the inscription is the sat's content.

A pure-ledger transfer (an Omni or Counterparty send). Content is 0, honestly, and structure and overhead carry the backing: a ledger token's bytes are its operations.

Which book a board uses #

The block.space rankings each read one book by default. The largest inscriptions are ranked by Book C, the file's own bytes. The heaviest tokens are ranked by Book A, and their toggles switch to Book B and Book C. The leaderboard divides each token's bytes under the chosen book among its holders.

Why three #

The measurements document gives EPOBC as the case the design exists for. Its colour lives entirely in a field every transaction already has, so its Book B is essentially nothing while its Book A is whole transactions. "The two books give opposite answers, and both are correct." The ratio between them is the free-ride index.

Related #

• BTI, the Blockspace Token Indexer
• The books (T3)
• Carriage and the free-ride index
• Attribution and the Shared Claim Axiom
• Book A
• Book B
• Book C

Sources #

1. block.space docs: BTI · block.space/docs/bti
2. block.space docs: rankings · block.space/docs/rankings
3. block.space docs: measurements · block.space/docs/measurements
4. block.space meter and summary APIs · block.space/api/summary
5. Blockspace Holdings records