# The byte census (T1)

BTI's first layer: one protocol-blind pass recording every transaction's size, vsize, weight and fee, and where in each block the data sits.

URL: https://blockspace.wiki/concepts/byte-census-t1/

[T1](https://blockspace.wiki/glossary/the-census/) is the first of [BTI](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/raw-bytes/), 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](https://blockspace.wiki/glossary/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,319 blocks, holding 1,464,231,426 transactions, 777.07 GB of raw bytes and 567.72 GB of vbytes (as of block 972,318, 2026-10-20 12:15:32 UTC). The census [cursor](https://blockspace.wiki/glossary/cursor/) stood at block 972,318, against a chain tip of 972,320 (as of block 972,315, 2026-10-20 12:10:25 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:

| height | share | what was happening |
|---|---|---|
| 450,000 | 0.0 % | pre-ordinals: the chain is payments |
| 600,000 | 9.2 % | Omni, Counterparty, early OP_RETURN |
| 788,000 | 13.4 % | BRC-20 mania |
| 833,000 | 45.4 % | the peak: nearly half of Bitcoin is payload |
| 850,000 | 31.9 % | recession after runes moved to OP_RETURN |

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)](/concepts/claims-t2/) read its observations; [the books (T3)](/concepts/books-t3/) must conserve against its totals.

Sources:

- Blockspace Holdings records
- block.space docs: BTI · https://block.space/docs/bti
- block.space docs: data types · https://block.space/docs/datatypes
- block.space docs: measurements · https://block.space/docs/measurements
- Blockspace Value Theory · https://block.space/docs/bvt
- block.space meter and summary APIs · https://block.space/api/summary

Live figures: census as of block 972,318, 2026-10-20 12:15:32 UTC; frontier as of block 972,315, 2026-10-20 12:10:25 UTC

Updated: 2026-10-20