The byte census (T1)

T1 is the first of BTI's three layers: observation. It makes one pass over the chain and records, for every transaction, its size, vsize, weight and fee, plus the byte census: where the data carriers are. T1 knows only bytes. In the layers document's words, its totals are "the ground truth everything above must conserve against."

What it records #

The design document names three products from one decode of each block:

• the ledger: per transaction, its size, vsize, weight and fee. Fees need the outputs being spent and sizes do not, so the two may advance at different speeds, but a block is not observed until both exist.
• the census: the same bytes by kind, such as frame, outpoints, signatures, data payload and unexplained. Unexplained is where the instrument says what it could not account for, transaction by transaction.
• carriers: data-carrying structures recognised by their shape, such as an envelope, an OP_RETURN output, bare multisig or an appropriated field, each recorded with its prefix, whatever it is. This is how protocols nobody named get found.

Protocol-blind by law #

The design says observation is protocol-blind "by law, not by convenience". Its facts must survive every future change in what BTI knows about protocols, because recognition can arrive years later and must find the observations already waiting. So T1 records what the instrument saw, never what it inferred.

Blockspace Value Theory (§2.2a) explains why this matters. A census that looks for markers cannot see a protocol that hides its marker: Counterparty encrypts its payloads, and a 2026-08-04 byte scan for SRC-721 found zero occurrences while Counterparty's own API showed mints live. BVT concludes that "unclaimed bytes" is therefore an upper bound, and that it should be stated as "not attributable by marker detection", a claim about the instrument rather than the chain.

The checks #

T1 is checked against bitcoind. The design lists invariants that can fail on every increment: the census buckets sum to the block's bytes, and BTI's computed sizes equal bitcoind's. The case studies (2026-08-10) cross-check T1 numbers against raw transaction hex through an independent parse that asserts two identities: the components sum to the size, and base × 3 + size = weight. The data-types reference gives the block-level check: a block's size is the 80-byte header plus the transaction-count varint plus the sum of the transaction sizes.

A small detail of the store, from the case studies: the per-transaction census table keeps rows only where unexplained is above zero, so a missing row means "unexplained = 0, by construction".

An example #

Case 10 of the case studies, the first BRC-20 mint at block 779,833, as T1 sees it: size 338, vsize 155, weight 620, fee 4,650. The components are a 10-byte frame, a 2-byte witness frame, a 41-byte input, a 43-byte output and a 242-byte witness. The witness holds a 64-byte signature, a 141-byte tapscript and a 33-byte control block. Inside it T1 finds an ord envelope (marker 6f7264) whose body is 71 bytes of text/plain JSON. Nothing in this is about BRC-20; that is T2's business.

Live figures #

The census had walked 972,303 blocks, holding 1,464,151,063 transactions, 777.04 GB of raw bytes and 567.70 GB of vbytes (as of block 972,302, 2026-10-20 10:16:21 UTC). The census cursor stood at block 972,302, against a chain tip of 972,304 (as of block 972,301, 2026-10-20 09:35:17 UTC).

What the census has shown #

The July 2026 measurement run, from block.space's measurements document, gives data payload as a share of all block bytes:

The document reads the fall from 45.4 % to 31.9 % as runes replacing inscription bodies with 20-byte runestones: a protocol getting more efficient reduced the chain's data share while increasing the number of tokens.

Its place in BTI #

T1 is the one tier that never versions. Rulesets and adapters come and go above it, and it is re-observed for exactly one reason: a bug in observation itself. Claims (T2) read its observations; the books (T3) must conserve against its totals.

Related #

• BTI, the Blockspace Token Indexer
• Claims (T2)
• The books (T3)
• The frontier and "as of block H"
• Weight units and vbytes
• the census

Sources #

1. block.space docs: BTI · block.space/docs/bti
2. block.space docs: data types · block.space/docs/datatypes
3. block.space docs: measurements · block.space/docs/measurements
4. Blockspace Value Theory · block.space/docs/bvt
5. block.space meter and summary APIs · block.space/api/summary
6. Blockspace Holdings records