Glossary · blockspace.wiki

Each term has its own page for linking. Project pages list the terms that belong to them.

Project

A B C D E F H I L M N O P R S T U V W X

A #

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".
Architecture Decision Record: How the Degent code makes a significant decision: a new component or service, a change of data flow, a signing or custody model, security architecture, a breaking contract change, or a new dependency on a service the project does not run. An ADR is proposed in a pull request under docs/adr/, open for comment for at least 5 business days, and accepted by the owning team or teams. An accepted ADR is never edited; a later ADR supersedes it.
archival node: A Bitcoin full node that keeps every block, as opposed to a pruned node, which discards old block data.
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.
Atelier: A section of the degent.club website and a service in the Degent code. Its code renders the Degent frame and placard. The code is Apache-2.0, but images it produces that carry the frame and placard may not be published, sold, inscribed or minted as Degents or under the club's marks.
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.

B #

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.
batch: Several inscriptions written by one commit transaction and one reveal transaction, sharing their fixed cost.
Bitbar: A bar-shaped inscription on Bitcoin whose size is its name: 1 kB (exactly 1,024 bytes), 64 kB, 128 kB and 256 kB. The 1 kB Bitbar is the hero of blockspace.holdings, "Exactly 1,024 bytes on Bitcoin Mainnet", and the page's copy of it must stay exactly 1,024 bytes.
Bitcoin L1: Bitcoin's base layer: the blockchain itself, not a sidechain or second-layer network.
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.
Bitmap: In bitmap.holdings' own words: "Bitmaps turn each Bitcoin block into a piece of digital land. Each Bitcoin block becomes a coordinate. Each coordinate becomes ownable. Each ownership becomes programmable."
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 asset: What Blockspace Holdings acquires and holds, in its tagline: "We acquire & Hodl Blockspace Assets." Its holdings list the Bitbars, Space Blocks and the Litebars.
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: The holding company behind block.space and every project listed on block.space/projects; its own page is blockspace.holdings. The owner named it "Blockspace Holdings" on 2026-10-20.
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 Labs: The research and development arm of Blockspace Holdings, at blockspacelabs.com: "research and development for Bitcoin blockspace". blockspace.to is a Blockspace Labs product.
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.
bounty: On the Devcash bounty platform, a developer task posted with a reward in ETH or DEV. Posters "crowdsource developer talent"; hunters "perform developer tasks, earn DEV".
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.

