BTI, the Blockspace Token Indexer

The instrument behind every block.space number: it counts every byte, catalogues every token operation, and writes three books of attribution.

BTI, the Blockspace Token Indexer, is the instrument that produces every number the block.space meter displays. In the words of its site documentation it does three things: it counts the bytes, it catalogues the operations, and it writes the books. This page describes what it does, the design it follows and its three layers.

What it does #

It counts the bytes. BTI walks every Bitcoin transaction from the genesis block forward and records each one's raw size, virtual size, weight and fee, per transaction and per block. Nothing is sampled or estimated: the per-transaction counts reconcile against each block's exact serialized size. As of the latest reading it had counted 1,464,151,063 transactions and 777.04 GB of chain bytes (as of block 972,302, 2026-10-20 10:16:21 UTC).

It catalogues the operations. Each token protocol writes its operations into transactions. BTI reads each protocol under that protocol's own published rules and records, per transaction, which tokens the transaction had a consequence for: what was created, moved or destroyed. It indexes 21 protocols and knows 126,874,922 tokens across 623,681,326 operations (as of block 972,299, 2026-10-20 09:30:48 UTC).

It writes the books. For each token a transaction touched, BTI writes three parallel entries: Book A (inclusive), Book B (regional) and Book C (content). On every entry C ≤ B ≤ A. Book A totals 133.75 GB, Book B 126.98 GB and Book C 36.38 GB (as of block 972,299, 2026-10-20 09:30:48 UTC). See the three books.

The design: what BTI must answer #

BTI's design document (draft 0.2, 2026-08-06) derives the indexer from the theory documents alone, Blockspace Value Theory, the Shared Claim Axiom, BTP and BYTES, and treats the first build as evidence rather than a template. It lists the questions the indexer must answer. Among them:

Backing per token, in raw bytes, for every token.
The states of every byte: claimed, unclaimed or burned, per block and cumulatively.
Instrument honesty. A marker census cannot see a protocol that hides its marker, so "unclaimed" is an upper bound, and BTI must publish its own blind spots.
Raw bytes are the measure; vbytes are an observable. The books apply no weight discount, but both measures are carried everywhere, because their ratio is the witness discount.
Determinism. BTI's output is meant to be a pure function of the chain and a versioned ruleset: state = F(chain[0..h], ruleset). The design calls this the single strongest constraint on the whole design.

The three layers #

The pipeline runs, in the layers document's words: "T1 sees bytes → T2 records claims → T3 judges worth."

T1, observation. One protocol-blind pass over the chain: every transaction's size, vsize, weight and fee, and the byte census of where data carriers sit. See the byte census.
T2, claims. Adapters and BTI's own decoders turn protocol records into append-only facts: token X touched transaction Y at these regions. See claims.
T3, accounting. A pure function of T1 and T2 that divides shared bytes, allocates fees, writes the book entries and emits the consensus hash. See the books.

The layering law: observation writes no protocol knowledge, claims write no arithmetic, and accounting writes no facts. Each layer can be checked against the one below it. A wrong census number is caught against bitcoind, a wrong claim against the protocol's record, and a wrong book by recomputing it.

The engine #

The design settles on one process that advances in increments. Each increment runs observe, catalogue and account inside one database transaction, and each stage has its own cursor: census, claims and books, with books ≤ claims ≤ census. See the frontier. The decisions recorded in the design: Postgres for storage, Go for the engine, and 5,000-block increments as the starting size.

Each tier can be rebuilt from the tier below it on its own. T3 can be recomputed from T2 when a formula changes. One protocol's T2 can be redone from T1 when a protocol fact changes. T1 stands beneath every ruleset; it is re-observed only for a bug in observation itself.

Adapters are pure incremental state machines: no replay, bounded memory, isolation (an adapter records what its own token claimed and stops), and keys that admit several assets on one output and several sources for one token. An unreachable source is a refusal, never a zero, and no increment may pass the height of any source it depends on.

The law it applies #

Attribution follows ruleset v1: five kernel rules (U1 to U5), one division formula, two named judgments and a table of protocol facts. The kernel's first rule is counterfactual: a byte is attributed to a token if the token's involvement is why the byte exists, or why it has the value it has. The axiom behind it is covered in attribution and the axiom.

Every byte counted once #

Each block's bytes fall into four categories, claimed, carriage, burned and unclaimed, which sum to the block's exact size with no byte in two of them. The site documentation calls this partition the meter's trust anchor. See conservation.

Names #

On this wiki the first version of BTI is called BTI-old. The documents on this page describe the current design.

Sources #

Live figures: books as of block 972,299, 2026-10-20 09:30:48 UTC; census as of block 972,302, 2026-10-20 10:16:21 UTC. Refreshed hourly.