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.

T3 is the third of 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 rows and aggregates, and emits the 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 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.

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 is content, 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.

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, so two operators running the same ruleset can agree, or find the window where they stopped agreeing.

Live figures #

The books cursor stood at block 972,299, behind the claims cursor at 972,305 (as of block 972,305, 2026-10-20 10:48:22 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 #

Live figures: books as of block 972,299, 2026-10-20 09:30:48 UTC; frontier as of block 972,305, 2026-10-20 10:48:22 UTC. Refreshed hourly.