C #

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.
citation: What a writer keeps after writing an inscription: its inscription id, block, content type, length and SHA-256 hash.
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.
confirmation: A block containing the transaction. Each later block adds one more.
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.
content type: The label stored with a payload (such as application/pdf) that tells readers how to open it.
counter: A Bitcoin Counter is "a numbered file event": a file committed to Bitcoin as the description of a Counterparty asset, carried in a Counterparty taproot envelope, and given a global, gap-free number in order of creation, from #0. It passes two tests at once: the bytes are the description of a valid Counterparty issuance or fairminter deploy, and they reached the chain inside witness data. Either test alone is nothing.
Counterparty: The protocol whose assets carry counters. For counters it supplies identity, ownership, naming, transfer and, since its v11 taproot envelope, the content itself. Counterparty Core is its node software. It decides message validity, asset identity, ownership and content; the counters indexer never reimplements that consensus. ("Bitcoin Core" is the separate Bitcoin node; the counters docs always name the two in full.)
counterparty + ord: The style of Counterparty taproot envelope that Counterparty Core emits with inscription=true: the same envelope plus the ordinals framing, with every field an official ordinals tag and tag 7 carrying xcp. Its reveal creates two independently ownable assets: the Counterparty asset, and an ordinals inscription on its own output. The stored value is counterparty/ord. The first five counters are all this style.
Counterparty DEX: Counterparty's on-chain order book. An order gives one asset to get another, with BTC allowed on either side; a non-BTC give is escrowed until the order fills, expires or is cancelled, and a matched BTC leg must be paid within about 20 blocks. Counterparty has one trade message, and consensus alone decides whether it fills against the book or a liquidity pool.
Counterparty taproot envelope: Counterparty v11's witness-data encoding, active from block 902,000: an OP_FALSE OP_IF … OP_ENDIF tapscript revealed by a commit and reveal transaction pair. The message, an asset's description included, travels as data pushes in the reveal's input-0 witness; the output side holds only the literal CNTRPRTY OP_RETURN marker. Two styles exist, the size-optimised counterparty native envelope and the counterparty + ord envelope, and both carry counters equally.
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.
cursed inscription: An inscription ord numbers apart from the blessed ones, with a negative number (such as #−10,508). ord /status counts the two separately.
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.

D #

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.
Decentralized Gentlemen Club: The collection and club at degent.club. In its own words, "a community-driven 10K ordinal collection of unique Pepes in tuxedos, built on Bitcoin". The 10K is its size when fully minted, not a count: 10,000 when fully minted, 4,112 inscribed (as of 2026-09-25 23:24:51 UTC).
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.
Degent: A Degent is an inscription in the Decentralized Gentlemen Club collection at degent.club. The club's minting rules (on its site as captured in September 2026) ask for a square JPEG of at least 200KB showing a Pepe character in a tuxedo with a mandatory bowtie, framed, with a placard that says "DEGEN", "DEGENT" or "REGEN" (the frame and placard).
Degent mint: degent.club's "automated, non-custodial mint that lets anyone add a Degent, up to a block-sized one, from the website with no human in the loop", at degent.club/mint. Its service, degent-mint, holds the order state machine, the art review, a policy signer and lanes; degent-mint-sdk holds the rules, domain types and a typed API client. The rules set no cap per wallet: "Mint as many as you want".
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.
Devcash: "Cash for the developer economy": DEV, an ERC-20 token, "the official currency of Blockchain Developers United", with a bounty platform and a decentralized exchange at devcash.dev.
dispenser: A Counterparty offer that escrows an asset and vends it for BTC at a price per lot that cannot change while it is open. A purchase needs a Counterparty dispense message: since block 866,000 a bare BTC payment to a dispenser address buys nothing. A closed dispenser keeps vending for about 5 blocks, then the unsold stock returns to the closer.
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.

E #

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.
edition: One day of blockspace.news. A snapshot of block.space's public API is saved each day at 00:15 UTC; an edition is the difference between that day's snapshot and the one before. A rewound or rewritten set of books is reported as "no comparison", never as a negative.
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).

F #

fairminter: A Counterparty message that deploys a fair-minted asset. A fairminter deploy whose description is a file is itself a counter; the fairmints that follow never are, so "a fair-minted collection gets one counter at deploy". Since Counterparty Core v11.2's fairmint_pool gate (mainnet block 961,100) a fairminter can seed a liquidity pool at soft cap with every satoshi it raised, minting the LP tokens to the unspendable address.
fee floor: The lowest fee rate a node will relay and keep in its mempool, set by minrelaytxfee. Bitcoin Core's default floor is 1 sat/vB; Blockspace Holdings' own Bitcoin node runs with minrelaytxfee=0.
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.
frame and placard: The ornamental gold picture frame and the placard reading DEGEN, DEGENT or REGEN that every Degent carries. The club's minting rules require it ("Must be framed and include a placard"), and the Degent mint's automated art review checks it. As a visual design and trade dress it is not licensed (all rights reserved), even where the code that draws it is Apache-2.0.
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.
full-RBF: A relay policy setting of a Bitcoin node (fullrbf), about replacing unconfirmed transactions. Blockspace Holdings' own Bitcoin node runs with it on; the Labs study "Full-RBF in practice" proposes to count the replacements its mempool sees.

