block.space · blockspace.wiki

Q: Is the code public?

The code of the sibling explorer, explore.block.space , is public at BLOCKdotSPACE/blockspace-explorer. It is the only one of block.space's two repositories that is public (as of 2026-10-20).

The Bitcoin Blockspace Meter: how much of Bitcoin's blockspace is attributed to tokens, token by token, byte by byte.

Status: Live
Site: block.space
Data: Rankings
Data: Leaderboard
Data: Largest inscriptions
Data: Heaviest tokens
Data: Collections
Data: Tokens
Data: Sync (the three tiers)
Data: Docs
Data: Summary API
Data: explore.block.space
As of: 2026-10-20

What it is #

block.space calls itself "The Bitcoin Blockspace Meter": "how much of Bitcoin's blockspace is attributed to tokens, token by token, byte by byte." the Meter displays the numbers that BTI, the Blockspace Token Indexer, produces. The site states its limits in its own footer: every figure is read live from the books and bounded by the height they are written to; nothing is modelled, extrapolated or filled in; and where a measurement does not exist yet, the site says so instead of showing a zero.

Its home page also carries a summary of Blockspace Value Theory. The site labels that theory as a living document and an untested thesis, and labels BTP and BYTES as drafts describing things that do not exist.

Status #

Live, as of 2026-10-20. The project list marks block.space live and featured.

How it works #

BTI runs in three layers. T1, the byte census, counts every transaction's bytes, weight and fee. T2 records which tokens each transaction touched, under each protocol's own published rules. T3, the books, judges every claimed byte into Book A (the inclusive book), Book B (the regional book) and Book C (the content book), following the partition. Where several tokens share a transaction, its bytes divide among them under the Shared Claim Axiom. Each block's bytes divide into claimed, carriage, burned and unclaimed, which sum to its exact size: this is the site's conservation rule, its trust anchor. The three heights the layers have reached are the frontier.

The rankings read the books and the holders appendix. The largest inscriptions board ranks inscriptions by Book C. The heaviest tokens board ranks tokens by Book A. the leaderboard ranks addresses by their share of backing, with a coverage line for what it cannot place. Every board follows the as of block H caption rule, ranks by backing in bytes or vbytes, and colours families by the five-colour family key, in which the sat family is Ordinal Sats. A collections board was added to the rankings index; on 2026-10-20 it showed nothing ranked yet.

explore.block.space is the sibling explorer, the transaction view of the same chain. Every number on the site is also served as JSON under https://block.space/api/.

Key figures #

The books are written to block 972,299 (as of block 972,299, 2026-10-20 09:30:48 UTC):

Book A: 133.75 GB attributed, 17.21 % of the 777.04 GB of blockspace in the written range;
Book B: 126.98 GB; Book C: 36.38 GB;
126,874,922 tokens across 21 protocols, from 623,681,326 operations, in 614,276 blocks.

By family, Book A: Ordinal Sats 56.13 GB, Runes 33.05 GB, BRC-20 17.49 GB, Alkanes 11.95 GB and Omni 6.66 GB (as of block 972,299, 2026-10-20 09:30:48 UTC).

the frontier (as of block 972,301, 2026-10-20 09:35:17 UTC): the census at block 972,302, claims at 972,301, the books at 972,299, with the chain tip at 972,304. The census has counted 777.04 GB in 1,464,151,063 transactions (as of block 972,302, 2026-10-20 10:16:21 UTC).

The leaderboard ranks 4,491,923 addresses (as of block 972,199, 2026-10-20 09:22:01 UTC). On 2026-10-20 its coverage line read 94.6 % of Book A bytes placed on addresses, with Omni, brc100 and op20 not measured.

Links #

The site: https://block.space
The explorer: https://explore.block.space, code at https://github.com/BLOCKdotSPACE/blockspace-explorer (public)
The documents: https://block.space/docs/bti, https://block.space/docs/rankings, https://block.space/docs/measurements

Glossary #

