# The books (T3)

BTI's third layer: a pure function of T1 and T2 that divides shared bytes among tokens, allocates fees and writes the book entries, the aggregates and the consensus hash.

URL: https://blockspace.wiki/concepts/books-t3/

[T3](https://blockspace.wiki/glossary/the-books/) is the third of [BTI](https://blockspace.wiki/glossary/bti/)'s three layers: accounting. It is a pure function of T1 and T2. It counts claimants per byte interval, applies the dedication gate, splits remainders by the division formula, allocates fees, writes the [book entry](https://blockspace.wiki/glossary/book-entry/) rows and aggregates, and emits the [consensus hash](https://blockspace.wiki/glossary/consensus-hash/). The layers document's phrase for it: T3 "judges worth".

## Derived, never facts

The design document is firm that this layer carries no information of its own. It exists because the questions are expensive, not because they are primitive. It can be deleted and recomputed at any time, and the design calls that "a design invariant, not an optimization note". Rebuilding T3 alone, from T2, with T2 and T1 untouched, is the cheap repair, and it is what a change of formula or judgment costs.

## The division formula

Ruleset v1, §6:

```
pool  = tx.size + Σ enabler shares   (an enabler splits across the
                                      transactions it enabled, by size)
B_i   = the measured byte-diff (the claim's declared regions alone)
dedicated:  A_i = B_i + (pool − ΣB) / n_ded
riding:     A_i = B_i
fee_i = poolFee · A_i / pool
```

- **n, the number of claimants on a byte, comes from the claim set**, never from an adapter. The design notes it can rise years later, when recognition improves, and claim facts never rewrite.
- **Division counts tokens, never rows.** The design calls a divisor that counts region rows the first build's most dangerous latent bug: it would silently halve co-claimed bytes the moment a second source sighted the same token.
- **Enablers enter the pool**, so their bytes surface in [Book A](https://blockspace.wiki/glossary/book-a/) and nowhere else.
- **Fees exist at pool scope** and follow Book A.
- **Riding claims** keep A = B; by default a claim with no dedication is carriage and is zero in all books. See [carriage and the free-ride index](/concepts/carriage-and-the-free-ride-index/).

## What a book entry holds

One row per transaction and token, with three disjoint components, content, structure and overhead, in both bytes and vbytes, and a fee share. [Book C](https://blockspace.wiki/glossary/book-c/) is content, [Book B](https://blockspace.wiki/glossary/book-b/) adds structure, and Book A adds overhead. The books are a view over the row and are never stored. Because the ordering C ≤ B ≤ A follows from addition, the check that used to police it was retired. What remains is one write rule: components are non-negative, and a row with content above zero has its structure measured. See [the three books](/concepts/the-three-books/).

## A worked division

Case 5 of the BTI case studies is an alkanes swap at block 911,180: a 450-byte transaction whose single protostone touched five alkanes: three contracts it invoked (a router and pool contracts) and the two tokens swapped. All five claims are dedicated and declare identical regions covering the whole transaction.

- Every byte has n = 5, so each token's Book B is 450 ÷ 5 = 90 bytes.
- Content is 0 everywhere; contract calls carry no envelope.
- The remainder is 0, so each Book A is also 90 bytes.
- The 329-sat fee divides the same way: 65.8 sats each.
- Conservation: 5 × 90 + 0 = 450, the pool.

The case study's comment: a divisor that counted rows instead of tokens would have been invisible here in every aggregate except the conservation line.

## The checks

The design lists invariants checked on every increment. The census buckets sum to the block's bytes. The sum of shares equals the sum of claimed bytes in each co-claim group. Supply is conserved across burns and successions. Each case study ends with the same kind of conservation line: the tokens' Book A plus any unattributed remainder equals the pool, with every byte placed.

## Aggregates and the hash

T3 keeps running sums per token, per protocol and per block, updated as each window lands rather than rescanned. Each committed window's rows are chained into the books hash, the [consensus hash](https://blockspace.wiki/glossary/consensus-hash/), so two operators running the same ruleset can agree, or find the window where they stopped agreeing.

## Live figures

The books [cursor](https://blockspace.wiki/glossary/cursor/) stood at block 972,299, behind the claims cursor at 972,315 (as of block 972,315, 2026-10-20 12:10:25 UTC). The books then held 133.75 GB in Book A, 126.98 GB in Book B and 36.38 GB in Book C, over 126,874,922 tokens (as of block 972,299, 2026-10-20 09:30:48 UTC).

Sources:

- Blockspace Holdings records
- block.space meter and summary APIs · https://block.space/api/summary

Live figures: books as of block 972,299, 2026-10-20 09:30:48 UTC; frontier as of block 972,315, 2026-10-20 12:10:25 UTC

Updated: 2026-10-20