blockspace.wiki

Claims (T2)

BTI's second layer: metaprotocol adapters and BTI's own decoders turn each protocol's records into append-only facts about which token touched which bytes.

T2 is the second of BTI's three layers: the catalogue stage. It converts protocol knowledge into facts: token X touched transaction Y at these regions, with this consequence. It reads T1's observations and each protocol's own record, and it writes claims. Judgment, meaning who shares what with whom and what a byte is worth, happens above it, in T3. In the T2 document's words, "T2 records".

What T2 writes #

  • token: anything separately ownable. Its identity is the protocol's own primary immutable id; every human name is an alias.
  • claim: token, transaction, source, op label, dedication and kind of consequence. The op label is one of mint, transfer, inscribe, burn or other.
  • claim region: the byte intervals the claim touched. A region's bytes and vbytes both follow from its coordinates. The adapter declares what its token touched, never what is shared; sharing is found later, by overlap.
  • attempt: a failed token operation, taken only from the protocol's own failure records.
  • enabling link: commits, CPFP children and fuel. T3 splits the enabler's bytes across the transactions it enabled.
  • supply delta: mints, burns and expiries, feeding the running supply.
  • adapter state: what each unit needs at one height to process the next, saved in the same database transaction as the facts it produced.

Claims are append-only. Every claim is recorded (rule B20) and the accounting layer alone judges.

What makes a claim #

Ruleset v1's claim gate, U5, is conjunctive. A byte attributes where three things hold together:

  1. U1, the counterfactual. Remove the token, hold everything else fixed, and the bytes that change are the token's.
  2. U2, the record. Every assertion is grounded in something the protocol produced. Where a protocol's reference writer and reader disagree, the writer's output is the record.
  3. U3, transferability. A token is exactly what can be transferred by itself, proven on chain; everything else is a label on one. An inscription is content and the sat is the token; a bitmap district is a label on an inscribed sat.

Bytes outside the gate are typed residue or protocol consumption: measured demand, never backing.

Adapters, decoders and indexers #

Since an architecture ruling of 2026-08-10 there is one adapter per metaprotocol indexer. A metaprotocol adapter adapts one external indexer to BTI and catalogues the claims of every token that indexer's protocols define. The ord adapter, for example, catalogues inscribed sats and CAT-21 sats. Protocols BTI indexes with no other indexer are native: BTI itself is the indexer, through its own decoders.

The roster, as amended on 2026-08-11, is 17 modules across 14 metaprotocol adapters plus 13 native protocols and one structural unit (cpfp), 31 units in all.

kind examples source
metaprotocol adapters ord (inscriptions, cat21), opi-brc20, opi-bitmap, opi-sns, counterparty, stamps, counters, countersproto, metashrew (alkanes), tap, atomicals (ARC-20 and NFTs) the external indexer each one adapts
second-source adapters opi-ord, brc20-prog, alkanes-explorer a second indexer on tokens the roster already catalogues; sightings only, never new tokens
native decoders runes, omni, openassets, coinspark, colu, epobc, spool, charms, pipe, brc20-opreturn, op20, mezcal, brc100 BTI's own decode of the chain
structural unit cpfp writes enabling links for same-block children that fee-bump a claimed parent

Each source declares its trust in the trust triad: native (BTI parses the chain itself, zero hops), definitional (the indexer's ruleset is the protocol, as ord is for which sat an inscription is bound to, and metashrew for alkanes) or derived (the source derives its verdicts from a protocol defined elsewhere, with the hops recorded). The design calls every derived source a debt: a place where "anyone can re-derive the state" is not yet true.

One rule holds across the whole fleet: bytes never come from an indexer. Indexers supply identity and validity only; every byte quantity comes from the raw chain through BTI's own region grammar.

How the stage runs #

Per window, the stage clamps its upper height to the lowest tip among the sources in play, runs every unit in roster order, and then diffs each first-source and second-source pair over exactly that window. Only then does the claims cursor move. An unreachable source is a refusal, never a zero, so a lagging source stalls the stage and shows in its status. An interrupted window is abandoned whole and rerun from the cursor.

One protocol's claims can be rebuilt alone: delete that unit's claims and state, rerun it over T1's range, and re-account the span. Other units' facts and T1 are left untouched.

An example of a co-claim #

Case 3 of the case studies is one reveal transaction at block 905,952 claimed by three tokens: an inscribed sat, a BRC-20 tick and a rune. Case 10, the first BRC-20 mint, has two: the sat (op inscribe, dedicated) and the tick ordi (op mint, regions limited to the envelope it was written in). T2 records both claims and their regions; it is T3 that finds the 107-byte envelope span is shared and divides it.

Live figures #

The claims cursor stood at block 972,305 (as of block 972,305, 2026-10-20 10:48:22 UTC). The books cover 21 protocols and 126,874,922 tokens across 623,681,326 operations (as of block 972,299, 2026-10-20 09:30:48 UTC).

Sources #

  1. block.space meter and summary APIs · block.space/api/summary
  2. Blockspace Holdings records

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.

Updated 2026-10-20 · This page as Markdown