alkane: A token of the Alkanes protocol: a contract run by a WebAssembly program (alkanes.wasm, "the protocol" in BTI's indexer table) and called through protostones. Its identity is its AlkaneId, written block:tx; DIESEL is 2:0. In BTI every contract whose code ran in a transaction claims that transaction's bytes, as do the alkanes whose balances moved, and metashrew's trace is the record.
anti-battery: Blockspace Value Theory's name for "an instrument that appreciates in energy terms as ambient energy expenditure rises, rather than depleting." BVT proposes that blockspace tokens behave this way. It is part of the theory, not a measured property.
appropriated field: A field every transaction must have anyway, such as an input's nSequence or a transaction's nLockTime, that a protocol overloads as its message. EPOBC writes its colour tag into nSequence; CAT-21 marks a mint with nLockTime 21. The field's bytes exist regardless, so the data-types reference says BTI should attribute zero incremental bytes to the channel. Ruling B43 says such carriers are selected by the protocol writer's own rule, with any divergence named in the decoder.
ARC-20: The fungible token standard of Atomicals. One unit is one sat by protocol design, so the units ride sats; the ticker is the token that claims the bytes. Its identity is the atomical_id, the commit transaction's id followed by the commit output number, and the ticker is an alias. Units spent through wallets that do not know the protocol scramble or burn, which BTI's token table calls "decays by scrambling".
as of block H: The caption rule every block.space ranking follows. H is the one block the holders appendix is synchronised to. Where the ranking was folded at a different height, or the books are written to another, the detail line names those heights too. A number without its height is not shown.
Atomicals container: An Atomicals NFT collection; its members are dmitems. Both are tokens in BTI, each identified by its atomical_id, with names as aliases. NFT binding is outpoint-positional, and the rule forks at block 819,181. The token table counted 1,766 containers and 30,464 dmitems on 2026-08-10. A container's membership is also a group, which aggregates books but claims nothing.
Atomicals realm: One of the Atomicals NFT kinds, with subrealms, identified like every Atomical by its atomical_id. BTI names realms as a coverage gap: its Atomicals indexer held zero realms against about 28 % of the footprint (verified 2026-08-10), so the adapter fails closed and their bytes are claimed by nobody.
attempt: A failed token operation, taken only from the protocol's own failure record. Its bytes attribute to the token it named; failed demand that left no record anywhere is residue, measured but never backing.
attribution: The judged assignment of blockspace to tokens, per transaction. The books are that attribution: for each token a transaction had a consequence for, BTI writes an entry in each of the three books. BTI attributes bytes to tokens, never to addresses; the holder side is the appendix's work.
backing: Blockspace bought for a token's purpose. A transaction is bought for a token when it exists for that token's operation: its inputs and outputs, including the funding input, serve the operation and nothing else. Bytes a token merely rides are carriage, measured in full and never backing.
backing ratio: In the BYTES and BTP drafts, a population's attributed bytes divided by its supply. The one-BYTES-per-byte peg "is not enforced; it is measured" by this ratio, which falls when another claimant is later recognised on the same bytes.
backing succession: A directed burn, drafted as BTP's SUCCEED operation: token A is provably destroyed under its own rules and a successor B is named, and A's backing moves to B. "Backing moves, it is never created." BTP is a draft and does not exist.
bare multisig: A data channel in which a 1-of-3 multisig output's first two "public keys" are data dressed as 33-byte keys, and the third is usually the sender's real key. Each fake key leaves 31 usable bytes, 62 per output. The data-types reference lists it as the carrier of classic Counterparty, classic Stamps and SRC-20, and Omni Class B. A 114-byte output carrying 62 data bytes costs about 1.84 raw bytes per data byte, and the outputs stay in the UTXO set until spent.
Bitcoin Stamp: A Counterparty asset whose description carries a file, written into output-side carriers: bare multisig at first, OLGA P2WSH chunks since block 833,000. In BTI's token table, stamp assets are a subset of XCP assets: the asset is the token and the stamp number is a label on it. Stamp #0, at block 779,652, is an asset issuance whose description holds an 85-byte PNG as base64. A STAMP: payload sent through Counterparty's taproot envelope is picked up by stamps indexers as a cursed (negative-numbered) stamp.
block: A batch of transactions added to Bitcoin's chain in one step. block.space's data-types reference gives a block's size as an 80-byte header, a count of its transactions, and the sum of their sizes. Consensus caps a block at 4,000,000 weight units. The chain is every block from the genesis block forward.
block subsidy: The part of a miner's revenue for a block that is not fees. Blockspace Value Theory (v3.0, July 2026) gives the current block subsidy as 3.125 BTC, says it "currently dominates miner revenue and is identical for every block", and discusses what changes as it approaches zero and fees become the reward.
blockspace: The space in Bitcoin's blocks: the bytes of every transaction a block holds, which is limited by the block weight limit and paid for in fees.
Blockspace Floor Price: In Blockspace Value Theory, the floor price of blockspace tokens, which BVT says is "always below mint cost and always above zero", and is literally the cheapest listing at any moment. The BYTES economics analysis (2026-07-29) proposes retiring the term, because the evidence it examined supports a ceiling at replacement cost but not a floor.
Blockspace Holdings' node and indexers: The Bitcoin full node, the ord server and the BTI indexer that Blockspace Holdings runs itself. block.space, blockspace.to and this wiki read their figures from them, and each figure carries the block height and time it was read.
blockspace token: In Blockspace Value Theory, "any asset whose existence required the permanent consumption of Bitcoin block capacity". BVT calls it a receipt of consumption, "not a claim on capacity". Its examples are runes, BRC-20s, alkanes, inscribed sats and Counterparty assets. The Shared Claim Axiom adds how its backing is measured when several tokens claim the same bytes.
Book A: The inclusive book: the whole transactions bought for a token, shared where shared. When several tokens share a transaction, its bytes divide among them under the Shared Claim Axiom. In the partition it is content + structure + overhead, "bytes bought for you at all", and it is the backing measure. Fees follow Book A.
Book B: The regional book: the measured regions a token's operations wrote, read or moved through, the transaction's relevant structure and nothing else. In the partition it is content + structure, "bytes bought exclusively for you".
Book C: The content book: the artifact bytes alone, the body of the file or message with all framing removed. In the partition it is content only, "the artifact itself".
book entry: BTI's primary record of the books: one row per (transaction, token), storing three disjoint components (content, structure and overhead) plus a fee share. The books are running sums over those components and are never stored themselves.
BRC-20 tick: A BRC-20 token, named by its tick. Its identity is the case-folded tick. A tick is a token because its units transfer by themselves under the ledger's rules; the inscription that carries a BRC-20 operation is not the token, so a BRC-20 mint has two claimants, the sat and the tick, which divide the bytes they share.
BTI: The Blockspace Token Indexer, the instrument that produces every number the block.space meter displays. It counts the bytes, catalogues the operations, and writes the books.
BTP: The Blockspace Token Protocol, a design draft (0.1, 2026-07-29) of "an attribution-layer protocol" that would answer "which token owns which consumed bytes" and make that ownership transactable. It does not exist; its marker encoding is unwritten. See BTP.
burned bytes: One of the four categories every block's bytes divide into: bytes that backed tokens that were provably destroyed.
BVT: Blockspace Value Theory, a living document and an untested thesis (version 3.0, July 2026). It proposes that blockspace tokens "derive monetary value from the scarce resource they permanently consume": Bitcoin blockspace. It holds that they form one commodity market denominated in kilobytes, with a price floor. The text itself says several of its central claims are untested. See Blockspace Value Theory.
BYTES: A draft (0.2, 2026-07-29) of a fungible blockspace token, minted one per byte of a transaction's consumed blockspace: "1 BYTES = 1 byte of consumed blockspace". It was called BITS in draft 0.1. It does not exist. All-caps BYTES is the token; lowercase bytes is the unit. See BYTES.
carriage: Bytes a token rode without buying them. A token rides a transaction when the transaction would have happened anyway, such as a payment or consolidation that carried the token along. Carriage is measured in full and is never backing: carriage answers what moved through the blockspace, backing answers what the blockspace was bought for. It is one of the four categories of the conservation partition.
CAT-21: A protocol whose mint is any transaction with nLockTime = 21. In BTI the cat is a label; the token is the first sat of output 0, a sat in the Ordinal Sats family, catalogued by the ord adapter. The locktime field exists in every transaction, so the data-types reference says the channel costs no extra bytes.
cenotaph: A malformed runestone, as ord decodes it. BTI's case law records a cenotaph as a protocol event, not garbage: a cenotaph that carries an etching still creates the rune, with no terms and no premine, and the protocol's cenotaph rule burns the runes on its inputs. Case 11 of the BTI case studies is one: INSCRIBERUNES, etched at block 840,101 by a runestone with the flaw truncated-field.
claimed bytes: One of the four categories every block's bytes divide into: bytes that back a living token. With carriage, burned bytes and unclaimed bytes they sum to the block's exact size.
claims: T2, BTI's claims layer, which the Sync page calls the catalogue. Adapters read each protocol's records and write claims: token X touched transaction Y at these regions, with labels. Every claim is grounded in a protocol record and owned by a real token. Claims are append-only facts; judgment happens in the books.
clean-mint rule: A rule proposed in the BYTES draft: a mint transaction may carry no data-carrying structure other than the BYTES marker. It would close the concealed co-claim by construction, at the cost that BYTES could not be minted alongside an inscription or other token operation.
coinbase transaction: The first transaction of every block, written by the miner. Its input has no previous output to spend, and its scriptSig is 2 to 100 bytes and must begin with the block height (BIP 34). After segwit it also carries the witness commitment. Miners pay no fee to themselves on it. Sats a coinbase never claimed are lost sats.
concealed co-claim: A risk named in the BTP and BYTES drafts: minting or declaring against a transaction that also carries an unrecognised protocol's token, selling at face value, and leaving the dilution to buyers when that protocol is recognised. BTP answers it with disclosure; BYTES proposes the clean-mint rule.
consensus hash: A hash chained over each committed window of book entries (bti.books_hash, rule R13 of the ruleset). block.space's Sync page shows the latest window, its block range, its entry count and the start of its hash.
consequence principle: The Shared Claim Axiom's rule that a token claims bytes "iff the protocol assigned those bytes a consequence in that token's state": creation, transfer, burn or any state change. The B19 draft (2026-07-31, not applied to the axiom) proposes demoting it to a description; BTI's ruleset v1 treats it as "the description", with a counterfactual test as the gate.
conservation: "Every byte counted exactly once." Each block partitions into four categories, claimed, carriage, burned and unclaimed, that sum to the block's exact size, with no byte in two of them. block.space calls this partition its trust anchor: the categories are complete and exclusive, and anyone can add the numbers.
coverage: The share of Book A bytes the leaderboard can place on addresses. A token whose holders the appendix cannot see contributes nothing to any address, and the coverage line states what share of the books that leaves out. On 2026-10-20 the leaderboard read 94.6 % of Book A bytes, with Omni, brc100 and op20 not measured.
cursor: A saved height that records how far one stage of an index has completed. BTI's three are census (T1), claims (T2) and books (T3); the holders appendix keeps its own, the block H its pages print.
decay-by-amnesia: The Atomicals observation's name for the slow, unintentional burn of ARC-20 tokens: with protocol-aware wallets gone, holders spending the colored sats through ordinary wallets scramble or burn them under the protocol's own rules. The Shared Claim Axiom calls it "blockspace burning continuously at scale".
decentralization constraint: In Blockspace Value Theory, the true limit on blockspace supply: "the largest chain growth compatible with independent verification remaining broadly feasible." BVT calls it a social variable, not a constant, and says the 4,000,000 weight-unit limit is where the community currently believes it binds.
dedicated: Said of a claim whose transaction exists for the token's operation: its inputs and outputs, the funding input included, serve the operation or are change. A dedicated claimant shares the transaction's remainder (overhead) in Book A.
delegate inscription: An inscription that displays another inscription's content. On block.space it is ranked by the bytes it bought, a few hundred, not by the size of what it shows.
dust claim: In the Shared Claim Axiom, "a valid claim whose standalone value sits below the cost and friction of exercising it". The split stays equal on paper, but the market treats the dust claim's share as going to its co-claimant, as with a generic BRC-20 transfer inscription.
edict: The part of a runestone that moves an amount of one rune to a chosen output of the transaction. Units the edicts do not allocate follow the runestone's pointer. Under ruleset v1's fact table, an edict or pointer aimed at a provably unspendable output is a burn.
enabler: A transaction that exists to make another possible: an inscription's commit, a CPFP child, SPOOL fuel. Its bytes join the enabled transaction's pool and surface in Book A only.
envelope: A data carrier inside a taproot script-path witness, holding content as pushes of at most 520 bytes each. ord's envelope carries the marker 6f7264; Counterparty and Counters have envelopes of their own.
etching: The runestone operation that creates a rune. The rune's id is the etching's position on the chain, block and transaction index (block:tx), and its name is an alias. BTI labels an etching mint, because it creates the token; the commit that carries the rune's name commitment is an enabler, and its bytes reach Book A.
explore.block.space: The sibling block explorer of block.space, "the transaction view of the same chain". On block.space, "Explorer" refers only to that site; block.space's own data page is Tokens. Its code is the public repository BLOCKdotSPACE/blockspace-explorer (https://github.com/BLOCKdotSPACE/blockspace-explorer).
fee rate: The fee a transaction pays per vbyte, in sats per vbyte (sat/vB). At a rate f, a witness byte costs f/4 sats and a non-witness byte f sats.
five-colour family key: The colours block.space uses to name token families. The five families with the most blockspace by Book A share when it was chosen on 2026-10-19, Ordinal Sats, Runes, BRC-20, Alkanes and Omni, each have a hue from IBM Carbon's palette; every other family is a neutral grey "Other". Colour names the family, never the rank: a family keeps its colour on every page and in every mode.
free-ride index: The fraction of a token's or protocol's Book A that is its own measured structure, Book B ÷ Book A. A value near 1 means it built its own transactions; a low value means most of its inclusive claim rode payments that were happening anyway.
heaviest tokens board: block.space/heaviest-tokens: the 100,000 heaviest tokens by Book A, every byte of every transaction their operations bought, shared where shared. One row is one token whatever the protocol (a sat, a rune, a BRC-20 tick, a Counterparty asset, an alkane), because the measure is bytes, not kind. Toggles switch to Book B and Book C; each family has a tab.
holder: An owner of a token's units, keyed by scriptPubKey (the address is a rendering of it). Burn addresses are holders too. block.space ranks holders by the blockspace behind what they hold.
inscription: Content bound to a sat by ord, carried in a witness envelope. Under BTI's law the inscription is content, not a token: the inscribed sat is the token that claims the bytes.
label: Under ruling U3, "a token is exactly what can be transferred by itself, proven on chain; everything else is a label on one". A label never claims bytes; it rides a token. Bitmap district numbers and sat names are labels on inscribed sats, a stamp number is a label on a Counterparty asset, SRC-721 is a label on a Counterparty asset, and SPOOL's PIECE is a label.
largest inscriptions board: block.space/largest-inscriptions: the 100,000 largest inscriptions by content bytes (Book C), the bytes the inscription bought, not the bytes it shows. A delegate inscription displays another inscription's content and is ranked at the few hundred bytes it bought. Tabs rank the other content families (Counterparty assets, SRC-20, BRC-20, TAP) by the same book, and "by sat" ranks sats instead.
metaprotocol adapter: The T2 unit that adapts one external metaprotocol indexer to BTI and catalogues the claims of every token that indexer's protocols define; ord's adapter, for example, catalogues inscribed sats and CAT-21 sats. Trust attaches to the adapter.
metaprotocol indexer: An external service that indexes one or more token protocols (ord, Counterparty Core, metashrew, OPI and others) and that a BTI adapter reads for identity and validity. Byte counts never come from it; they come from the raw chain.
metashrew: The indexer that runs alkanes.wasm over the chain and records every Alkanes call as a trace. BTI's metashrew adapter treats it as definitional, because its ruleset is the protocol. The indexer table calls it "routinely the pass's binding clamp": when it lags, the catalogue stage waits for it.
native protocol: A protocol BTI indexes itself, with its own decoder reading the chain from bitcoind and no external indexer between; runes, Omni and BRC-100 are examples. Its trust is "native", zero hops.
not measured: block.space's words for a figure the instrument has not measured: a book not measured for a protocol, a sat the record has not bound to an inscription, a holder the appendix cannot see. Each is written in words. A zero means a measured zero.
OLGA: "Octet Linked Graphics & Artifacts": the Stamps encoding, in use since block 833,000, that chunks file data 32 bytes at a time into the witness-program field of consecutive P2WSH outputs. The "hashes" are raw data, so the outputs can never be spent and stay in the UTXO set. The data sits in output scripts, not in witness data, so no witness discount applies; the data-types reference puts the cost at about 1.34 raw bytes per data byte. The outputs look like real P2WSH, so BTI can only find them through protocol context.
Omni property: A token of the Omni protocol, of the Mastercoin lineage. Its identity is a property id assigned by replaying the protocol; human names such as TetherUS (property 31) are aliases. BTI reads Omni with its own decoder, Class C only, where the message rides an OP_RETURN that begins with the marker "omni".
OP_RETURN: An output whose script begins with OP_RETURN (0x6a), which makes it provably unspendable; Bitcoin Core never adds it to the UTXO set. Its bytes are non-witness, so each costs one vbyte. Consensus has never limited its size; the limits are relay policy, and Bitcoin Core 30.0 raised the default to 100,000 bytes and allowed several such outputs per transaction. The data-types reference lists Runes, alkanes protostones, small Counterparty messages, Omni Class C, Pipe and Charms among its users. BTI attributes the whole output serialization: 8 value bytes, the script length and the script.
OPI: An indexer stack for inscription-borne protocols. BTI counts it as several indexers that sync on their own: opi-brc20 (the BRC-20 ledger), opi-bitmap, opi-sns, and opi-ord (an ord-side extraction). Each has its own adapter, all of trust "derived".
ord: The ordinals indexer and explorer. Its fork, run by Blockspace Holdings, serves blockspace.to and is the definitional source for BTI's inscription-to-sat binding, sat numbers and inscription numbers.
ordinal number: The number ord gives each sat. BTI uses it as the sat token's identity (its canonical_ref); ord's numbering is definitional.
Ordinal Sats: The display name of the sat family on block.space, renamed from "Individual Sats" on 2026-10-19. The key stays sat in every URL, API field and database row. Under it sit Ordinal Inscriptions, bitmap, sat names and CAT-21.
protostone: An Alkanes message carried inside a runestone's OP_RETURN, in the protorunes field (tag 16383), which plain runes ignores. A protostone names a protocol tag, a pointer, a refund output and a cellpack, the call to a contract. One runestone can hold several, and a protostone can point at the next one through a "shadow" output number past the real outputs.
rankings: block.space's boards that rank by bytes, never by count, and the index page at block.space/rankings that lists them with their top three rows. The rankings document describes three measures: inscriptions by content (Book C), tokens by what they bought (Book A), and addresses by the blockspace behind what they hold. On 2026-10-20 the live index lists four boards: the leaderboard, the largest inscriptions, the heaviest tokens and the largest collections, which showed nothing ranked yet.
raw bytes: A transaction's full serialized size, witness included. BTI's books measure raw bytes, with no weight discounting; vbytes are carried beside them as an observable.
Readings A, B and C: The three readings Blockspace Value Theory offers for why the market prices provenance rather than kilobytes. Reading A: the market is immature and kilobyte pricing will come. Reading B: consumption sets the floor, provenance sets the price ("probably the strongest defensible version"). Reading C: consumption is not a value driver and the floor is cultural.
recursive inscription: An inscription that refers to other inscriptions' content instead of repeating it. BVT lists recursion as a way to reduce per-item consumption.
residue: Bytes outside the claim gate: a protocol-shaped operation that no token claims, because the protocol's own record shows no failure to cite (B31) or because no token exists to claim it (U5). Residue is measured demand, never backing, and its rows persist (B31a). A mint naming a tick that was never deployed, or a genesis that the protocol's own rules voided, is residue.
ruleset: BTI's versioned law: five kernel rules (U1 to U5), one division formula, two named judgments and the standing law, plus the adapter roster and source pins. The consensus hash is comparable only within one ruleset version.
sat name: An inscription that names a sat. BTI treats the name as a label on the inscribed sat, not a separately transferable token. The opi-sns adapter catalogues these sats, and block.space shows them as the "Sat names" sub-item of Ordinal Sats.
second-source adapter: An adapter for a second indexer on tokens BTI already catalogues: opi-ord beside ord, brc20-prog beside opi-brc20, alkanes-explorer beside metashrew. Its claims are sightings with no regions, so it writes no bytes and can never create a token. Each pair is diffed per window, and the rows that mean something go to one table of divergences.
share of backing: What an address holds on the leaderboard: a token's bytes under the chosen book, divided among its holders in proportion to the units each holds, over the holder total the source indexer reports, never the protocol's stated supply. An address holding half of a token's units is backed by half of that token's bytes. A non-fungible unit carries all of its token's bytes to its one holder. The share is by units held, not by value.
Shared Claim Axiom: A proposal refining Blockspace Value Theory's definition of a blockspace token: when several tokens claim the same consumed bytes, the bytes are shared among the claims. The axiom's document calls "shared equally" a rule of thumb, not a derived result. In a batch transaction each token owns its own payload bytes, and the shared bytes split in proportion to each token's direct payload. The books apply it when they divide a transaction shared by several tokens.
sighting: A recorded claim with a zero byte-diff, such as a rune drifting through a payment, an inscribed sat being sent, or a second source confirming a token the first already saw. It is kept as a fact and judged as carriage.
the appendix: The holders appendix: one daemon beside BTI's layers that answers who holds each token, how many units, and so how many of the token's bytes back each address. It reads BTI's tables and the protocols' own indexers and never writes BTI's tables. It was seeded once and then advances block by block with one cursor; a protocol it cannot see is "not measured", never 0. It is temporary: it goes when BTI's own custody design lands.
the books: T3, BTI's accounting layer, and what it writes: Book A, Book B and Book C. T3 is a pure function of T1 and T2: it counts the claimants of each byte, splits shared bytes by the ruleset's formula, allocates fees, and writes the book entries and every block's four categories. It can be deleted and recomputed at any time, because the facts live in the layers below it.
the census: T1, BTI's observation layer. One protocol-blind pass over the chain records every transaction's size, vsize, weight and fee, and where the data carriers are (OP_RETURN, witness envelopes, bare multisig, appropriated fields). T1 knows only bytes; its totals are the ground truth every layer above must conserve against.
the frontier: How far BTI has got, as three heights, one cursor per layer: census (T1), claims (T2) and books (T3), always books ≤ claims ≤ census. The site's attribution frontier is the claims cursor, the height every protocol adapter has been searched up to. Every published figure is bounded by the books height; a block counted but not yet written to the books says so rather than showing zeros.
the leaderboard: block.space/leaderboard: every address ranked by the blockspace its tokens are backed by. For each token, its bytes under the chosen book divide among its holders by their share of backing; an address's figure is the sum of its shares. One row is one output script, so a wallet spread over many addresses is many rows. Each address has its own page.
the Meter: The Bitcoin Blockspace Meter, the name block.space gives itself: a measure of "how much of Bitcoin's blockspace is attributed to tokens, token by token, byte by byte." Every number it displays is produced by BTI and is bounded by the height the books are written to.
the one envelope: The one JSON shape every block.space ranking API answers with: as_of (the appendix, books and ranking heights), book, denom, family, sub, population, total, limit, offset, source and rows, with anything particular to one board under extra. It has been the boards' shape since 2026-10-19, so a reader learns one shape for all of them.
the partition: The three disjoint parts BTI stores for each book entry, one entry per transaction and token: content (the artifact body), structure (the other bytes that exist because of the token: carrier framing, protocol outputs, funding inputs) and overhead (the dedicated remainder share, including enablers such as commits and CPFP; zero for riders). The books are sums over them: Book C = content, Book B = content + structure, Book A = all three.
the three books: BTI's three answers to "how many bytes back this token?": Book A (inclusive), Book B (regional) and Book C (content). On every entry C ≤ B ≤ A.
transaction: The unit a block holds: a version, a list of inputs (the outputs it spends), a list of outputs (new amounts and their locking scripts), a lock time and, in a segwit transaction, a witness stack per input. The txid hashes the transaction without its witness; the wtxid hashes all of it.
trust triad: How BTI declares each source's trust: native (BTI itself is the indexer), definitional (the indexer's ruleset is the protocol, as ord is for inscriptions) or derived (the source derives its verdicts from a protocol defined elsewhere, with hops recorded).
two-step transfer: A transfer made in two transactions, as BRC-100's facts in ruleset v1 describe it. First a transfer inscription locks an amount on the inscription's output and has no ledger effect, so BTI writes no tick claim for it. Then any spend of that output is the send, and the output that receives the inscription's sat receives the amount.
unclaimed bytes: One of the four categories every block's bytes divide into: bytes that back nothing. The BTI document says they are the majority of every block.
vbytes: Virtual bytes: a transaction's weight divided by four, rounded up. Every non-witness byte costs 4 weight units and every witness byte 1, so a witness byte counts as a quarter of a vbyte. Fee markets price vbytes. BTI's canonical measure is raw serialized bytes with no weight discounting, and every book entry is kept in both bytes and vbytes.
weight unit: The unit of the block limit (BIP 141): every non-witness byte costs 4 WU and every witness byte 1 WU, so weight = stripped size × 3 + total size. A block may hold 4,000,000 WU.
witness: The segwit section of a transaction (BIP 141/144) holding one stack per input. It is hashed into the wtxid but not the txid, and each of its bytes weighs 1 WU instead of 4.
witness discount: SegWit's 4× weight reduction on witness data. BVT reads it as a price subsidy, not a capacity increase: the same scarce bytes sold at a quarter of the price through one door. Bytes ÷ vbytes measures how much of it a protocol takes.

FAQ #

What does block.space measure? #

How much of Bitcoin's blockspace is attributed to tokens, token by token, byte by byte. BTI counts every byte, catalogues each protocol's operations, and writes three books per token: Book A, Book B and Book C.

Why are there three books? #

They answer three different questions about the same token: how much blockspace was consumed by transactions that touched it, how much was consumed for it, and how much of that is substance. No single number answers all three. On every entry C ≤ B ≤ A.

Why does every figure name a block height? #

Every figure is bounded by the height the books are written to, and every ranking carries as of block H. A number without its height is not shown, and a block counted but not yet in the books says so rather than showing zeros.

Does a zero on block.space mean nothing was there? #

A zero is a measured zero. Anything the instrument has not measured is written as not measured, never as 0.

Is the code public? #

The code of the sibling explorer, explore.block.space, is public at BLOCKdotSPACE/blockspace-explorer. It is the only one of block.space's two repositories that is public (as of 2026-10-20).

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; frontier as of block 972,301, 2026-10-20 09:35:17 UTC; holders as of block 972,199, 2026-10-20 09:22:01 UTC; protocols as of block 972,299, 2026-10-20 09:30:48 UTC. Refreshed hourly.