H #

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.
Hodl: The deliberate spelling in Blockspace Holdings' tagline, "We acquire & Hodl Blockspace Assets." The spelling is fixed: every Blockspace Holdings property keeps the "Hodl" wordplay.
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.

I #

indexer: Software that reads every block and builds a searchable view of it. ord is the indexer for inscriptions.
initial bounty offering: Devcash's way of allocating DEV, in its own words "inspired by ICO. Instead of money, you put your skills and time to build awesome things to get Devcash." It runs on the Devcash bounty platform.
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.
inscription id: The reveal's transaction id, then the letter i, then the inscription's position in that transaction.

L #

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.
lazy consensus: The rule for day-to-day changes in the Degent code's governance. Maintainers seek consensus in the pull request review, and silence after a reasonable review period is consent. The owning team's approval plus green CI is enough to merge.
liquidity pool: A constant-product reserve pair on Counterparty, with its own LP token, native since Counterparty Core v11.1's amm_pools gate. There is no "create pool" message: the first deposit creates the pool, and its two amounts set the opening price. counters.fun lists the counters that have pools against XCP.
Litebars: Litecoin inscriptions. Their collection page calls them "ordinal inscriptions that represent Litecoin blockspace, measured in kilobytes". Their cover is a silver 1 kB litebar of exactly 1,024 bytes, the Bitbar's design in silver. The Labs site lists them as held by the company.
Litepedia: The project at litepedia.space: "Wikipedia on Litecoin. The encyclopedia uploaded to Litecoin, where anyone can pay LTC to make an edit, with a robust editing system." Not yet built.
lost sats: Sats that coinbase transactions never claimed, so they exist in no output. ord's /status counts them.
LP token: The token a Counterparty liquidity pool gives its depositors. Burning LP tokens takes both assets back pro rata. LP tokens sent to the unspendable address lock the liquidity, and counters.fun shows that lock as the share of LP supply at the burn address.

M #

machine surfaces: The files a site publishes for agents and crawlers, built from the same source as its pages: sitemap.xml, robots.txt, llms.txt and llms-full.txt, JSON-LD, an Atom feed and /.well-known/blockspace.json. blockspace.wiki is the pilot site for them.
mempool: The waiting room of unconfirmed transactions that miners choose from.
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.

N #

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.
non-custodial: Never holding the user's funds or keys: the user's own wallet funds and signs.
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.

O #

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.

P #

payload: The file being written into an inscription.
pointer counter: A counter whose content is a single URI token (ipfs:, ar://, http(s)://) rather than a file. It is a full, valid counter, but only the pointer is on chain. A counters server shows the pointer text and never fetches it; counters.fun does not display pointer counters at all.
price per KB: counters.fun's price against on-chain size: the market cap spread over the bytes the asset carries on chain, summed over every counter on it, so price × circulating supply ÷ KB, in the price's own unit. Every pooled card, dispenser card and DEX row on counters.fun shows it.
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.

R #

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.
reinscription: New content attached to a Counterparty asset you own: a Counterparty reissuance with a fresh taproot-carried description (quantity 0, on counters.fun's mint page). It is numbered like any other counter. Numbering is per event, so an unlocked asset collects a new counter each time; its lowest-numbered counter is its original, and no earlier counter is erased.
reorg: When a competing chain replaces recent blocks, undoing their confirmations.
replacement ceiling: A term proposed in the BYTES economics analysis (2026-07-29): replacement cost in its role as an arbitrage-enforced upper bound on the price of reproducible blockspace assets. It would replace BVT's "mint cost anchor". Non-reproducible (provenance) assets have none. Trough parity is the replacement cost at the cheapest fee window an arbitrageur can wait for.
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.
reveal transaction: In a Counterparty taproot mint, the commit transaction pays to a taproot address committing to the envelope tapscript. The reveal transaction spends that output by the script path, exposing the envelope in input 0's witness, and carries an OP_RETURN holding only the literal marker CNTRPRTY. The reveal is the transaction Counterparty parses and the one a counter is keyed to. An unrevealed commit is nothing.
rolling hash: How independent counters indexers check that they agree. Each counter extends a SHA-256 chain over its number, transaction, position, kind, asset and content hash, seeded from the tag counters:v3:bitcoin-mainnet:902000. Two indexers agree on the whole history if and only if their latest rolling hash matches. It is not BTI's consensus hash.
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.
rune: A token of the Runes protocol, whose messages (runestones) are carried in an OP_RETURN output tagged OP_13. ord indexes them: its /status counts the runes.

S #

sat: One hundred-millionth of a bitcoin, the unit fees are paid in.
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.
sats per kB: The price blockspace.markets ranks listings by: a listing's asking price in sats divided by the blockspace block.space's books attribute to the asset (Book A), per kilobyte (1 kB = 1,000 B). A listing is an offer, not a sale.
Scribbit: The product at scribb.it, a project of Blockspace Holdings: a planned way to write a document or record directly into Bitcoin. The app is coming soon (as of 2026-10-20); its features come from the owner's design brief and are not yet confirmed.
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.
SHA-256: A cryptographic hash. The same file always gives the same 64-character hash, and any change gives a different one.
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.
Space Blocks: Inscription #83,851,681: one JPEG, 1537 × 1537, of 1,047,584 bytes, 99.9 % of a 1,048,576-byte (1 MB) block, inscribed in block 881,188. Its own line: "One image that fills a 1 MB block". The image shows a glowing cube of circuitry marked 1MB floating in space, captioned SPACEBLOCK.
spent sats: The sat ranges of outputs that have already been spent. The ord fork behind blockspace.to runs with --index-spent-sats, so a spent output still answers with its sat ranges; an ord without that flag does not.
spiderweb: The web of links across the Blockspace Holdings properties, "a searchable and findable by agents spiderweb" in the owner's words: every property links the others, and each knowledge entry links its related entries elsewhere. On blockspace.wiki, every project page links its site and every concept its related terms.
standard transaction: A transaction Bitcoin Core's policy will relay, as opposed to one that is merely valid. One limit: a standard transaction weighs at most 400,000 WU (about 100,000 vB); larger ones need direct submission to a miner.
sub-1 sat/vB relay: Relaying and keeping transactions that pay less than 1 sat/vB, the default floor of Bitcoin Core. Blockspace Labs' node does it by running stock Bitcoin Core with minrelaytxfee=0; it is a Live Labs project.

T #

Taproot: The 2021 Bitcoin upgrade whose script-path spends carry inscription envelopes.
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 buy board: block.space's board of assets listed for bitcoin on the venues it watches, ranked by sats per kB, with the buy flow at block.space/buy. blockspace.markets is a static page built from its public listing data every 10 minutes.
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.
tokenized blockspace: Consumed blockspace that a token claims, so that the bytes are represented by something holdable and transferable. Under the Shared Claim Axiom it is the "claimed" state, as against unclaimed and burned blockspace. The axiom describes how unclaimed bytes could be tokenized "after the fact" by a claiming protocol.
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.

U #

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.

V #

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.

W #

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.
whole-block: block.space's size class for an inscription whose content is over 3,500,000 bytes (one over 400,000 bytes is "large"). spaceblocks.art's page "Other works that fill a block" lists the inscriptions block.space classes as whole-block: 110 as of block 972,262. Space Blocks itself, at 1,047,584 bytes, fills a 1 MB block and is below this class.
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.

X #

XCP asset: An asset in the Counterparty ledger. BTI's token catalogue calls XCP assets "the first blockspace tokens (2014)", counts XCP itself as one, and lists counters as a subset. An asset's description can hold a file; when it reaches the chain in a Counterparty taproot envelope, that description is a counter. On counters.fun's mint page, a named asset burns 0.5 XCP.

Sources #

Blockspace Holdings records