# blockspace.wiki: the whole wiki Built 2026-10-20T10:17:30Z from https://blockspace.wiki. 304 pages. --- # blockspace.wiki Everything about Bitcoin blockspace, written down. URL: https://blockspace.wiki/ A place to write all information and documentation about [blockspace](https://blockspace.wiki/glossary/blockspace/): the projects of Blockspace Holdings and their glossaries, the concepts behind them, the token protocols that write to Bitcoin, how their bytes are measured, and the data and APIs anyone can read. Every page cites its sources. Theory is labelled as theory: Blockspace Value Theory is a living document and an untested thesis, and BTP and BYTES are drafts describing things that do not exist. A figure is always given with its "as of". **The meter today.** [BTI](https://blockspace.wiki/glossary/bti/) has counted every byte of Bitcoin up to block 972,302: 777.04 GB in 1,464,151,063 transactions (as of block 972,302, 2026-10-20 10:16:21 UTC). Of those bytes, Book A attributes 133.75 GB to 126,874,922 tokens across 21 protocols (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space meter and summary APIs · https://block.space/api/summary - block.space docs: BTI · https://block.space/docs/bti 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 Updated: 2026-10-20 --- # Bitcoin blockspace basics A short primer: blocks, weight, vbytes, fees, the mempool and the witness discount. URL: https://blockspace.wiki/basics/ The on-ramp for newcomers and agents: what a block holds, how it is sized, and how its space is priced. - [What is a block](https://blockspace.wiki/basics/what-is-a-block/): Blocks, transactions and the chain: what a Bitcoin block holds, how its size is counted, and how many there are. - [Block weight and the limit](https://blockspace.wiki/basics/block-weight-and-the-limit/): Why a block's capacity is counted in weight units, the 4,000,000 WU consensus limit, and the 400,000 WU limit on a standard transaction. - [Vbytes](https://blockspace.wiki/basics/vbytes/): The virtual byte: a quarter of a transaction's weight, the unit fee rates are quoted in, and why it differs from a transaction's raw size. - [Fees and the mempool](https://blockspace.wiki/basics/fees-and-the-mempool/): Where a transaction waits before it is mined, how its fee is quoted in sat/vB, and what Blockspace Holdings' own node and fee estimates read. - [The witness discount](https://blockspace.wiki/basics/the-witness-discount/): A witness byte weighs a quarter of a base byte, so it costs a quarter as much at the same fee rate. The short version, with links to the full page. - [Halvings and the subsidy](https://blockspace.wiki/basics/halvings-and-the-subsidy/): The block subsidy, what Blockspace Holdings' documents say about it and the halving schedule, the fees beside it, and the sats coinbases never claimed. - [Why blockspace is scarce](https://blockspace.wiki/basics/why-blockspace-is-scarce/): The fixed weight limit is the fact; what limits blockspace underneath it is Blockspace Value Theory's argument, labelled as theory. Sources: - Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: data types · https://block.space/docs/datatypes Updated: 2026-10-20 --- # Concepts The ideas behind the meter: Blockspace Value Theory, BTI, the books, attribution, carriage and the rest. URL: https://blockspace.wiki/concepts/ The ideas the projects are built on. Theory pages are marked as theory. - [Blockspace Value Theory](https://blockspace.wiki/concepts/blockspace-value-theory/): BVT, a living document and an untested thesis: that tokens built on consumed Bitcoin blockspace form one commodity, priced in kilobytes. - [Blockspace](https://blockspace.wiki/concepts/blockspace/): What blockspace is: the bytes Bitcoin's blocks hold, as BTI counts them, and what Blockspace Value Theory proposes about them. - [Attribution and the Shared Claim Axiom](https://blockspace.wiki/concepts/attribution-and-the-axiom/): The Shared Claim Axiom: when several tokens claim the same consumed bytes, they share them equally. Plus the B19 draft, which proposes a different test. - [BTP, the Blockspace Token Protocol](https://blockspace.wiki/concepts/btp/): BTP is a draft (0.1, 2026-07-29) of a protocol whose subject is blockspace itself: which token owns which consumed bytes. It does not exist. - [BYTES, a fungible blockspace token](https://blockspace.wiki/concepts/bytes/): BYTES is a draft (0.2, 2026-07-29) of a token minted one per byte of consumed blockspace. It does not exist; its economics are analysed in a companion document. - [Atomicals as a natural experiment](https://blockspace.wiki/concepts/atomicals-natural-experiment/): An observation offered to BVT: Atomicals kept its consumed blockspace and lost its community, so its market is a test between Reading B and Reading C. - [BTI, the Blockspace Token Indexer](https://blockspace.wiki/concepts/bti/): The instrument behind every block.space number: it counts every byte, catalogues every token operation, and writes three books of attribution. - [The three books](https://blockspace.wiki/concepts/the-three-books/): Book A (inclusive), Book B (regional) and Book C (content): three answers to how many bytes back a token, with C ≤ B ≤ A on every entry. - [Carriage and the free-ride index](https://blockspace.wiki/concepts/carriage-and-the-free-ride-index/): Bought or riding: why bytes a token merely rode are measured but never backing, and how B/A shows how much of a token's inclusive claim is its own. - [The byte census (T1)](https://blockspace.wiki/concepts/byte-census-t1/): BTI's first layer: one protocol-blind pass recording every transaction's size, vsize, weight and fee, and where in each block the data sits. - [Claims (T2)](https://blockspace.wiki/concepts/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. - [The books (T3)](https://blockspace.wiki/concepts/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. - [The frontier and "as of block H"](https://blockspace.wiki/concepts/the-frontier/): How far each stage of BTI and its appendix has got, why the cursors are ordered books ≤ claims ≤ census, and why every block.space figure carries its height. - [Weight units and vbytes](https://blockspace.wiki/concepts/weight-units-and-vbytes/): Three ways to size a Bitcoin transaction (raw bytes, weight units and vbytes), the exact formulas, and why BTI's books count raw bytes. - [The witness discount](https://blockspace.wiki/concepts/witness-discount/): SegWit weighs witness bytes at a quarter of base bytes. What that does to fees, how BTI measures it per protocol, and what Blockspace Value Theory proposes it means. - [Fee rate](https://blockspace.wiki/concepts/fee-rate/): What a transaction pays per vbyte, why a witness byte costs a quarter of a base byte, and how BTI divides fees among the tokens a transaction was bought for. - [Relay policy](https://blockspace.wiki/concepts/relay-policy/): What a node will relay, as opposed to what is valid: the fee floor and sub-1 sat/vB relay, the standard size, data-carrier limits and full-RBF, from Blockspace Holdings' own node. - [Sats and ordinals](https://blockspace.wiki/concepts/sats-and-ordinals/): Every sat is separately ownable and numbered by ord. How BTI treats the sat as a token, why rarity is not one, and the Ordinal Sats family on block.space. - [Inscriptions](https://blockspace.wiki/concepts/inscriptions/): Files bound to sats by ord: the witness envelope that carries them, the commit and reveal, recursion and delegation, cursed inscriptions, and how BTI books their bytes. - [Spent sats (blockspace.to)](https://blockspace.wiki/concepts/spent-sats/): blockspace.to is an ord explorer and indexer that also keeps the sat ranges of spent outputs. What that adds, what uses it, and the live state of its index. - [Holders and share of backing](https://blockspace.wiki/concepts/holders/): Who holds the tokens BTI measures, and how each token's bytes divide among its holders: the holders appendix, the rule of shares, coverage, and the leaderboard population. Sources: - Blockspace Value Theory · https://block.space/docs/bvt - Blockspace Holdings records - block.space docs: BTI · https://block.space/docs/bti Updated: 2026-10-20 --- # Projects Every Blockspace Holdings project, one page each, with its own glossary and FAQ. URL: https://blockspace.wiki/projects/ Each project is a domain. A project that isn't live yet says so, with its "as of". - [block.space](https://blockspace.wiki/projects/block.space/): The Bitcoin Blockspace Meter: how much of Bitcoin's blockspace is attributed to tokens, token by token, byte by byte. - [degent.club](https://blockspace.wiki/projects/degent.club/): The Decentralized Gentlemen Club: a community-driven ordinal collection of unique Pepes in tuxedos, built on Bitcoin, with a non-custodial mint. - [scribb.it](https://blockspace.wiki/projects/scribb.it/): Scribbit: a planned way to write a document or record directly into Bitcoin. "Write it once. Keep it forever." - [counters.fun](https://blockspace.wiki/projects/counters.fun/): Counters with XCP liquidity pools. On-chain files only. - [counters.gallery](https://blockspace.wiki/projects/counters.gallery/): Bitcoin Counters explorer: numbered inscriptions in Bitcoin witness data, owned through Counterparty assets. - [devcash.dev](https://blockspace.wiki/projects/devcash.dev/): Devcash: "Cash for the developer economy: a bounty platform and a decentralized exchange." - [mintbitbars.xyz](https://blockspace.wiki/projects/mintbitbars.xyz/): Bitbar minting app. - [blockspace.holdings](https://blockspace.wiki/projects/blockspace.holdings/): Blockspace Holdings' own page: "We acquire & Hodl Blockspace Assets. We serve public Blockspace Infrastructure." - [spaceblocks.art](https://blockspace.wiki/projects/spaceblocks.art/): Space Blocks: one image that fills a 1 MB block, inscription #83,851,681, 1,047,584 bytes. - [blockspace.wiki](https://blockspace.wiki/projects/blockspace.wiki/): "A place to write all information and documentation about blockspace." - [litepedia.space](https://blockspace.wiki/projects/litepedia.space/): "Wikipedia on Litecoin. The encyclopedia uploaded to Litecoin, where anyone can pay LTC to make an edit, with a robust editing system." - [blockspace.loans](https://blockspace.wiki/projects/blockspace.loans/): A parked domain of Blockspace Holdings; no concept announced as of 2026-10-20. - [blockspace.markets](https://blockspace.wiki/projects/blockspace.markets/): Blockspace for sale, priced per kilobyte. - [blockspace.news](https://blockspace.wiki/projects/blockspace.news/): The day in Bitcoin blockspace, in numbers, from block.space. - [blockspacelabs.com](https://blockspace.wiki/projects/blockspacelabs.com/): Blockspace Labs: "Research and development for Bitcoin blockspace." - [blockspace.to](https://blockspace.wiki/projects/blockspace.to/): "Tracks spent sats. A Blockspace Labs product." - [blockspace.space](https://blockspace.wiki/projects/blockspace.space/): A parked domain of Blockspace Holdings; no concept announced as of 2026-10-20. - [bitmap.holdings](https://blockspace.wiki/projects/bitmap.holdings/): Bitmap Holdings: "Bitmaps turn each Bitcoin block into digital land—programmable, ownable, eternal." Sources: - The project list at block.space/projects · https://block.space/projects - Blockspace Holdings records Updated: 2026-10-20 --- # Protocols One page per token family BTI measures: how it writes to Bitcoin, how its bytes are attributed, and its live share. URL: https://blockspace.wiki/protocols/ Every token family [BTI](https://blockspace.wiki/glossary/bti/) measures. - [Ordinal Sats](https://blockspace.wiki/protocols/ordinal-sats/): The sat family: inscribed sats, bitmaps, sat names and CAT-21 sats. How ord binds files to sats, how BTI books them, and the family's live share. - [Runes](https://blockspace.wiki/protocols/runes/): Fungible tokens whose messages, runestones, ride an OP_RETURN output. BTI decodes them itself; ord is only its audit oracle. - [BRC-20](https://blockspace.wiki/protocols/brc-20/): Tick ledgers written as JSON inscriptions, and since 2026-08-11 also on bare OP_RETURN. A BRC-20 mint has two claimants, the sat and the tick. BRC-100 is covered here too. - [Alkanes](https://blockspace.wiki/protocols/alkanes/): Contract tokens called through protostones inside a runestone. metashrew's trace is the record; every contract that ran claims the bytes. - [Omni](https://blockspace.wiki/protocols/omni/): The Mastercoin-lineage ledger, TetherUS included. BTI decodes Class C messages in OP_RETURN itself; a ledger token's bytes are its operations. - [ARC-20 and Atomicals](https://blockspace.wiki/protocols/arc-20-and-atomicals/): Atomicals' fungible ARC-20 tickers, whose units ride sats, and its NFTs (containers and dmitems). One definitional indexer, one quarantine, one named gap: realms. - [Counterparty](https://blockspace.wiki/protocols/counterparty/): XCP assets, the first blockspace tokens (2014), with Stamps and Counters as subsets: one asset, one claim, however many sources sight it. - [TAP](https://blockspace.wiki/protocols/tap/): TAP ticks and DMT, catalogued through tap-reader, a mirror of Trac's feed, with two hops of derived trust. - [SRC-20 and SRC-101](https://blockspace.wiki/protocols/src-20/): SRC-20 ticks written in the Stamps carriers, and SRC-101 names, both catalogued by the stamps adapter. - [Open Assets](https://blockspace.wiki/protocols/open-assets/): An asset protocol of coloured outputs that BTI decodes itself with a coloured-UTXO walk; B/A 0.72 in the July 2026 measurement run. - [CoinSpark](https://blockspace.wiki/protocols/coinspark/): A coloured-output asset protocol whose default route moves units with no CoinSpark bytes at all: the most extreme free-ride measurement recorded. - [EPOBC](https://blockspace.wiki/protocols/epobc/): Colours written into the nSequence field every input already has: zero carrier bytes, the limiting case of the free-ride index. - [Colu](https://blockspace.wiki/protocols/colu/): Colored Coins 2.0: a coloured-UTXO protocol over two carriers, OP_RETURN and bare multisig, whose identity is a pure function of chain data. - [SPOOL](https://blockspace.wiki/protocols/spool/): ascribe's edition registry in OP_RETURN, from 2014 to 2017: editions are tokens, pieces are labels, and fuel transactions are enablers. - [Charms](https://blockspace.wiki/protocols/charms/): A zero-knowledge token protocol whose spells state the resulting charms in the clear; it moved from witness to OP_RETURN, and its Bitcoin-side supply is a lower bound. - [Pipe](https://blockspace.wiki/protocols/pipe/): A September-2023 OP_RETURN token protocol, the Runes precursor, with art in tapscript; no indexer has ever existed, so BTI's replay is the record. - [BRC-100](https://blockspace.wiki/protocols/brc-100/): An inscription-borne tick ledger with a two-step transfer; its only mirror died, so BTI was ruled its indexer on 2026-08-11. - [Mezcal](https://blockspace.wiki/protocols/mezcal/): Runes-lite JSON mezcalstones in OP_RETURN from block 898,750; BTI's decoder transcribes the author's reference indexer, quirks and all. - [OP-20](https://blockspace.wiki/protocols/op20/): BRC-20's JSON shape on OP_RETURN plus a required credit address; no indexer has ever existed, so BTI's replay is the record. - [Bitmap](https://blockspace.wiki/protocols/bitmap/): Bitmap districts are labels on inscribed sats: BTI's opi-bitmap adapter adds a source under Ordinal Sats, never a family of its own. Sources: - Blockspace Holdings records - block.space protocols API · https://block.space/api/protocols Updated: 2026-10-20 --- # How it's measured The methodology: null is never zero, the frontier, the conservation identity, and what each board ranks. URL: https://blockspace.wiki/methodology/ How block.space turns Bitcoin's bytes into the figures it publishes. - [Null is never zero](https://blockspace.wiki/methodology/null-is-never-zero/): Why block.space and this wiki write "not measured" instead of 0: what a measured zero is, where nulls come from, and how the rule shows on the pages and in the APIs. - [The frontier and "as of"](https://blockspace.wiki/methodology/the-frontier-and-as-of/): How to read the heights on block.space and this wiki: which block a figure is true to, why one page can carry several heights, and how a dated document figure differs from a live one. - [The conservation identity](https://blockspace.wiki/methodology/the-conservation-identity/): claimed + carriage + burned + unclaimed = block size: the four categories every byte falls into, why the identity is the meter's trust anchor, and how block.space shows the check. - [What each board ranks](https://blockspace.wiki/methodology/what-each-board-ranks/): The four block.space rankings, the leaderboard, largest inscriptions, heaviest tokens and collections: what one row is, which book each reads by default, how deep it goes, and the rules they share. - [Coverage](https://blockspace.wiki/methodology/coverage/): How much of Book A the holders appendix can place on addresses, protocol by protocol: what the gap is made of, which protocols are not measured, and the checks behind the figure. - [Measured findings](https://blockspace.wiki/methodology/measured-findings/): The findings of the July 2026 measurement run, each dated, and what the live meter reads now. Ratios are the durable results; shares of the chain move. Sources: - block.space docs: BTI · https://block.space/docs/bti - block.space docs: measurements · https://block.space/docs/measurements - block.space docs: rankings · https://block.space/docs/rankings Updated: 2026-10-20 --- # Data and APIs Every public API across the estate, its fields and examples, and the machine surfaces. URL: https://blockspace.wiki/data/ For developers and agents: where the data lives and how to read it. - [The block.space API](https://blockspace.wiki/data/block-space-api/): Every public JSON endpoint under https://block.space/api/: what each one returns, its parameters, the shared conventions, and real responses with their as of. - [The block.space board APIs](https://blockspace.wiki/data/block-space-api-boards/): The ranking APIs behind block.space/rankings, the leaderboard, the largest inscriptions, the heaviest tokens and the collections, and the address and inscription detail endpoints, all in the one envelope. - [The explore.block.space API](https://blockspace.wiki/data/explorer-api/): explore.block.space runs the open-source Mempool explorer, and with it the Mempool REST API: what is enabled, where it is documented, and real responses. - [The blockspace.to ord API](https://blockspace.wiki/data/ord-api/): blockspace.to is an ord server with its JSON API switched on: how to ask for JSON, the endpoints its guide lists, the recursive /r/ endpoints, the brotli rule for /content, and real responses. - [Data the other sites publish](https://blockspace.wiki/data/other-sites-data/): The data files and feeds of blockspacelabs.com, blockspace.news, blockspace.markets and the block.space buy board, counters.gallery and scribb.it: what each holds, where it comes from, and a real reading. - [Machine surfaces](https://blockspace.wiki/data/machine-surfaces/): The files blockspace.wiki publishes for agents and crawlers: sitemap, robots, llms.txt and llms-full.txt, Markdown per page, the Atom feed, the search index, blockspace.json, the live figures and the JSON-LD types. Plus what is planned for the other sites. Sources: - block.space docs: data types · https://block.space/docs/datatypes - block.space meter and summary APIs · https://block.space/api/summary Updated: 2026-10-20 --- # Glossary Every term, A to Z, defined once, linked everywhere, filterable by project. URL: https://blockspace.wiki/glossary/ Each term has its own page for linking. Project pages list the terms that belong to them. - **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](https://blockspace.wiki/glossary/the-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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/reveal-transaction/) and one [reveal transaction](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counterparty/) asset whose description carries a file, written into output-side carriers: [bare multisig](https://blockspace.wiki/glossary/bare-multisig/) at first, [OLGA](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/transaction/) 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](https://blockspace.wiki/glossary/weight-unit/). The chain is every block from the genesis block forward. - **block subsidy**: The part of a miner's revenue for a [block](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/shared-claim-axiom/). In the [partition](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](/concepts/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](/concepts/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](/concepts/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/inscription/): its [inscription id](https://blockspace.wiki/glossary/inscription-id/), block, [content type](https://blockspace.wiki/glossary/content-type/), length and [SHA-256](https://blockspace.wiki/glossary/sha-256/) hash. - **claimed bytes**: One of the four categories every block's bytes divide into: bytes that back a living token. With [carriage](https://blockspace.wiki/glossary/carriage/), [burned bytes](https://blockspace.wiki/glossary/burned-bytes/) and [unclaimed bytes](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/claimed-bytes/), [carriage](https://blockspace.wiki/glossary/carriage/), [burned](https://blockspace.wiki/glossary/burned-bytes/) and [unclaimed](https://blockspace.wiki/glossary/unclaimed-bytes/), 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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counterparty/) asset, carried in a [Counterparty taproot envelope](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/fairminter/) deploy, and they reached the chain inside [witness data](https://blockspace.wiki/glossary/witness/). Either test alone is nothing. - **Counterparty**: The protocol whose assets carry [counters](https://blockspace.wiki/glossary/counter/). For counters it supplies identity, ownership, naming, transfer and, since its v11 [taproot envelope](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/inscription/) on its own output. The stored value is `counterparty/ord`. The first five [counters](https://blockspace.wiki/glossary/counter/) 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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/reveal-transaction/) pair. The message, an asset's description included, travels as data pushes in the reveal's input-0 [witness](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counterparty-plus-ord/) envelope, and both carry [counters](https://blockspace.wiki/glossary/counter/) equally. - **coverage**: The share of [Book A](https://blockspace.wiki/glossary/book-a/) bytes the [leaderboard](https://blockspace.wiki/glossary/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. - **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](https://blockspace.wiki/glossary/inscription/) in the [Decentralized Gentlemen Club](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. - **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). - **fairminter**: A Counterparty message that deploys a fair-minted asset. A fairminter deploy whose description is a file is itself a [counter](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/liquidity-pool/) at soft cap with every satoshi it raised, minting the [LP tokens](https://blockspace.wiki/glossary/lp-token/) 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](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/) 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](https://blockspace.wiki/glossary/degent/) carries. The club's minting rules require it ("Must be framed and include a placard"), and the [Degent mint](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/) runs with it on; the Labs study "Full-RBF in practice" proposes to count the replacements its mempool sees. - **heaviest tokens board**: block.space/heaviest-tokens: the 100,000 heaviest tokens by [Book A](https://blockspace.wiki/glossary/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. - **indexer**: Software that reads every block and builds a searchable view of it. [ord](https://blockspace.wiki/glossary/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. - **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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counterparty/), with its own [LP token](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counter/) 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](https://blockspace.wiki/glossary/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. - **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. - **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. - **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](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/), 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. - **payload**: The file being written into an [inscription](https://blockspace.wiki/glossary/inscription/). - **pointer counter**: A [counter](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. - **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](https://blockspace.wiki/glossary/book-c/)), tokens by what they bought ([Book A](https://blockspace.wiki/glossary/book-a/)), and addresses by the blockspace behind what they hold. On 2026-10-20 the live index lists four boards: the [leaderboard](https://blockspace.wiki/glossary/the-leaderboard/), the [largest inscriptions](https://blockspace.wiki/glossary/largest-inscriptions-board/), the [heaviest tokens](https://blockspace.wiki/glossary/heaviest-tokens-board/) 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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counter/) is keyed to. An unrevealed commit is nothing. - **rolling hash**: How independent counters indexers check that they agree. Each [counter](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. - **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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. - **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](https://blockspace.wiki/glossary/book-a/), [Book B](https://blockspace.wiki/glossary/book-b/) and [Book C](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. - **whole-block**: block.space's size class for an [inscription](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. - **XCP asset**: An asset in the [Counterparty](https://blockspace.wiki/glossary/counterparty/) ledger. BTI's token catalogue calls XCP assets "the first blockspace tokens (2014)", counts XCP itself as one, and lists [counters](https://blockspace.wiki/glossary/counter/) as a subset. An asset's description can hold a file; when it reaches the chain in a [Counterparty taproot envelope](https://blockspace.wiki/glossary/taproot-envelope/), that description is a counter. On counters.fun's mint page, a named asset burns 0.5 XCP. Sources: - Blockspace Holdings records Live figures: degent as of 2026-09-25 23:24:51 UTC Updated: 2026-10-20 --- # Answers One question each, answered in 40 to 60 words, with its sources. URL: https://blockspace.wiki/answers/ Short answers to the questions the projects are asked. All of them are also on the [FAQ](/faq/) page. - [How many Degents are there?](https://blockspace.wiki/answers/how-many-degents-are-there/): 10,000 when fully minted, beside the live inscribed count. - [How much of Bitcoin's blockspace do tokens use?](https://blockspace.wiki/answers/how-much-blockspace-do-tokens-use/): The live share of chain bytes the books attribute to tokens, with its height. - [What are Book A, B and C?](https://blockspace.wiki/answers/what-are-book-a-b-and-c/): BTI's three answers to how many bytes back a token, from widest to narrowest. - [What are spent sats?](https://blockspace.wiki/answers/what-are-spent-sats/): The sat ranges of already-spent outputs, which blockspace.to's ord fork keeps. - [What does "as of block H" mean?](https://blockspace.wiki/answers/what-does-as-of-block-h-mean/): Every block.space figure names the block height it is synchronised to. - [What does "not measured" mean?](https://blockspace.wiki/answers/what-does-not-measured-mean/): No figure exists for that thing yet; block.space writes it in words, never as 0. - [What is a rune?](https://blockspace.wiki/answers/what-is-a-rune/): A fungible token whose operations ride an OP_RETURN runestone; BTI decodes runes itself. - [What is a sub-1 sat/vB transaction?](https://blockspace.wiki/answers/what-is-a-sub-1-sat-vb-transaction/): A transaction paying below Bitcoin Core's default floor of 1 sat/vB, which Blockspace Labs' node relays. - [What is an inscription?](https://blockspace.wiki/answers/what-is-an-inscription/): A file that ord binds to a sat; BTI treats it as content, and the sat as the token. - [What is Blockspace Holdings?](https://blockspace.wiki/answers/what-is-blockspace-holdings/): The holding company behind block.space and the projects on block.space/projects. - [What is Blockspace Value Theory?](https://blockspace.wiki/answers/what-is-blockspace-value-theory/): BVT, a living document and an untested thesis about tokens built on consumed Bitcoin blockspace. - [What is blockspace?](https://blockspace.wiki/answers/what-is-blockspace/): The capacity of Bitcoin's blocks, as the block.space documents define and BTI measures it. - [What is BTI?](https://blockspace.wiki/answers/what-is-bti/): The Blockspace Token Indexer: the instrument behind every block.space number. - [What is BTP?](https://blockspace.wiki/answers/what-is-btp/): A draft (0.1) of the Blockspace Token Protocol, whose subject is blockspace itself. It does not exist. - [What is BYTES?](https://blockspace.wiki/answers/what-is-bytes/): A draft (0.2) describing a fungible token of one per byte of consumed blockspace. It does not exist. - [What is carriage?](https://blockspace.wiki/answers/what-is-carriage/): Bytes a token merely rode: measured in full, never counted as backing. - [What is Scribbit?](https://blockspace.wiki/answers/what-is-scribbit/): A planned Blockspace Holdings product at scribb.it, coming soon. - [What is the Shared Claim Axiom?](https://blockspace.wiki/answers/what-is-the-shared-claim-axiom/): The proposed rule that tokens claiming the same consumed bytes share them equally. - [What is the witness discount?](https://blockspace.wiki/answers/what-is-the-witness-discount/): SegWit weighs witness bytes at a quarter of other bytes, so they cost a quarter as much. - [Where can I get the data?](https://blockspace.wiki/answers/where-can-i-get-the-data/): From block.space's JSON API, and from this wiki's machine-readable files. - [Why does block.space count bytes and not vbytes?](https://blockspace.wiki/answers/why-bytes-not-vbytes/): Raw bytes are the measure; vbytes are kept beside them because the ratio is the witness discount. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # Research Blockspace Labs projects, one short page each, linked to blockspacelabs.com. URL: https://blockspace.wiki/research/ Blockspace Labs is the research and development arm, at [blockspacelabs.com](https://blockspacelabs.com). These pages describe its projects. - [Sub-1 sat/vB relay](https://blockspace.wiki/research/sub-1-sat-vb-relay/): Live: the Blockspace Labs node relays and keeps transactions paying less than 1 sat/vB, on stock Bitcoin Core with minrelaytxfee=0. - [blockspace.to: spent sats](https://blockspace.wiki/research/blockspace-to-spent-sats/): Live, a product: an ord explorer and indexer that also tracks which sats have been spent, running a fork of ord with --index-spent-sats. - [Blockspace Token Indexer (BTI)](https://blockspace.wiki/research/blockspace-token-indexer/): Live: every byte of every block attributed to the tokens that bought it, in three books. It powers block.space. - [The byte census](https://blockspace.wiki/research/byte-census/): Live: every block's bytes, counted by region: base, witness and envelopes. - [Who holds blockspace](https://blockspace.wiki/research/who-holds-blockspace/): Live: the holders of every token's bytes, ranked by address. It powers the block.space leaderboard. - [The blockspace price](https://blockspace.wiki/research/blockspace-price/): Live: asking prices per kilobyte of blockspace across marketplaces, from every listing that can be read. It powers blockspace.markets. - [4 MB transaction relay](https://blockspace.wiki/research/4mb-transaction-relay/): Research: relaying transactions up to 4 MB, the whole block weight. Stock Bitcoin Core stops at 100 kvB, so it needs a patched node; none relays them here today. - [Blockspace expansion policy](https://blockspace.wiki/research/blockspace-expansion-policy/): Research: the relay and consensus levers that change how much blockspace is usable and who can reach it, each measured effect beside the arguments for and against. Descriptive; it takes no side. - [Permanent bytes: what to store on Bitcoin, and how](https://blockspace.wiki/research/permanent-bytes/): Research: every byte on Bitcoin is permanent and costly. What deserves that, and how is each byte best spent? Seven questions, each tied to the data that could answer it. - [Policy observatory](https://blockspace.wiki/research/policy-observatory/): Research: count the transactions mined each block that standard relay would refuse, and how much blockspace reaches miners off the standard relay path. - [Low-fee propagation](https://blockspace.wiki/research/low-fee-propagation/): Research: which sub-1 sat/vB transactions the Labs mempool keeps actually get mined, by which pools, and how long they wait. - [The sub-1 sat/vB share](https://blockspace.wiki/research/sub-1-sat-vb-share/): Research: hour by hour, how much of a mempool with no fee floor pays below 1 sat/vB, and what it would have paid at the default floor. - [Full-RBF in practice](https://blockspace.wiki/research/full-rbf-in-practice/): Research: count the replacements the Labs mempool sees with full-RBF on, and which of them reach blocks. - [The witness discount, by protocol](https://blockspace.wiki/research/witness-discount-by-protocol/): Research: each token family's split of base and witness bytes, and what the discount saved it in fees. - [The envelope taxonomy](https://blockspace.wiki/research/envelope-taxonomy/): Research: every way data is carried on Bitcoin (ord envelopes, Counterparty, OP_RETURN protocols, stamps), by bytes over time. - [Inscription permanence](https://blockspace.wiki/research/inscription-permanence/): Research: how often inscribed sats are spent or move, and where they go. - [Lost sats](https://blockspace.wiki/research/lost-sats/): Research: sats that coinbase transactions never claimed, so they exist in no output: where and when they were lost. - [Cursed inscriptions](https://blockspace.wiki/research/cursed-inscriptions/): Research: which rules cursed each inscription, by height, and how the books bind them to sats. - [Testing the BVT](https://blockspace.wiki/research/testing-the-bvt/): Research: does the price per kilobyte track attributed bytes? A proposed empirical test of Blockspace Value Theory, an untested thesis. - [Blockspace Value Theory (Labs card)](https://blockspace.wiki/research/blockspace-value-theory/): Research: the thesis behind the meter, in its own words a living document and an untested thesis. - [Fork and reorg watch](https://blockspace.wiki/research/fork-and-reorg-watch/): Research: detect indexers that follow a stale tip or a fork, from the experience of an atomicals indexer stuck on an orphan at block 966,500. - [Litecoin and Dogecoin blockspace](https://blockspace.wiki/research/litecoin-and-dogecoin-blockspace/): Research: Litecoin's and Dogecoin's blockspace measured the way block.space measures Bitcoin's. No Litecoin or Dogecoin node runs yet; the study starts when one does. Sources: - Blockspace Holdings records - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com Updated: 2026-10-20 --- # About this wiki What blockspace.wiki is, who writes it, and the rules every page follows. URL: https://blockspace.wiki/about/ blockspace.wiki is the knowledge hub of Blockspace Holdings: "a place to write all information and documentation about blockspace". It went live on 2026-10-20. ## The rules - **Invent nothing.** Every page is written from Blockspace Holdings' published documents and records and from the live data of [Blockspace Holdings' node and indexers](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/), and cites them. A claim with no source is not written. - **Theory is labelled as theory.** Blockspace Value Theory is a living document and an untested thesis. BTP and BYTES are drafts describing things that do not exist. Pages about them carry a notice saying so. - **Every figure has an "as of".** Live figures are read every hour; a source that cannot be read keeps its last reading and its old "as of". - **Null is never zero.** Something not measured is "not measured", never 0. - **One name per thing.** The company is Blockspace Holdings. The product at scribb.it is Scribbit. - **Corrections are dated,** on the [errata](/errata/) page, and never silently erased. ## For machines Every page is also published as Markdown at its address plus `index.md`. The whole wiki is one file at [/llms-full.txt](/llms-full.txt), with an index at [/llms.txt](/llms.txt), a [sitemap](/sitemap.xml), an [Atom feed](/feed.xml), the [search index](/search-index.json) and a summary at [/blockspace.json](/blockspace.json). See [Data and APIs](/data/). Sources: - Blockspace Holdings records - block.space meter and summary APIs · https://block.space/api/summary Updated: 2026-10-20 --- # Block weight and the limit Why a block's capacity is counted in weight units, the 4,000,000 WU consensus limit, and the 400,000 WU limit on a standard transaction. URL: https://blockspace.wiki/basics/block-weight-and-the-limit/ A block's capacity is not counted in bytes. It is counted in [weight units](https://blockspace.wiki/glossary/weight-unit/) (WU), and consensus caps a [block](https://blockspace.wiki/glossary/block/) at **4,000,000 WU**. This page is the short version; the formulas and worked transactions are on [weight units and vbytes](/concepts/weight-units-and-vbytes/). ## How weight is counted block.space's data-types reference, citing BIP 141, gives the rule: ``` weight = stripped_size × 3 + total_size ``` Here `total_size` is the whole transaction and `stripped_size` is the transaction without its [witness](https://blockspace.wiki/glossary/witness/). In plain terms: - every byte outside the witness costs **4 WU**; - every byte inside the witness costs **1 WU**. A legacy transaction, with no witness, weighs exactly four times its size. ## What the limit allows Because base and witness bytes weigh differently, the same 4,000,000 WU can hold different numbers of bytes. Blockspace Value Theory's worked example (§3.6) gives a block's capacity as 1,000,000 vB, and BVT §3.1 notes that a block made almost entirely of witness data approaches 4 MB, and works it through: 4 MB × 144 blocks a day × 365 days is about 210 GB a year. BVT calls that a ceiling, "not a schedule": the most that could be used if every block were filled to the limit with the most discounted data, which "has never been sustained". *BVT is a living document and an untested thesis.* ## A smaller limit for relay Consensus decides what is valid. Relay policy decides what a node passes on. The reference gives the policy limit: a [standard transaction](https://blockspace.wiki/glossary/standard-transaction/) weighs at most **400,000 WU**, about 100,000 vB. A bigger transaction is still valid, but it has to be sent to a miner directly. blockspacelabs.com lists both figures for Blockspace Holdings' own node: max standard tx 400,000 WU, max block weight 4,000,000 WU (read 2026-10-20 09:07 UTC). See [relay policy](/concepts/relay-policy/). ## Is the limit fixed? BVT §3.3 argues it is "a social variable, not a constant": the 4M weight limit is where the community currently believes the [decentralization constraint](https://blockspace.wiki/glossary/decentralization-constraint/) binds, "revisable in either direction". blockspacelabs.com lists the block weight limit and the witness discount among the consensus levers in its descriptive study "Blockspace expansion policy", which, in its words, "takes no side". ## What the chain actually used The census has counted 777.04 GB of [raw bytes](https://blockspace.wiki/glossary/raw-bytes/) over 972,303 blocks (as of block 972,302, 2026-10-20 10:16:21 UTC). How that is sized in fee terms is on [vbytes](/basics/vbytes/). Sources: - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - block.space meter and summary APIs · https://block.space/api/summary Live figures: census as of block 972,302, 2026-10-20 10:16:21 UTC Updated: 2026-10-20 --- # Fees and the mempool Where a transaction waits before it is mined, how its fee is quoted in sat/vB, and what Blockspace Holdings' own node and fee estimates read. URL: https://blockspace.wiki/basics/fees-and-the-mempool/ A transaction is not mined the moment it is sent. It waits in the [mempool](https://blockspace.wiki/glossary/mempool/), "the waiting room of unconfirmed transactions that miners choose from", in the words of the Scribbit glossary. Blocks have capacity limits, and Blockspace Value Theory notes that transactions "must compete for inclusion"; the fee is the bid. Once a [block](https://blockspace.wiki/glossary/block/) includes it, it has its first [confirmation](https://blockspace.wiki/glossary/confirmation/). ## How a fee is quoted A fee is paid in sats, but it is compared as a [fee rate](https://blockspace.wiki/glossary/fee-rate/): sats per virtual byte, sat/vB. block.space's data-types reference gives what a rate buys. At f sat/vB: - a base byte costs f sats; - a [witness](https://blockspace.wiki/glossary/witness/) byte costs f/4 sats. So the same fee rate buys four times as many witness bytes as base bytes. See [vbytes](/basics/vbytes/) and [the witness discount](/basics/the-witness-discount/). The fuller treatment, including how [BTI](https://blockspace.wiki/glossary/bti/) divides a fee among the tokens a transaction was bought for, is on [fee rate](/concepts/fee-rate/). Blockspace Value Theory describes the time before a block as the phase of "bids for inclusion": transactions broadcast, "producers watching the fee market, bidders guessing at inclusion". It records the fee environment of early to mid 2026 as "sustained periods at 0.13–0.14 sat/vB, with AntPool accepting sub-1 sat/vB inscriptions". *BVT is a living document and an untested thesis.* ## What Blockspace Holdings' node keeps Which transactions a node keeps in its mempool is relay policy, not consensus. [Blockspace Holdings' own Bitcoin node](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/) reads (as of block 972,304, 2026-10-20 10:17:29 UTC): | setting | value | |---|---| | node | /Satoshi:28.2.0/ | | fee floor (minrelaytxfee) | 0 sat/vB | | incrementalrelayfee | 1 sat/vB | | maxmempool | 300 MB | | full-RBF | on | With a floor of 0 the node keeps transactions paying below 1 sat/vB, which blockspacelabs.com calls "the default floor of Bitcoin Core". Its page, read at 2026-10-20 09:07:08 UTC (block 972,298), showed 38,991 transactions in the mempool, 23.7 vMB, of which 38,265 paid below 1 sat/vB. See [sub-1 sat/vB relay](https://blockspace.wiki/glossary/sub-1-sat-vb-relay/) and [relay policy](/concepts/relay-policy/). ## A fee estimate Scribbit reads fee estimates from explore.block.space, the mempool explorer on Blockspace Holdings' own node. At 2026-10-20 09:36:44 UTC it gave, in sat/vB: economy 1, within the hour 1, fastest 2, and a median of 1.03 for the next block. ## Fees over the whole chain The census has counted 30,078,457,217,912 sats paid in fees across 1,464,151,063 transactions (as of block 972,302, 2026-10-20 10:16:21 UTC). Sources: - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - Blockspace Holdings records - block.space meter and summary APIs · https://block.space/api/summary Live figures: census as of block 972,302, 2026-10-20 10:16:21 UTC; relay as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # Halvings and the subsidy The block subsidy, what Blockspace Holdings' documents say about it and the halving schedule, the fees beside it, and the sats coinbases never claimed. URL: https://blockspace.wiki/basics/halvings-and-the-subsidy/ In Blockspace Value Theory's account, a miner's revenue for a [block](https://blockspace.wiki/glossary/block/) has two parts: the [block subsidy](https://blockspace.wiki/glossary/block-subsidy/) and the fees of the transactions it includes. This page gives what Blockspace Holdings' documents record about the subsidy. They do not give the halving schedule's interval or its dates, so this page does not either. ## The subsidy now Blockspace Value Theory (v3.0, July 2026) lists the current block subsidy as **3.125 BTC**, in its table of measured network figures. It describes the subsidy as one that "currently dominates miner revenue and is identical for every block". On the supply of bitcoin itself, BVT says: "The 21 million cap is enforced by every validating node rejecting inflationary blocks." ## The halving schedule, as BVT uses it BVT mentions the halving schedule once, as a comparison it withdrew. Version 2.0 had treated a ceiling of about 210 GB of blockspace a year "as analogous to Bitcoin's halving schedule — a known, protocol-guaranteed supply curve". Version 3.0 calls that an error: blockspace "does not follow a curve; it follows the fee market." See [why blockspace is scarce](/basics/why-blockspace-is-scarce/). ## When fees become the reward *This section reports Blockspace Value Theory, a living document and an untested thesis.* BVT's risk chapter starts from the subsidy: because it is the same in every block, "extending the chain tip is always rational". "As the subsidy approaches zero and fees become the reward, that changes — because fees are lumpy in a way the subsidy never was." It cites Carlsten et al. (2016) on the incentive this creates to [reorg](https://blockspace.wiki/glossary/reorg/) a block with unusually high fees rather than build on it. BVT notes that its own long thesis assumes fee revenue rises to replace the subsidy, and that this is "the scenario in which this problem is most acute". Fees so far: the census has counted 30,078,457,217,912 sats in fees over the whole chain (as of block 972,302, 2026-10-20 10:16:21 UTC). ## Sats a coinbase never claimed Each block begins with a [coinbase transaction](https://blockspace.wiki/glossary/coinbase-transaction/), written by the miner. blockspacelabs.com describes [lost sats](https://blockspace.wiki/glossary/lost-sats/) as "sats that coinbase transactions never claimed, so they exist in no output". ord, on [Blockspace Holdings' own node and indexers](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/), counted 2,895,844,904 lost sats (as of block 972,304, 2026-10-20 10:17:29 UTC). Sources: - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: data types · https://block.space/docs/datatypes - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - ord /status (the blockspace.to ord server) · https://blockspace.to/status - block.space meter and summary APIs · https://block.space/api/summary Live figures: census as of block 972,302, 2026-10-20 10:16:21 UTC; ord as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # The witness discount A witness byte weighs a quarter of a base byte, so it costs a quarter as much at the same fee rate. The short version, with links to the full page. URL: https://blockspace.wiki/basics/the-witness-discount/ The [witness discount](https://blockspace.wiki/glossary/witness-discount/) is the rule, from segwit, that a byte in a transaction's [witness](https://blockspace.wiki/glossary/witness/) counts 1 [weight unit](https://blockspace.wiki/glossary/weight-unit/) and every other byte counts 4. The full page, with the measurements and the theory, is [the witness discount](/concepts/witness-discount/). This is the short version. ## In one line block.space's data-types reference: "witness bytes are real bytes on disk and on the wire, but count 1/4 toward the 4,000,000 WU consensus block limit." Because fees are priced in [vbytes](https://blockspace.wiki/glossary/vbytes/), a witness byte also costs a quarter as much as a base byte at the same [fee rate](https://blockspace.wiki/glossary/fee-rate/). ## What it changes Where data goes depends on the price. The reference's channel comparison, per data byte at f sat/vB: - a Taproot witness [envelope](https://blockspace.wiki/glossary/envelope/): 1 WU, f/4 sats; - OP_RETURN: 4 WU, f sats. That is why, in the reference's words, every high-volume protocol (ordinals, BRC-20, Alkanes WASM, Counterparty v11) "converged on" the witness envelope, while OP_RETURN keeps small structured messages such as runestones. ## How much each protocol takes Bytes divided by vbytes shows how much of the discount a protocol takes. In the July 2026 measurement run on block.space it was 3.374 for inscriptions, 1.008 for stamps, 1.0000 for runestones and 1.0142 for Omni. [BTI](https://blockspace.wiki/glossary/bti/) keeps both raw bytes and vbytes on every row so this ratio stays visible. ## Two readings The mechanism is a fact about weight. What it means is argued. Blockspace Value Theory proposes that the discount is "a price subsidy, not a capacity increase": witness bytes are downloaded, validated and stored like any others, so they use the same scarce resource at a quarter of the price. *BVT is a living document and an untested thesis.* BTI's books follow its measuring rule, raw bytes with no weight discounting, without taking a view on value. Sources: - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: measurements · https://block.space/docs/measurements - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - Blockspace Holdings records Updated: 2026-10-20 --- # Vbytes The virtual byte: a quarter of a transaction's weight, the unit fee rates are quoted in, and why it differs from a transaction's raw size. URL: https://blockspace.wiki/basics/vbytes/ A transaction has a size in bytes and a size in [vbytes](https://blockspace.wiki/glossary/vbytes/) (vB, virtual bytes). The second is the one fees are priced in. This page is the primer; the exact formulas are on [weight units and vbytes](/concepts/weight-units-and-vbytes/). ## The definition block.space's data-types reference gives it: ``` vsize = ceil(weight / 4) ``` So a vbyte is a quarter of the [weight](https://blockspace.wiki/glossary/weight-unit/), rounded up for the transaction as a whole. Since a base byte weighs 4 WU and a [witness](https://blockspace.wiki/glossary/witness/) byte weighs 1 WU: - a base byte counts as 1 vB; - a witness byte counts as a quarter of a vB. A transaction with no witness has the same size in bytes and in vbytes. A transaction that is mostly witness has about four times as many bytes as vbytes. ## Two real transactions From the BTI case studies (2026-08-10): | transaction | bytes | vbytes | |---|---|---| | the first BRC-20 mint, block 779,833 | 338 | 155 | | a 3.9 MB jpeg inscription, block 960,962 | 3,911,459 | 977,936 | The jpeg is almost all witness; the case study puts its ratio of bytes to vbytes, commit included, at about 4.00. ## Why the difference matters Fee markets charge per vbyte (see [fees and the mempool](/basics/fees-and-the-mempool/)). The [raw bytes](https://blockspace.wiki/glossary/raw-bytes/) are, in the reference's words, "real bytes on disk and on the wire". [BTI](https://blockspace.wiki/glossary/bti/)'s design takes a side on which one measures blockspace: "raw bytes are the measure; vbytes are an observable." It keeps both on every row anyway, because the ratio between them shows how much of [the witness discount](/basics/the-witness-discount/) a protocol takes. ## The chain in both units The census, as of block 972,302, 2026-10-20 10:16:21 UTC: - raw bytes: 777.04 GB - vbytes: 567.70 GB block.space's boards offer a bytes and a vbytes toggle for the same reason. Sources: - block.space docs: data types · https://block.space/docs/datatypes - Blockspace Holdings records - block.space meter and summary APIs · https://block.space/api/summary - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Live figures: census as of block 972,302, 2026-10-20 10:16:21 UTC Updated: 2026-10-20 --- # What is a block Blocks, transactions and the chain: what a Bitcoin block holds, how its size is counted, and how many there are. URL: https://blockspace.wiki/basics/what-is-a-block/ Bitcoin's history is a chain of [blocks](https://blockspace.wiki/glossary/block/). Each block holds a batch of [transactions](https://blockspace.wiki/glossary/transaction/). The space those transactions take up is what this wiki calls [blockspace](https://blockspace.wiki/glossary/blockspace/). ## What a block holds block.space's data-types reference states a block's size exactly: an 80-byte header, then a count of its transactions, then the transactions themselves. Its size in bytes is the header plus the count plus the sum of the transactions' sizes. [BTI](https://blockspace.wiki/glossary/bti/) uses that sum as a check: what it attributes inside a block must add up to the block's size. The first transaction of every block is the [coinbase transaction](https://blockspace.wiki/glossary/coinbase-transaction/). The miner writes it. Its scriptSig must begin with the block's height, and the rest of it, up to 100 bytes, is free for the miner's own use. ## What a transaction holds A transaction, in the reference's layout, is: ``` nVersion(4) | marker | flag | inputs | outputs | witness | nLockTime(4) ``` - **Inputs** name the earlier outputs being spent. - **Outputs** each carry an 8-byte amount and a locking script. - **The witness**, in a segwit transaction, holds one stack per input: signatures, and sometimes data. - The marker and flag are two bytes of the segwit layout. A transaction's txid hashes it without the witness; its wtxid hashes all of it. The reference says that split is what makes witness data structurally separable, and weight treats it separately. See [the witness discount](/basics/the-witness-discount/). ## The chain The chain runs from the genesis block, block 0, to the newest block, the tip. BTI "walks every Bitcoin transaction, from the genesis block forward, and counts every byte exactly". Its census, the first of its three stages, had counted (as of block 972,302, 2026-10-20 10:16:21 UTC): | what | count | |---|---| | blocks | 972,303 | | transactions | 1,464,151,063 | | raw bytes | 777.04 GB | The tip, as [Blockspace Holdings' own node](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/) reported it, was block 972,304 (as of block 972,301, 2026-10-20 09:35:17 UTC). ## Where to go next How large a block may be is set by weight, not bytes: see [block weight and the limit](/basics/block-weight-and-the-limit/). How the census counts every byte is on [the byte census](/concepts/byte-census-t1/). Sources: - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: BTI · https://block.space/docs/bti - Blockspace Holdings records - block.space meter and summary APIs · https://block.space/api/summary - block.space frontier API (the three tier cursors and the chain tip) · https://block.space/api/frontier Live figures: 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 Updated: 2026-10-20 --- # Why blockspace is scarce The fixed weight limit is the fact; what limits blockspace underneath it is Blockspace Value Theory's argument, labelled as theory. URL: https://blockspace.wiki/basics/why-blockspace-is-scarce/ > Theory, not fact. Blockspace Value Theory is a living document and an untested thesis. BTP and BYTES are drafts describing things that do not exist. Every [block](https://blockspace.wiki/glossary/block/) has a fixed capacity, and a byte that is in a block stays in it. Those two facts make [blockspace](https://blockspace.wiki/glossary/blockspace/) limited. Why the limit sits where it does, and what it protects, is argued by [Blockspace Value Theory](https://blockspace.wiki/glossary/bvt/), a living document and an untested thesis. This page keeps the two apart. ## The fact: a fixed limit Consensus caps every block at 4,000,000 [weight units](https://blockspace.wiki/glossary/weight-unit/). block.space's data-types reference states it as "the 4,000,000 WU consensus block limit". No block may exceed it, so transactions compete for the space. block.space's front page puts the result in one line: "A block is a fixed quantity of blockspace, consumed once and never again." How much of the chain's space the tokens [BTI](https://blockspace.wiki/glossary/bti/) measures have used: [Book A](https://blockspace.wiki/glossary/book-a/) attributes 133.75 GB of the 777.04 GB in its range, 17.21 % (as of block 972,299, 2026-10-20 09:30:48 UTC). ## What BVT proposes **What blockspace is.** BVT calls blockspace "a socially constructed commodity built on top of a protocol-enforced constraint". The constraint is real; the commodity is "a useful fiction" that lets markets form. It says this explains "why supply is perfectly inelastic". **What really limits it.** BVT argues that the binding limit is not bytes per block but "the largest the blockchain could grow while still keeping verification decentralized". Every byte in a block raises, slightly, the cost of running a node that verifies the chain. As that cost rises, fewer people run nodes. On this reading, blockspace value "is therefore, at bottom, the value of keeping verification decentralized". See [decentralization constraint](https://blockspace.wiki/glossary/decentralization-constraint/). **Why the number can move.** BVT calls the 4M weight limit "a social variable, not a constant", defended "by norms rather than by mathematics", and notes it has "already been fought over once". It contrasts this with bitcoin's own supply: "The 21 million cap is enforced by every validating node rejecting inflationary blocks." The blockspace ceiling is enforced the same way, it says, but its number "is far more contested". **Why supply is not a schedule.** A full block of witness data approaches 4 MB, and BVT works out that 4 MB × 144 blocks a day × 365 days is about 210 GB a year. It calls that a ceiling, not a schedule: actual use "is demand-determined and has been far below the ceiling". See [halvings and the subsidy](/basics/halvings-and-the-subsidy/) for the comparison with bitcoin's issuance that BVT withdrew. ## Open questions blockspacelabs.com lists "Blockspace expansion policy" as a descriptive study of the levers that change how much blockspace is usable: the fee floor, the standard size, data-carrier limits, full-RBF, the block weight limit and the witness discount. It "takes no side". The full theory, with its own falsifiable test, is on [Blockspace Value Theory](/concepts/blockspace-value-theory/). Sources: - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - block.space meter and summary APIs · https://block.space/api/summary Live figures: books as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Atomicals as a natural experiment An observation offered to BVT: Atomicals kept its consumed blockspace and lost its community, so its market is a test between Reading B and Reading C. URL: https://blockspace.wiki/concepts/atomicals-natural-experiment/ > Theory, not fact. Blockspace Value Theory is a living document and an untested thesis. BTP and BYTES are drafts describing things that do not exist. This page reports a companion observation to [Blockspace Value Theory](https://blockspace.wiki/glossary/bvt/), noted on 2026-07-28 and aimed at BVT Part VII and its three readings. It is an argument about what a market should show, not a measured result. ## The observation The observation's claim is that Atomicals and its ARC-20 tokens are "the first blockspace-token protocol where **the consumption layer and the community layer have fully decoupled**". That, it says, "makes it the control group BVT has been missing." It describes three layers with three fates. ### 1. The consumption is permanent Every `atom` witness envelope ever revealed is still consensus-valid data. The observation lists "The founder's disappearance (2024), the treasury drain (Feb 2026), and the death of every wallet, marketplace, and hosted indexer" and says they "changed **zero bytes** of it." ### 2. The interpretation layer died and can be rebuilt Ownership state "is a pure function of (chain data, protocol rules)". The complete ARC-20 ledger can be re-derived from chain data and the published rules alone, with no snapshot or API. "**A dead protocol with published rules is a resurrectable index.**" The contrast it draws is TAP, "where the writer is closed and tap-reader only mirrors." ### 3. The live ledger decays ARC-20 is colored sats: tokens ride specific satoshis, one sat to one unit (see [sats and ordinals](/concepts/sats-and-ordinals/)). With protocol-aware wallets gone, holders who spend those outputs through ordinary wallets burn or scramble their tokens under the protocol's own rules. So: - the historical record is immortal; - the computable current state can always be recovered; - the economically live supply "shrinks monotonically as custody knowledge evaporates." It names this [decay-by-amnesia](https://blockspace.wiki/glossary/decay-by-amnesia/): "A slow, unintentional, permanent burn — supply deflation by amnesia." The [Shared Claim Axiom](/concepts/attribution-and-the-axiom/) cites it as "blockspace burning continuously at scale". ## What each reading predicts BVT offers three readings of why the market prices provenance rather than kilobytes ([Readings A, B and C](https://blockspace.wiki/glossary/readings-a-b-c/)). The observation sets out what each predicts for Atomicals after the collapse: | Reading | Prediction | |---|---| | A: the market is immature | Prices re-anchor toward consumption value as infrastructure restores legibility | | B: consumption sets the floor, provenance the price | A thin but nonzero floor persists; provenance premia collapse toward it | | C: value is purely cultural | Prices trend to zero despite permanent consumption | "**Whatever Atomicals prices do from here is evidence between B and C**". It calls this the cleanest such evidence available, "because every other roster protocol still has a live community confounding the signal." If a measurable floor persists relative to kilobytes consumed, "consumption-as-floor gains real support". If prices go fully to zero, "BVT should concede the floor is cultural (Reading C)". It adds a second effect. Because of decay-by-amnesia, "*even under Reading C*, surviving intact ARC-20 positions become scarcer over time without any demand change". That is a supply-side experiment inside the demand-side one. ## What BTP would change The [BTP draft](/concepts/btp/) says its SUCCEED operation would let holders of dead-protocol tokens such as ARC-20 exit by burning into live tokens, so "the Atomicals natural experiment gains an observable exit ramp." BTP does not exist. ## What can be measured The observation lists four measurements: - total KB consumed by all Atomicals operations; - live against destroyed supply over time, "the decay-by-amnesia curve, measurable at every height"; - holder-count decay, distinct holding scripts since the collapse; - remaining marketplace listings, for the price side. The first is now on block.space. [BTI](/concepts/bti/) carries two Atomicals families in [the three books](/concepts/the-three-books/), read as of block 972,299, 2026-10-20 09:30:48 UTC: | | ARC-20 | Atomicals NFTs | |---|---|---| | Book A bytes | 4.95 GB | 0.07 GB | | share of the chain's bytes | 0.64 % | 0.01 % | | operations | 8,284,671 | 32,517 | | tokens | 657 | 32,230 | | first block | 808081 | 808579 | | last block | 972299 | 929700 | The sources this page draws on do not report the decay-by-amnesia curve, the holder-count decay or the price side, so for this page they are not measured, and the test the observation proposes has no reported result. ## The one-line version > Atomicals is the natural experiment: the blockspace survived, the community didn't, and the market's treatment of the survivors is the cleanest available measurement of whether consumption or culture sets the floor. Sources: - block.space docs: Atomicals · https://block.space/docs/atomicals - Atomicals as a natural experiment for BVT · https://block.space/docs/atomicals - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: the axiom · https://block.space/docs/axiom - block.space docs: BTP · https://block.space/docs/btp - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Attribution and the Shared Claim Axiom The Shared Claim Axiom: when several tokens claim the same consumed bytes, they share them equally. Plus the B19 draft, which proposes a different test. URL: https://blockspace.wiki/concepts/attribution-and-the-axiom/ > Theory, not fact. Blockspace Value Theory is a living document and an untested thesis. BTP and BYTES are drafts describing things that do not exist. The [Shared Claim Axiom](https://blockspace.wiki/glossary/shared-claim-axiom/) is the accounting rule under [Blockspace Value Theory](https://blockspace.wiki/glossary/bvt/). It answers one question: when a token is said to represent consumed kilobytes, which kilobytes, and what happens when several tokens claim the same ones. It was noted on 2026-07-28 as a proposed refinement of BVT's definition of a [blockspace token](https://blockspace.wiki/glossary/blockspace-token/). Its own text says "'Shared equally' is explicitly a rule of thumb, not a derived result." This page describes the rule as the documents state it. It is theory, not a measured fact. ## The axiom > A blockspace token represents consumed kilobytes. When multiple tokens claim the same consumed bytes, the kilobytes are **shared equally** among the claims. A token's [backing](https://blockspace.wiki/glossary/backing/) is the bytes consumed divided by n, where n counts "distinct assets — separately ownable tokens — claiming the bytes". It does not count protocol names or owners. Who holds the tokens is irrelevant to the split. The scope is "all kilobytes consumed during or by a transaction": the full serialized size, plus transactions that exist only to enable it, such as the commit half of a commit and reveal pair. Witness bytes count at full size, with no weight discount, in line with BVT. ## Batches, enablers and fungible tokens - **Batch transactions.** Each token owns its own payload bytes. The shared bytes (frame, signatures, overhead) split in proportion to each token's direct payload, with an equal split when no payload tells the claims apart. "Co-tenancy of a transaction is still not co-claiming of bytes." - **Enabling transactions.** Commit transactions, CPFP children and funding ("fuel") transactions join the pool of the operation they enable. - **Fungible tokens.** Backing is "the sum of **all** its lifecycle operations": deploy, every mint and every transfer. Backing grows with use. Per-unit backing is aggregate backing divided by surviving supply. ## Why share equally The axiom gives two reasons. **Conservation**: total backing across all tokens always equals total bytes consumed, with nothing double-counted or orphaned. **Neutrality**: an equal split needs no judgment about which claim is primary. "The rule of thumb is the Schelling point." ## What counts as a claimant "A token is anything that is holdable and transferrable." The test: "can you transfer it by itself? It's a token. Does it only travel with something else? It's not." From that test: "**An envelope never claims. The token it is bound to claims.**" An inscription on a sat is claimed by the sat; a COUNT envelope or a stamp on a Counterparty asset is claimed by the asset. "**An inscription is not a token.** It is *content bound to a token*." Labels such as inscription, stamp or counter numbers name the content and add no claims. The axiom sums this up as three levels: "**label → content → token.** Only the last one claims." See [inscriptions](/concepts/inscriptions/) and [sats and ordinals](/concepts/sats-and-ordinals/). ## The consequence principle The axiom sharpens this with the [consequence principle](https://blockspace.wiki/glossary/consequence-principle/): a token claims bytes "iff the protocol assigned those bytes a **consequence in that token's state**". Its worked examples: a malformed runestone (cenotaph) burns input runes, so the burned runes claim it; a failed rune mint changes nothing and stays unclaimed; a failed BRC-20 mint is claimed by its inscription but not by the tick. Failed attempts are measured separately as failed-demand KB, "never part of backing". ## Worked cases and dust claims The axiom's table gives one claimant (full bytes) for a plain inscription, stamp, rune or alkane, and for an alkanes contract deploy. A Counters v3 artifact with an ordinals-compatible envelope has two claimants, split 50/50; a bare envelope has one. A BRC-20 deploy or transfer inscription has two in principle. Many such second claims are [dust claims](https://blockspace.wiki/glossary/dust-claim/): "a valid claim whose standalone value sits below the cost and friction of exercising it". The split stays 50/50 on paper, but the market treats the share as going to the co-claimant. A famous deploy inscription is not a dust claim that woke up; its price is a provenance premium. ## Unclaimed and burned blockspace "**Most consumed blockspace has no claim on it at all.**" Payments, consolidations and sweeps sit at n = 0. So consumed blockspace has three states: claimed, [unclaimed](https://blockspace.wiki/glossary/unclaimed-bytes/) and [burned](https://blockspace.wiki/glossary/burned-bytes/). "Unclaimed is not burned. Burned blockspace exited the market; unclaimed blockspace never entered it." The axiom adds that a new protocol could claim unclaimed bytes, for example by proof of authorship: signing with a key that controlled an input of a historical transaction. That would turn unclaimed bytes into [tokenized blockspace](https://blockspace.wiki/glossary/tokenized-blockspace/), "Your own past consumption, tokenized after the fact." It calls the unclaimed pool "a vast latent supply". [BTP](/concepts/btp/) drafts this as its CLAIM operation. The burn rules: a burned claim's share goes to the other tokens on the same bytes, unless the burn directs it to a successor (BTP's SUCCEED). Only provable forever-unspendability counts as burned; "Key loss never counts as burned". When every token on some bytes is burned, that blockspace is burned, "the asset class's only deflationary sink". And "A claim's validity does not depend on anyone caring": dead but unburned tokens keep their claims. ## The proposed revision to BVT The axiom ends with proposed wording for BVT §2.1: a blockspace token's backing is "measured as those kilobytes divided equally among the distinct tokens claiming the same bytes", and "attribution is shared, conserved, and concentrates only by burn." ## Amendments of 2026-08-11 Blockspace Holdings' records of the axiom hold three amendments, ruled on 2026-08-11: - **A1.** Groups (collections, subasset families, series) are neither tokens nor labels. They never add claims or change n. Membership is fractional: k memberships weigh 1/k each. Ordinals collections are groups with curated membership, provenance class "asserted". - **A2.** A protocol total is a sum of shares. Backing, carrier slice and footprint are distinct quantities. - **A3.** Identity provenance is chain-derived, index-derived or flagged, plus asserted for group membership. ## The B19 draft On 2026-07-31 a draft proposed one sentence to govern the axiom: > **Bytes are attributed to a token iff they were bought for that token's purpose. Attribution is backing.** The draft is marked "**Not applied**": it is proposed wording for the owner's documents, not a change to them. It would demote the consequence principle "to a description" and make a failed operation claim its bytes: "failing at a token you do not hold **donates** backing to whoever does." It keeps carriage out: a token carried through a stranger's payment does not claim, because "Attributable" must mean "*bought for*, never *identifiable with*." It leaves one case open: a third party naming a rival's token in a failing operation. The public axiom text still states the consequence principle and keeps failed attempts out of backing. BTI's own law went the other way. Ruleset v1 (2026-08-06) reads "Attribution is backing — one category (B19)" and makes a counterfactual test the gate, with "the consequence principle is the description". The public BTI docs say that a failed operation recorded in its protocol's ledger "still bought its blockspace, and those bytes count as backing". How BTI applies this is covered under [claims](/concepts/claims-t2/), [the books](/concepts/books-t3/) and [carriage](/concepts/carriage-and-the-free-ride-index/). Sources: - block.space docs: the axiom · https://block.space/docs/axiom - The Shared Claim Axiom · https://block.space/docs/axiom - Blockspace Holdings records - block.space docs: BTI · https://block.space/docs/bti Updated: 2026-10-20 --- # Blockspace Value Theory BVT, a living document and an untested thesis: that tokens built on consumed Bitcoin blockspace form one commodity, priced in kilobytes. URL: https://blockspace.wiki/concepts/blockspace-value-theory/ > Theory, not fact. Blockspace Value Theory is a living document and an untested thesis. BTP and BYTES are drafts describing things that do not exist. [Blockspace Value Theory](https://blockspace.wiki/glossary/bvt/) (BVT) is a framework for valuing consumed Bitcoin blockspace. The public text is version 3.0, last updated July 2026, with the status "Living document, subject to revision". It describes itself as "an emerging theoretical position, not established consensus, and several of its central claims are untested." Everything on this page is what BVT proposes, not a finding. ## The claim in brief BVT proposes that [blockspace tokens](https://blockspace.wiki/glossary/blockspace-token/) (BTs), tokens linked to files committed on the Bitcoin blockchain, "derive monetary value from the scarce resource they permanently consume". Its examples are runes, BRC-20s, alkanes, [satoshis with inscriptions](/concepts/inscriptions/), Counterparty assets (stamps, counters) "and all their successors". The theory holds three things about them: - they form one commodity market, denominated in kilobytes; - they have a price floor, the [Blockspace Floor Price](https://blockspace.wiki/glossary/blockspace-floor-price/); - besides bitcoin itself, they are the only commodity "whose supply rules are enforced by proof-of-work consensus". The abstract gives a figure from its own date (July 2026): blockspace tokens account for "nearly 10%" of the chain, 60 GB of 757 GB. It names UNCOMMON•GOODS as the token whose price "serves as the primary indicator of blockspace floor price today". For what the indexer measures now, see [BTI](/concepts/bti/) and [the three books](/concepts/the-three-books/). ## Part I: what blockspace is BVT's first chapter argues that the word does not survive inspection. "Strictly: **blockspace exists only during block construction.**" Before a block there are bids; after it there is data in a block already built. Its formulation: > Blockspace is a socially constructed commodity built on top of a protocol-enforced constraint. From this BVT draws its definition of a token. A blockspace token is not a claim on blockspace, because the space no longer exists. It is "a permanent, verifiable receipt that a specific quantity of the constrained resource was consumed at a specific moment, at a specific cost, and can never be consumed again." BVT splits the life of blockspace into three phases (pre-block, construction, post-block) and calls itself "a theory of **phase three**". More on this is on the [blockspace](/concepts/blockspace/) page. ## Part II: one commodity BVT's roster runs from Ordinals inscriptions (January 2023) through BRC-20, Stamps, Runes, recursive inscriptions, Alkanes, Counterparty v11 taproot envelopes and Bitcoin Counters. "The roster grows. The theory does not depend on any entry in it." Its "one giant collection" thesis says "Format is packaging." Inscriptions, runes, stamps and counters are "vintages and flavors of one commodity". If that is right, the theory expects cross-format arbitrage to push prices toward one price per kilobyte, and the cheapest kilobyte in any format to set the floor. ## Part III: the supply constraint Version 3.0 corrects version 2.0. The old figure of about 210 GB a year is a ceiling, not a schedule: 4 MB × 144 blocks a day × 365 days. Actual issuance "follows the fee market". BVT restates the limit: > **The supply of blockspace tokens is limited to the largest the blockchain could grow while still keeping verification decentralized.** This is the [decentralization constraint](https://blockspace.wiki/glossary/decentralization-constraint/). BVT calls it "a social variable, not a constant", defended by norms rather than mathematics. On the [witness discount](/concepts/witness-discount/), version 3.0 reverses version 2.0. Every node downloads, validates and propagates witness bytes and OP_RETURN bytes alike, so BVT counts raw bytes: "4 MB of witness data consumes 4 MB of the real kilobyte budget." The discount "sells the same scarce resource at one quarter the price through one particular door." BVT calls the choice between pricing by kilobytes or by fees "the central open variable in the entire theory". The July 2026 measurement run on block.space found the ratio of bytes to [vbytes](/concepts/weight-units-and-vbytes/) at 3.374 for inscriptions and 1.0000 for runestones, and reads that ratio as the subsidy each protocol receives. ## Part IV: the floor BVT's core claim is that blockspace tokens have a floor "**always below mint cost and always above zero.**" Below mint cost because a buyer would mint instead; above zero because the consumption is real and permanent. It adds that the floor is the single cheapest listing, that depth matters more than the floor, and that premiums stack on top: vintage, inscription number, mint-count rarity, prestige, encoding efficiency. ## Parts V and VI: energy and utility BVT calls a blockspace token an [anti-battery](https://blockspace.wiki/glossary/anti-battery/): an instrument that gains value in energy terms as the network spends more energy. It grounds this in July 2026 hardware figures and calls the long thesis "a bet that humanity's transition to energy-backed digital value systems succeeds." Part VI lists three uses, DeFi collateral, L2 staking and fee payment. It calls them "**preconditions that have not been built.** None of the three exists in production as of July 2026." ## Part VII: where theory and price diverge BVT says plainly that the market does not price by kilobyte. Ordinals trade by inscription number, not by size. "**The market prices provenance. The theory prices consumption.**" It offers three readings, given here as [Readings A, B and C](https://blockspace.wiki/glossary/readings-a-b-c/): - **Reading A**: the market is immature, and kilobyte pricing will arrive. - **Reading B**: consumption sets the floor, provenance sets the price. BVT calls this "probably the strongest defensible version". - **Reading C**: consumption is not a value driver; the floor is cultural. It admits "BVT is not currently falsifiable as stated" and proposes a test: controlling for inscription number, collection, format and mint era, "price per kilobyte should converge toward a common value." The document says this "has not been measured." It also notes that revealed demand for blockspace as such "remains close to nil." ## Parts VIII and IX: risk and the thesis The risk chapters cover supply expansion by consensus change, the BIP-110 proposal, the post-subsidy fee instability described by Carlsten et al. (2016), thin floors, concentration and legal exposure. BVT closes with seven numbered claims and an eighth that "belongs in the same list rather than in a footnote": "**The market does not currently price this way.**" The practical position it states is "accumulate kilobytes while fees are cheap", alongside the cost of being wrong: "a binary bet on civilizational transformation with no meaningful middle outcome". ## Critiques The BYTES economics document (2026-07-29) stress-tests the floor claim. It splits it into a ceiling half (price cannot sustainably exceed replacement cost) and a floor half (price cannot reach zero). It finds strong support for the first and "essentially none" for the second: "**the theory predicted a floor and the evidence delivered a ceiling.**" It proposes renaming the mint cost anchor a "replacement ceiling". This is a proposal; BVT has not adopted it. ## Companions - [The Shared Claim Axiom](/concepts/attribution-and-the-axiom/) refines BVT's definition of a token. - [BTP](/concepts/btp/) and [BYTES](/concepts/bytes/) are drafts built on the theory. - [Atomicals](/concepts/atomicals-natural-experiment/) is offered as a natural experiment between Readings B and C. Sources: - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - Blockspace Value Theory · https://block.space/docs/bvt - Blockspace Holdings records - block.space docs: measurements · https://block.space/docs/measurements Updated: 2026-10-20 --- # Blockspace What blockspace is: the bytes Bitcoin's blocks hold, as BTI counts them, and what Blockspace Value Theory proposes about them. URL: https://blockspace.wiki/concepts/blockspace/ [Blockspace](https://blockspace.wiki/glossary/blockspace/) is the space in Bitcoin's blocks: the bytes of every transaction a block holds. This page keeps two things apart. The first half is what is measured: how many bytes the chain holds and how the [Blockspace Token Indexer](/concepts/bti/) counts them. The second half is what [Blockspace Value Theory](https://blockspace.wiki/glossary/bvt/) proposes about those bytes. That half is theory, and it is attributed to BVT. ## What is counted [BTI](https://blockspace.wiki/glossary/bti/) "walks every Bitcoin transaction, from the genesis block forward, and counts every byte exactly". For each transaction and each block it records four numbers: raw size, virtual size, weight and fee. "Nothing is sampled and nothing is estimated": the per-transaction counts reconcile against each block's exact serialized size. This first stage is the [byte census](/concepts/byte-census-t1/). The census reads, as of block 972,302, 2026-10-20 10:16:21 UTC: - 972,303 blocks; - 1,464,151,063 transactions; - 777.04 GB of raw bytes; - 567.70 GB in virtual bytes (vbytes). Raw bytes and vbytes are two different measures of the same data. The fee market charges by vbytes, and witness data is discounted in that measure. See [weight units and vbytes](/concepts/weight-units-and-vbytes/) and [the witness discount](/concepts/witness-discount/). BTI keeps every entry in both. ## How it is divided BTI sorts every byte of every block into one of four categories, which together add up to the block's exact size: - **claimed** bytes back a living token; - **carriage** bytes moved a token without being bought for it; - **burned** bytes backed tokens that were provably destroyed; - **unclaimed** bytes back nothing; they are "the majority of every block". No byte is in two categories. The block.space docs call this partition "the Meter's trust anchor". Claimed bytes are written into [the three books](/concepts/the-three-books/). The broadest of them, Book A (the inclusive book), attributes 133.75 GB to tokens, which is 17.21 % of the 777.04 GB it covers (as of block 972,299, 2026-10-20 09:30:48 UTC). Carriage is explained on [carriage and the free-ride index](/concepts/carriage-and-the-free-ride-index/). ## How the use of blockspace changed The July 2026 measurement run on block.space measured data payload as a share of all block bytes at a few heights: | height | share | |---|---| | 450,000 | 0.0 % | | 600,000 | 9.2 % | | 788,000 | 13.4 % | | 833,000 | 45.4 % | | 850,000 | 31.9 % | The docs read the fall after the peak as "runes replacing inscription bodies with 20-byte runestones". The same run measured the ratio of bytes to vbytes per protocol: 3.374 for inscriptions, 1.008 for stamps and 1.0000 for runestones. A higher ratio means a protocol pays for a smaller share of the bytes it uses. ## What BVT proposes blockspace is BVT opens with the claim that the word "does not survive inspection". It argues that blockspace "has no location, no duration, and no existence independent of the moment a block is constructed", and puts it in bold: "**blockspace exists only during block construction.**" Its formulation: > Blockspace is a socially constructed commodity built on top of a protocol-enforced constraint. BVT treats both halves as necessary. The constraint is real: blocks have capacity limits that producers must respect. The commodity is "a useful fiction" that lets markets form around the decision of what goes into a block. BVT divides the life of blockspace into three phases: | Phase | What is traded | |---|---| | Pre-block | Bids for inclusion, derivatives | | Construction | The producer's allocation decision | | Post-block | Blockspace tokens, "receipts of consumption" | BVT says nearly all commentary concerns the first phase, and calls itself "a theory of **phase three**". ## What BVT proposes limits it BVT does its arithmetic at a 4,000,000 weight-unit limit. A maximally witness-heavy block then approaches 4 MB, which gives a ceiling of about 210 GB a year. BVT version 3.0 says this is "a *ceiling*" and not a schedule; actual use "follows the fee market". It places the real limit elsewhere, in the [decentralization constraint](https://blockspace.wiki/glossary/decentralization-constraint/): the supply is "limited to the largest the blockchain could grow while still keeping verification decentralized." On that reading, BVT says, blockspace value is "the value of keeping verification decentralized." BVT also proposes that raw bytes, not vbytes, are the honest measure, because every node downloads, validates and propagates witness bytes in full. BTI's design takes this as a requirement: "raw bytes are the measure; vbytes are an observable", so both are carried everywhere. ## Tokens and blockspace In BVT's terms, a [blockspace token](https://blockspace.wiki/glossary/blockspace-token/) is any asset "whose existence required the permanent consumption of Bitcoin block capacity". It is a receipt, not a claim on capacity. The [Shared Claim Axiom](/concepts/attribution-and-the-axiom/) adds the accounting: how the bytes are shared when several tokens claim the same transaction, and what happens to the bytes no token claims. The axiom notes that "most consumed blockspace has no claim on it at all", which matches the unclaimed majority the books measure. ## A limit on measurement BVT records a limit on how any byte census of this kind is built. Protocols are found by their markers, and "it fails silently against any protocol that obfuscates its marker." A byte scan on 2026-08-04 found zero SRC-721 occurrences across blocks 820,600 to 823,200 while Counterparty's own API showed SRC-721 mints live. So BVT says a figure for unattributed bytes should be read as "not attributable by marker detection", which "is a claim about the instrument, not about the chain." Sources: - block.space docs: BTI · https://block.space/docs/bti - block.space docs: measurements · https://block.space/docs/measurements - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: the axiom · https://block.space/docs/axiom - Blockspace Holdings records - block.space meter and summary APIs · https://block.space/api/summary Live figures: books as of block 972,299, 2026-10-20 09:30:48 UTC; census as of block 972,302, 2026-10-20 10:16:21 UTC Updated: 2026-10-20 --- # The books (T3) BTI's third layer: a pure function of T1 and T2 that divides shared bytes among tokens, allocates fees and writes the book entries, the aggregates and the consensus hash. URL: https://blockspace.wiki/concepts/books-t3/ [T3](https://blockspace.wiki/glossary/the-books/) is the third of [BTI](https://blockspace.wiki/glossary/bti/)'s three layers: accounting. It is a pure function of T1 and T2. It counts claimants per byte interval, applies the dedication gate, splits remainders by the division formula, allocates fees, writes the [book entry](https://blockspace.wiki/glossary/book-entry/) rows and aggregates, and emits the [consensus hash](https://blockspace.wiki/glossary/consensus-hash/). The layers document's phrase for it: T3 "judges worth". ## Derived, never facts The design document is firm that this layer carries no information of its own. It exists because the questions are expensive, not because they are primitive. It can be deleted and recomputed at any time, and the design calls that "a design invariant, not an optimization note". Rebuilding T3 alone, from T2, with T2 and T1 untouched, is the cheap repair, and it is what a change of formula or judgment costs. ## The division formula Ruleset v1, §6: ``` pool = tx.size + Σ enabler shares (an enabler splits across the transactions it enabled, by size) B_i = the measured byte-diff (the claim's declared regions alone) dedicated: A_i = B_i + (pool − ΣB) / n_ded riding: A_i = B_i fee_i = poolFee · A_i / pool ``` - **n, the number of claimants on a byte, comes from the claim set**, never from an adapter. The design notes it can rise years later, when recognition improves, and claim facts never rewrite. - **Division counts tokens, never rows.** The design calls a divisor that counts region rows the first build's most dangerous latent bug: it would silently halve co-claimed bytes the moment a second source sighted the same token. - **Enablers enter the pool**, so their bytes surface in [Book A](https://blockspace.wiki/glossary/book-a/) and nowhere else. - **Fees exist at pool scope** and follow Book A. - **Riding claims** keep A = B; by default a claim with no dedication is carriage and is zero in all books. See [carriage and the free-ride index](/concepts/carriage-and-the-free-ride-index/). ## What a book entry holds One row per transaction and token, with three disjoint components, content, structure and overhead, in both bytes and vbytes, and a fee share. [Book C](https://blockspace.wiki/glossary/book-c/) is content, [Book B](https://blockspace.wiki/glossary/book-b/) adds structure, and Book A adds overhead. The books are a view over the row and are never stored. Because the ordering C ≤ B ≤ A follows from addition, the check that used to police it was retired. What remains is one write rule: components are non-negative, and a row with content above zero has its structure measured. See [the three books](/concepts/the-three-books/). ## A worked division Case 5 of the BTI case studies is an alkanes swap at block 911,180: a 450-byte transaction whose single protostone touched five alkanes: three contracts it invoked (a router and pool contracts) and the two tokens swapped. All five claims are dedicated and declare identical regions covering the whole transaction. - Every byte has n = 5, so each token's Book B is 450 ÷ 5 = 90 bytes. - Content is 0 everywhere; contract calls carry no envelope. - The remainder is 0, so each Book A is also 90 bytes. - The 329-sat fee divides the same way: 65.8 sats each. - Conservation: 5 × 90 + 0 = 450, the pool. The case study's comment: a divisor that counted rows instead of tokens would have been invisible here in every aggregate except the conservation line. ## The checks The design lists invariants checked on every increment. The census buckets sum to the block's bytes. The sum of shares equals the sum of claimed bytes in each co-claim group. Supply is conserved across burns and successions. Each case study ends with the same kind of conservation line: the tokens' Book A plus any unattributed remainder equals the pool, with every byte placed. ## Aggregates and the hash T3 keeps running sums per token, per protocol and per block, updated as each window lands rather than rescanned. Each committed window's rows are chained into the books hash, the [consensus hash](https://blockspace.wiki/glossary/consensus-hash/), so two operators running the same ruleset can agree, or find the window where they stopped agreeing. ## Live figures The books [cursor](https://blockspace.wiki/glossary/cursor/) stood at block 972,299, behind the claims cursor at 972,301 (as of block 972,301, 2026-10-20 09:35:17 UTC). The books then held 133.75 GB in Book A, 126.98 GB in Book B and 36.38 GB in Book C, over 126,874,922 tokens (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space meter and summary APIs · https://block.space/api/summary Live figures: books as of block 972,299, 2026-10-20 09:30:48 UTC; frontier as of block 972,301, 2026-10-20 09:35:17 UTC Updated: 2026-10-20 --- # BTI, the Blockspace Token Indexer The instrument behind every block.space number: it counts every byte, catalogues every token operation, and writes three books of attribution. URL: https://blockspace.wiki/concepts/bti/ [BTI](https://blockspace.wiki/glossary/bti/), the Blockspace Token Indexer, is the instrument that produces every number the block.space meter displays. In the words of its site documentation it does three things: it counts the bytes, it catalogues the operations, and it writes [the books](https://blockspace.wiki/glossary/the-books/). This page describes what it does, the design it follows and its three layers. ## What it does **It counts the bytes.** BTI walks every Bitcoin transaction from the genesis block forward and records each one's [raw size](https://blockspace.wiki/glossary/raw-bytes/), virtual size, weight and fee, per transaction and per block. Nothing is sampled or estimated: the per-transaction counts reconcile against each block's exact serialized size. As of the latest reading it had counted 1,464,151,063 transactions and 777.04 GB of chain bytes (as of block 972,302, 2026-10-20 10:16:21 UTC). **It catalogues the operations.** Each token protocol writes its operations into transactions. BTI reads each protocol under that protocol's own published rules and records, per transaction, which tokens the transaction had a consequence for: what was created, moved or destroyed. It indexes 21 protocols and knows 126,874,922 tokens across 623,681,326 operations (as of block 972,299, 2026-10-20 09:30:48 UTC). **It writes the books.** For each token a transaction touched, BTI writes three parallel entries: [Book A](https://blockspace.wiki/glossary/book-a/) (inclusive), [Book B](https://blockspace.wiki/glossary/book-b/) (regional) and [Book C](https://blockspace.wiki/glossary/book-c/) (content). On every entry C ≤ B ≤ A. Book A totals 133.75 GB, Book B 126.98 GB and Book C 36.38 GB (as of block 972,299, 2026-10-20 09:30:48 UTC). See [the three books](/concepts/the-three-books/). ## The design: what BTI must answer BTI's design document (draft 0.2, 2026-08-06) derives the indexer from the theory documents alone, Blockspace Value Theory, the Shared Claim Axiom, BTP and BYTES, and treats the first build as evidence rather than a template. It lists the questions the indexer must answer. Among them: - **Backing per token**, in raw bytes, for every token. - **The states of every byte**: claimed, unclaimed or burned, per block and cumulatively. - **Instrument honesty.** A marker census cannot see a protocol that hides its marker, so "unclaimed" is an upper bound, and BTI must publish its own blind spots. - **Raw bytes are the measure; vbytes are an observable.** The books apply no weight discount, but both measures are carried everywhere, because their ratio is the [witness discount](https://blockspace.wiki/glossary/witness-discount/). - **Determinism.** BTI's output is meant to be a pure function of the chain and a versioned [ruleset](https://blockspace.wiki/glossary/ruleset/): `state = F(chain[0..h], ruleset)`. The design calls this the single strongest constraint on the whole design. ## The three layers The pipeline runs, in the layers document's words: "T1 sees bytes → T2 records claims → T3 judges worth." - **T1, observation.** One protocol-blind pass over the chain: every transaction's size, vsize, weight and fee, and the byte census of where data carriers sit. See [the byte census](/concepts/byte-census-t1/). - **T2, claims.** Adapters and BTI's own decoders turn protocol records into append-only facts: token X touched transaction Y at these regions. See [claims](/concepts/claims-t2/). - **T3, accounting.** A pure function of T1 and T2 that divides shared bytes, allocates fees, writes the book entries and emits the [consensus hash](https://blockspace.wiki/glossary/consensus-hash/). See [the books](/concepts/books-t3/). The layering law: observation writes no protocol knowledge, claims write no arithmetic, and accounting writes no facts. Each layer can be checked against the one below it. A wrong census number is caught against bitcoind, a wrong claim against the protocol's record, and a wrong book by recomputing it. ## The engine The design settles on one process that advances in increments. Each increment runs observe, catalogue and account inside one database transaction, and each stage has its own [cursor](https://blockspace.wiki/glossary/cursor/): census, claims and books, with books ≤ claims ≤ census. See [the frontier](/concepts/the-frontier/). The decisions recorded in the design: Postgres for storage, Go for the engine, and 5,000-block increments as the starting size. Each tier can be rebuilt from the tier below it on its own. T3 can be recomputed from T2 when a formula changes. One protocol's T2 can be redone from T1 when a protocol fact changes. T1 stands beneath every ruleset; it is re-observed only for a bug in observation itself. Adapters are pure incremental state machines: no replay, bounded memory, isolation (an adapter records what its own token claimed and stops), and keys that admit several assets on one output and several sources for one token. An unreachable source is a refusal, never a zero, and no increment may pass the height of any source it depends on. ## The law it applies [Attribution](https://blockspace.wiki/glossary/attribution/) follows ruleset v1: five kernel rules (U1 to U5), one division formula, two named judgments and a table of protocol facts. The kernel's first rule is counterfactual: a byte is attributed to a token if the token's involvement is why the byte exists, or why it has the value it has. The axiom behind it is covered in [attribution and the axiom](/concepts/attribution-and-the-axiom/). ## Every byte counted once Each block's bytes fall into four categories, [claimed](https://blockspace.wiki/glossary/claimed-bytes/), [carriage](https://blockspace.wiki/glossary/carriage/), [burned](https://blockspace.wiki/glossary/burned-bytes/) and [unclaimed](https://blockspace.wiki/glossary/unclaimed-bytes/), which sum to the block's exact size with no byte in two of them. The site documentation calls this partition the meter's trust anchor. See [conservation](https://blockspace.wiki/glossary/conservation/). ## Names On this wiki the first version of BTI is called BTI-old. The documents on this page describe the current design. Sources: - block.space docs: BTI · https://block.space/docs/bti - Blockspace Holdings records - block.space meter and summary APIs · https://block.space/api/summary Live figures: books as of block 972,299, 2026-10-20 09:30:48 UTC; census as of block 972,302, 2026-10-20 10:16:21 UTC Updated: 2026-10-20 --- # BTP, the Blockspace Token Protocol BTP is a draft (0.1, 2026-07-29) of a protocol whose subject is blockspace itself: which token owns which consumed bytes. It does not exist. URL: https://blockspace.wiki/concepts/btp/ > Theory, not fact. Blockspace Value Theory is a living document and an untested thesis. BTP and BYTES are drafts describing things that do not exist. [BTP](https://blockspace.wiki/glossary/btp/), the Blockspace Token Protocol, is a design draft. Blockspace Holdings' records hold draft 0.1, dated 2026-07-29. It describes something that does not exist: its marker encoding, op codes and composition rules are, in its own word, "unwritten". The draft says of itself: "Status: design draft; decisions marked OPEN are undecided." This page reports what the draft describes. ## What the draft describes The draft calls BTP "an **attribution-layer protocol**". It works on [backing](https://blockspace.wiki/glossary/backing/), the claim layer defined by the [Shared Claim Axiom](/concepts/attribution-and-the-axiom/), rather than on any host protocol's ledger: > Where every existing metaprotocol answers "who owns which token," BTP answers "which token owns which consumed bytes," and makes that ownership *transactable*. Its state would be "a set of backing assignments, deterministically derivable by anyone from chain data plus published rules." The draft calls it "the first protocol whose subject matter IS blockspace." It sees BTP as two passages of the axiom made operational: the idea that a new protocol could claim unclaimed blockspace, and the burn rules. It places BTP in a stack: [Blockspace Value Theory](/concepts/blockspace-value-theory/) (the theory), the Shared Claim Axiom (the accounting rules), [BYTES](/concepts/bytes/) (the native token) and [BTI](/concepts/bti/) (the reference indexer). ## The operations The draft has one marker namespace with several operations per transaction. "Invalid ops mint or move nothing, and are measured as failed demand — never backing." 1. **MINT** issues BYTES against the transaction's own bytes. A declared amount is "valid iff x ≤ tx size in bytes; over-declaration is hard-invalid". 2. **TRANSFER** moves BYTES in explicit records; balances ride UTXOs. The handling of malformed transfers is OPEN. 3. **SUCCEED** is a directed burn: "**Any token is burnable for any other token.**" It joins the provable destruction of token A, under A's own rules, to the naming of a successor B. A's backing then moves to B. This is [backing succession](https://blockspace.wiki/glossary/backing-succession/). 4. **ATTRIBUTE** (proposed) declares "x bytes of this transaction's blockspace go to token X". The declarer claims only the residual, the bytes no other claimant's structure holds. 5. **CLAIM** (phase 2) attributes a historical transaction's unclaimed bytes to whoever proves they controlled one of its inputs. It is "Deliberately deferred" because it would open a large cheap-vintage supply. ## Succession and conservation SUCCEED has two forms in the draft. In the **donation form**, B's total backing grows and its supply does not change, so every B holder's per-unit backing rises. It "needs nothing from B's protocol". In the **exchange form**, burning A also mints the target token to the burner, priced by A's backing at the burn height. Only BYTES would honour this at first, and it needs a "backing oracle". Succession is terminal for A. Burned tokens cannot receive, so successions form a graph with no cycles. The draft names conservation as the invariant: "backing moves, it is never created." ## The burn taxonomy The draft sorts every burn into three kinds. In all of them "**the burn transaction itself claims its own bytes**". | Burn | Per-unit backing | Where the backing goes | |---|---|---| | Undirected partial | rises doubly | stays inside the token | | Directed (SUCCEED) | siblings unaffected | the successor | | Full population, undirected | none (token dead) | co-claimants, else the blockspace is burned | The draft calls a simple burn "a double pump": the burn transaction adds bytes and the destroyed units reduce supply. Its example is Counterparty's XCP anti-spam fees, which are destroyed rather than paid: "3,858.58 XCP gone through block ~340k by BTI's measure." ## Consensus and the reference indexer BTP state would be computed by BTI. The draft requires pinned, versioned rulesets; "A rolling consensus hash over BTP state for cross-indexer agreement"; and a reproducible backing figure for the exchange form. "Exchange therefore activates only when pinned-ruleset backing computation is reproducible across independent BTI instances." BTI's design, draft 0.2, takes these as requirements R12 and R13. ## What the draft says it does to the theory - It would give BVT's "one giant collection" thesis arbitrage plumbing, a mechanism that "could actually drive per-KB price convergence." - Holders of dead-protocol tokens, ARC-20 for example, could exit by burning into live tokens. The [Atomicals experiment](/concepts/atomicals-natural-experiment/) would gain "an observable exit ramp". - The honest cost: backing becomes "partly portable ballast". A token's history would be its own consumption plus what it received by succession. ## OPEN decisions The draft leaves these undecided: the carrier and marker encoding (a runes-style OP_RETURN marker is "the lean"); defaults for malformed operations; whether SUCCEED-donation ships before exchange; and whether CLAIM is included at all. ## Risks the draft states - The [concealed co-claim](https://blockspace.wiki/glossary/concealed-co-claim/): minting or declaring against a transaction that also carries an unrecognised protocol's token, selling at face value and leaving the dilution to buyers. The draft's answer is "disclosure, not prohibition": publish unexplained bytes per claimed transaction and the backing-ratio history. - "BTP's authority is accounting-layer consensus". "Adoption is the protocol." - The exchange form inherits every open risk in BYTES, plus oracle reproducibility. - BTP transactions consume blockspace themselves, so the order in which operations in one transaction interact must be specified exactly. Sources: - block.space docs: BTP · https://block.space/docs/btp - BTP, the Blockspace Token Protocol, draft 0.1 · https://block.space/docs/btp - block.space docs: the axiom · https://block.space/docs/axiom - block.space docs: BYTES · https://block.space/docs/bytes - Blockspace Holdings records Updated: 2026-10-20 --- # The byte census (T1) BTI's first layer: one protocol-blind pass recording every transaction's size, vsize, weight and fee, and where in each block the data sits. URL: https://blockspace.wiki/concepts/byte-census-t1/ [T1](https://blockspace.wiki/glossary/the-census/) is the first of [BTI](https://blockspace.wiki/glossary/bti/)'s three layers: observation. It makes one pass over the chain and records, for every transaction, its size, vsize, weight and fee, plus the byte census: where the data carriers are. T1 knows only bytes. In the layers document's words, its totals are "the ground truth everything above must conserve against." ## What it records The design document names three products from one decode of each block: - **the ledger**: per transaction, its [size](https://blockspace.wiki/glossary/raw-bytes/), vsize, weight and fee. Fees need the outputs being spent and sizes do not, so the two may advance at different speeds, but a block is not observed until both exist. - **the census**: the same bytes by kind, such as frame, outpoints, signatures, data payload and **unexplained**. Unexplained is where the instrument says what it could not account for, transaction by transaction. - **carriers**: data-carrying structures recognised by their shape, such as an [envelope](https://blockspace.wiki/glossary/envelope/), an `OP_RETURN` output, bare multisig or an appropriated field, each recorded with its prefix, whatever it is. This is how protocols nobody named get found. ## Protocol-blind by law The design says observation is protocol-blind "by law, not by convenience". Its facts must survive every future change in what BTI knows about protocols, because recognition can arrive years later and must find the observations already waiting. So T1 records what the instrument saw, never what it inferred. Blockspace Value Theory (§2.2a) explains why this matters. A census that looks for markers cannot see a protocol that hides its marker: Counterparty encrypts its payloads, and a 2026-08-04 byte scan for SRC-721 found zero occurrences while Counterparty's own API showed mints live. BVT concludes that "unclaimed bytes" is therefore an upper bound, and that it should be stated as "not attributable by marker detection", a claim about the instrument rather than the chain. ## The checks T1 is checked against bitcoind. The design lists invariants that can fail on every increment: the census buckets sum to the block's bytes, and BTI's computed sizes equal bitcoind's. The case studies (2026-08-10) cross-check T1 numbers against raw transaction hex through an independent parse that asserts two identities: the components sum to the size, and `base × 3 + size = weight`. The data-types reference gives the block-level check: a block's size is the 80-byte header plus the transaction-count varint plus the sum of the transaction sizes. A small detail of the store, from the case studies: the per-transaction census table keeps rows only where unexplained is above zero, so a missing row means "unexplained = 0, by construction". ## An example Case 10 of the case studies, the first BRC-20 mint at block 779,833, as T1 sees it: size 338, vsize 155, weight 620, fee 4,650. The components are a 10-byte frame, a 2-byte witness frame, a 41-byte input, a 43-byte output and a 242-byte witness. The witness holds a 64-byte signature, a 141-byte tapscript and a 33-byte control block. Inside it T1 finds an ord envelope (marker `6f7264`) whose body is 71 bytes of `text/plain` JSON. Nothing in this is about BRC-20; that is T2's business. ## Live figures The census had walked 972,303 blocks, holding 1,464,151,063 transactions, 777.04 GB of raw bytes and 567.70 GB of vbytes (as of block 972,302, 2026-10-20 10:16:21 UTC). The census [cursor](https://blockspace.wiki/glossary/cursor/) stood at block 972,302, against a chain tip of 972,304 (as of block 972,301, 2026-10-20 09:35:17 UTC). ## What the census has shown The July 2026 measurement run, from block.space's measurements document, gives data payload as a share of all block bytes: | height | share | what was happening | |---|---|---| | 450,000 | 0.0 % | pre-ordinals: the chain is payments | | 600,000 | 9.2 % | Omni, Counterparty, early OP_RETURN | | 788,000 | 13.4 % | BRC-20 mania | | 833,000 | 45.4 % | the peak: nearly half of Bitcoin is payload | | 850,000 | 31.9 % | recession after runes moved to OP_RETURN | The document reads the fall from 45.4 % to 31.9 % as runes replacing inscription bodies with 20-byte runestones: a protocol getting more efficient reduced the chain's data share while increasing the number of tokens. ## Its place in BTI T1 is the one tier that never versions. Rulesets and adapters come and go above it, and it is re-observed for exactly one reason: a bug in observation itself. [Claims (T2)](/concepts/claims-t2/) read its observations; [the books (T3)](/concepts/books-t3/) must conserve against its totals. Sources: - Blockspace Holdings records - block.space docs: BTI · https://block.space/docs/bti - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: measurements · https://block.space/docs/measurements - Blockspace Value Theory · https://block.space/docs/bvt - block.space meter and summary APIs · https://block.space/api/summary Live figures: 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 Updated: 2026-10-20 --- # BYTES, a fungible blockspace token BYTES is a draft (0.2, 2026-07-29) of a token minted one per byte of consumed blockspace. It does not exist; its economics are analysed in a companion document. URL: https://blockspace.wiki/concepts/bytes/ > Theory, not fact. Blockspace Value Theory is a living document and an untested thesis. BTP and BYTES are drafts describing things that do not exist. [BYTES](https://blockspace.wiki/glossary/bytes-token/) is a draft design for a fungible [blockspace token](https://blockspace.wiki/glossary/blockspace-token/). Blockspace Holdings' records hold draft 0.2, dated 2026-07-29; it was called BITS in draft 0.1 earlier the same day. The token does not exist. Nothing has been minted and its carrier encoding is unwritten. This page reports what the draft describes and what a companion analysis, BYTES economics (2026-07-29), concludes about it. The draft's notation: "all-caps BYTES = the token; lowercase bytes = the unit." ## The idea > BYTES is a fungible token minted by attributing a transaction's consumed blockspace to it — one token per byte — making consumed blockspace itself tradeable, and making price-per-KB directly observable for the first time. "**1 BYTES = 1 byte of consumed blockspace**", so the kilobyte price is the BYTES price × 1,000. ## Why it matters to the theory The draft ties BYTES to [Blockspace Value Theory](/concepts/blockspace-value-theory/): - It strips the packaging from BVT's "one giant collection" thesis: consumed blockspace "with no artifact attached". - It would be "A live ticker for Part VII". BVT's convergence test needs a regression; if BYTES traded, "The convergence test becomes a quote." - Its ceiling tracks replacement cost block by block, since BYTES can always be minted at the current fee cost of its own bytes. - "Vintage erasure, deliberately." A byte minted in a cheap era and one minted today are the same. "It is the index fund of blockspace". ## Minting A transaction carrying the BYTES marker mints BYTES. A declared amount is "**valid iff x ≤ tx size in bytes**"; over-declaration "mints nothing". Omitting the amount mints the full measured size. Minting less is legal, and the whole transaction still backs the smaller supply. The draft gives a wallet algorithm for the case where writing the number changes the size it measures. "Anyone can mint; the cost is the fee on the minting transaction", so issuance is "a **perpetual fair mint priced by the fee market**." ### The clean-mint rule (proposed) The [clean-mint rule](https://blockspace.wiki/glossary/clean-mint-rule/) would forbid a mint transaction from carrying any data structure other than the BYTES marker. Its purpose is to close the [concealed co-claim](https://blockspace.wiki/glossary/concealed-co-claim/): because BYTES is fungible, buyers cannot inspect each mint, so a mint that hid another protocol's token could later dilute the whole pool. The cost: BYTES "cannot be minted in the same transaction as an inscription or other token op." The public draft marks one question OPEN: whether a mint is provably claimed by BYTES alone (n = 1). Spending ordinary sats does not break it. Spending an already-inscribed sat might, if passive carriage applies to sats as it does to runes. "Decide it on its own merits, not to save BYTES." See [carriage](/concepts/carriage-and-the-free-ride-index/) and [sats and ordinals](/concepts/sats-and-ordinals/). ## Ledger, price and supply Balances would ride UTXOs, runes-style, with explicit transfer records. The draft holds that BYTES' price "IS the Blockspace Floor Price, by construction", because it carries no vintage, provenance or content premium. Trough conditions put its ceiling near "0.035 sat per BYTES ≈ $0.035/kB at $100k BTC", the same figure as BVT's worked example. Supply would act like a thermostat. Above parity, minting pays and issuance resumes; below it, minting stops and demand alone sets the price. The draft's caveat: "the ceiling is computable and empirically confirmed (UNCOMMON•GOODS); the floor is asserted but unevidenced." Supply would be unbounded in count but limited in rate to the bytes consumed, up to about 4,000,000 per block. Supply and backing are kept apart: the one-per-byte peg "is not enforced; it is **measured**" through each population's [backing ratio](https://blockspace.wiki/glossary/backing-ratio/). ## Decisions and open questions Decided in the draft: raw bytes as the denomination (a vbyte-denominated sibling, VBYTES, "remains possible"), and explicit mint amounts that are hard-invalid on over-declaration. OPEN: **the redemption sink**, "a launch requirement". As specified, BYTES is "a one-sided peg (minting = hard ceiling; nothing enforces a floor)". The lever the draft names is "BYTES-for-inclusion at a mining pool". The carrier protocol is also OPEN. Burn-to-mint and retroactive claims moved to [BTP](/concepts/btp/) as SUCCEED and CLAIM. "A BYTES mint is ATTRIBUTE-to-BYTES plus issuance." ## BYTES economics The companion analysis (written as "BITS Economics", same date, renamed in its header) runs five investigations. Its market figures are snapshots from public sources in late July 2026. Its verdicts, as the document states them: 1. **The floor claim.** UNCOMMON•GOODS is BVT's own primary indicator. The document finds that it "trades almost exactly at its trough-window replacement cost". Its conclusion: "**replacement cost is a ceiling that works and a floor that does not exist.**" 2. **Terminology.** It proposes one term per concept: consumed, content and attempted KB; backing and backing ratio; price per kilobyte (PPK); a [replacement ceiling](https://blockspace.wiki/glossary/replacement-ceiling/); trough parity; and a split of price into blockspace value plus vintage, provenance and content premiums. It flags "Blockspace Floor Price" and "mint cost anchor" for replacement. 3. **Fee payment.** Paying for inclusion with blockspace tokens is "coherent, not viciously circular". Its precedents are Ethereum's gas tokens and out-of-band pool accelerators. The gate is "adoption reflexivity, not economics." 4. **Not a stablecoin.** "It is not one and must not be sold as one". It calls BYTES a "ceiling-pegged commodity token", one redemption channel away from a two-sided peg. 5. **Supply increases.** The unit survives any consensus change and supply cannot grow faster than the chain, but the price is "maximally exposed to supply expansion". Its one load-bearing conclusion: "a proven, arbitrage-enforced ceiling with no floor", so every path to BYTES being "more than a fee-trough tracker" runs through the redemption sink. ## Risks the draft states - Its value proposition "is precisely BVT's untested claim". If the floor is cultural (Reading C), "BYTES trades to zero". The draft calls it "the cleanest possible falsification instrument for the theory, in both directions." - With flat fees it never appreciates above replacement cost. - Even minting needs a canonical indexer; [BTI](/concepts/bti/) is "the obvious candidate". - The name and the unit can be confused, which the notation manages. Sources: - block.space docs: BYTES · https://block.space/docs/bytes - BYTES, a fungible blockspace token, draft 0.2 · https://block.space/docs/bytes - Blockspace Holdings records - block.space docs: BTP · https://block.space/docs/btp - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # Carriage and the free-ride index Bought or riding: why bytes a token merely rode are measured but never backing, and how B/A shows how much of a token's inclusive claim is its own. URL: https://blockspace.wiki/concepts/carriage-and-the-free-ride-index/ A token can be in a transaction in two ways. The transaction can have been **bought** for it, or the token can merely **ride** a transaction that would have happened anyway. [BTI](https://blockspace.wiki/glossary/bti/) keeps the two apart. Bytes a token rode are [carriage](https://blockspace.wiki/glossary/carriage/): measured in full, and never [backing](https://blockspace.wiki/glossary/backing/). The site documentation puts it this way: carriage answers what moved through the blockspace; backing answers what the blockspace was bought for. ## Bought and riding 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. Such a claim is [dedicated](https://blockspace.wiki/glossary/dedicated/). The ruleset's working test (B1a) is that "every substantive output serves the token or is change"; sale consideration counts as serving the token. A token rides when the transaction would have happened without it, such as a payment or a consolidation that carried the token along. The ruleset's examples: - a rune drifting through someone's payment; - an inscribed sat being sent; - airdropped dust, which "buys dust-sized backing", and the ruleset says this closes the airdrop attack. A passive movement like these is a [sighting](https://blockspace.wiki/glossary/sighting/). The location change is recorded as a fact, the byte-diff is zero, and the judgment is carriage. ## What each books The division formula in ruleset v1 (§6) treats the two cases differently: ``` pool = tx.size + Σ enabler shares dedicated: A_i = B_i + (pool − ΣB) / n_ded riding: A_i = B_i ``` - A dedicated claimant gets its own measured regions (Book B) plus an equal share, among the dedicated claimants, of what is left of the pool. That remainder is the overhead in [Book A](https://blockspace.wiki/glossary/book-a/). - A riding claimant keeps only its own measured regions, so its Book A equals its Book B. - If every claimant aboard is riding, the remainder stays with the transaction. In the ruleset's words, "backing belongs to buyers, and every claimant aboard was a passenger." Case 21 in the case studies, an Omni send that also paid a stranger, is this all-riding case. - By default (mode B25), a claim with no dedication at all is judged carriage and is zero in all three books. A flag, `--with-riding-tokens`, can promote such claims, and the mode is stamped in the books' metadata. ## The free-ride index The [free-ride index](https://blockspace.wiki/glossary/free-ride-index/) is Book B divided by Book A: the fraction of a token's inclusive claim that is its own measured structure. The ruleset's display law (B9) says Book A is always published with B/A beside it, and names the published indices as the dedicated share and the within-dedicated ratio. A value near 1 means a protocol built its own transactions. A low value means most of what it claims under the inclusive book is somebody else's payment. The measurements document says two protocols can have identical inclusive totals and mean completely different things, and calls this ratio "the strongest argument that one number was never enough." ## Measured cases From the July 2026 measurement run (block.space's measurements document): - **Open Assets, B/A = 0.72.** In the document's words, 29 % of its inclusive claim is riding on payments that were happening anyway. - **CoinSpark, a three-regime collapse: 1.00 → 0.91 → 0.09.** Measured separately, its regimes read: genesis 0.913, dedicated transfer 0.963 and protocol-unaware carriage 0.405, with a per-claim floor of 0.026. In its late regime CoinSpark moved token state using the default route, with no carrier bytes at all. The document calls it the most extreme free-ride measurement recorded. - **EPOBC, free-carrier fraction 1.0.** Its colour is encoded entirely in the input-0 `nSequence` field, which every transaction already has. The marginal bytes for carrying the token are zero. Under Book B it claims essentially nothing; under Book A it claims whole transactions. The document notes that ratios such as B/A are the durable findings: they hold as measurement advances, while shares of chain totals move. ## Where carriage sits in the block Carriage is one of the four categories every block divides into, beside claimed, burned and unclaimed bytes. No byte is in two of them, and the four sum to the block's exact size. See [conservation](https://blockspace.wiki/glossary/conservation/). Sources: - block.space docs: BTI · https://block.space/docs/bti - Blockspace Holdings records - block.space docs: measurements · https://block.space/docs/measurements Updated: 2026-10-20 --- # 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. URL: https://blockspace.wiki/concepts/claims-t2/ [T2](https://blockspace.wiki/glossary/claims/) is the second of [BTI](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/native-protocol/): 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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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,301 (as of block 972,301, 2026-10-20 09:35:17 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: - Blockspace Holdings records - block.space meter and summary APIs · https://block.space/api/summary Live figures: books as of block 972,299, 2026-10-20 09:30:48 UTC; frontier as of block 972,301, 2026-10-20 09:35:17 UTC Updated: 2026-10-20 --- # Fee rate What a transaction pays per vbyte, why a witness byte costs a quarter of a base byte, and how BTI divides fees among the tokens a transaction was bought for. URL: https://blockspace.wiki/concepts/fee-rate/ A transaction's [fee rate](https://blockspace.wiki/glossary/fee-rate/) is what it pays per virtual byte, written in sats per vbyte (sat/vB). Fee markets price [vbytes](https://blockspace.wiki/glossary/vbytes/), not raw bytes. This page covers what a rate means for different kinds of bytes, the figures Blockspace Holdings' documents record, and how [BTI](https://blockspace.wiki/glossary/bti/) carries fees in its books. ## What a rate buys block.space's data-types reference states the rule: at a fee rate of f sat/vB, a [witness](https://blockspace.wiki/glossary/witness/) byte costs f/4 sats and a non-witness byte costs f sats. That follows from weight: a witness byte is 1 [weight unit](https://blockspace.wiki/glossary/weight-unit/) and a non-witness byte is 4, and a vbyte is a quarter of the weight. See [weight units and vbytes](/concepts/weight-units-and-vbytes/) and [the witness discount](/concepts/witness-discount/). Blockspace Value Theory's appendix of formulas writes the cost of a mint the same way: ``` Mint cost = fee_rate(sat/vB) × size(vB) × BTC_price Mint cost per KB = (sat/vB) × (vB per KB) × ($/sat) ``` ## Fee rates in the documents BVT records the fee environment of early to mid 2026 as "sustained periods at 0.13–0.14 sat/vB, with AntPool accepting sub-1 sat/vB inscriptions", and calls it historically anomalous. Its worked example (§3.6) at 0.14 sat/vB: ``` Fee rate: 0.14 sat/vB Block capacity: 1,000,000 vB Witness ratio: ~4 bytes per vB Bytes per block: ~4,000,000 = 4,000 KB Cost per block: 140,000 sats At $100,000/BTC: $140 per 4 MB = $0.035 per KB ``` *BVT is a living document and an untested thesis.* It draws an accumulation objective from this example, "maximize kilobytes consumed per satoshi spent", which in practice means Taproot witness data at the lowest sustainable fee rate. Rates below 1 sat/vB matter to [Blockspace Holdings' own Bitcoin node](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/), which relays them. See [relay policy](/concepts/relay-policy/). ## Two real transactions From the BTI case studies (2026-08-10): - **The first BRC-20 mint** (block 779,833): 155 vB, fee 4,650 sats. - **A 3.9 MB jpeg inscription** (block 960,962): 977,936 vB, fee 1,476,683 sats. Its commit transaction, mined 56,161 blocks earlier, paid 406 sats more. ## How the books carry fees BTI's ledger keeps every transaction's fee beside its sizes. The design document notes that fees need the outputs being spent and sizes do not, so the two may advance at different speeds, but a block is not observed until both exist. In the books, fees follow bytes. Ruleset v1's formula: ``` fee_i = poolFee · A_i / pool ``` A token's share of a transaction's fee is its share of the pool's bytes under [Book A](https://blockspace.wiki/glossary/book-a/), and an enabler's fee rides along with its bytes. In case 7, the jpeg's sat carries both fees, 1,477,089 sats, "the sat bought both", in the case study's words. In case 10, the first BRC-20 mint, the 4,650-sat fee splits between the sat and the tick by their Book A shares: about 3,913.98 sats and 736.02 sats. ## Live figures Over the whole chain the census has counted 30,078,457,217,912 sats in fees, over 567.70 GB of vbytes (as of block 972,302, 2026-10-20 10:16:21 UTC). The fees the books attribute to the four largest families by Book A (as of block 972,299, 2026-10-20 09:30:48 UTC): | family (key) | fees attributed (sats) | Book A | |---|---|---| | Ordinal Sats (`sat`) | 604,023,782,900 | 56.13 GB | | Runes (`rune`) | 248,847,428,574 | 33.05 GB | | BRC-20 (`brc20`) | 331,317,657,239 | 17.49 GB | | Alkanes (`alkane`) | 6,120,479,708 | 11.95 GB | Sources: - block.space docs: data types · https://block.space/docs/datatypes - Blockspace Value Theory · https://block.space/docs/bvt - Blockspace Holdings records - block.space docs: BTI · https://block.space/docs/bti - block.space meter and summary APIs · https://block.space/api/summary - block.space protocols API · https://block.space/api/protocols Live figures: census as of block 972,302, 2026-10-20 10:16:21 UTC; protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Holders and share of backing Who holds the tokens BTI measures, and how each token's bytes divide among its holders: the holders appendix, the rule of shares, coverage, and the leaderboard population. URL: https://blockspace.wiki/concepts/holders/ [BTI](https://blockspace.wiki/glossary/bti/) attributes bytes to tokens, never to addresses. To say how much blockspace stands behind an address, something has to know who holds each token. At Blockspace Holdings that is the job of [the holders appendix](https://blockspace.wiki/glossary/the-appendix/). This page covers what the appendix is, the rule by which a token's bytes divide among its [holders](https://blockspace.wiki/glossary/holder/), what it can and cannot see, and the population the block.space leaderboard ranks. ## The holders appendix For every protocol the books measure, it answers who holds each token, how many units, and therefore how many of the token's bytes back each address. It is a daemon beside BTI's tiers: one service, one [cursor](https://blockspace.wiki/glossary/cursor/), one database schema, seeded once from every source and then advanced block by block. The pages read it; it never reads them. Its rules include: - **The engine is not changed.** The appendix reads BTI's tables and never writes them. - **Built once, advanced by deltas.** The first pass seeds from every source; each later pass applies what changed. This follows the ruleset's standing law (2026-10-18) that every BTI index is built once and keeps its state; a whole rebuild has two causes only, a ruleset change or recovery after a failed check. - **A pass is one transaction.** Readers never see a half-written table, and a failed check rolls the pass back while the last good state keeps serving. - **Scripts, not people.** Owners are keyed by scriptPubKey; the address string is a rendering of it. Burn addresses are holders. - **ord is definitional** for where sats land. Each pass compares 100 random sat landings with ord's own answer, and a disagreement fails the pass. The appendix is temporary by construction. The permanent design, BTI's custody draft (0.3, 2026-10-17), makes ownership a T2 fact, "units of token X moved to owner Y in transaction Z", written by each roster unit beside its claims, with per-address books as T3 arithmetic. Nothing of it is built; it is meant to land at the next full resync, when the appendix schema is dropped. ## Share of backing The rule of shares: ``` share(X, T) = units(X, T) / units_total(T) ``` where `units_total` is the holder total the source reports, never the protocol's stated supply. Each of the token's book components, content, structure and overhead, in bytes and vbytes, is multiplied by the share and summed over the tokens an address holds. So [Book C](https://blockspace.wiki/glossary/book-c/) is content, [Book B](https://blockspace.wiki/glossary/book-b/) adds structure and [Book A](https://blockspace.wiki/glossary/book-a/) adds overhead, and C ≤ B ≤ A holds per address too. This is the address's [share of backing](https://blockspace.wiki/glossary/share-of-backing/). The rankings documentation states the consequences plainly. An address holding half of a token's units is backed by half of that token's bytes. A non-fungible unit, such as an inscribed sat, has one unit, so its owner carries all of the token's bytes. The share is by units held, not by value. Every pass ends with checks that must hold before it commits, among them: the shares of each token sum to 1, and the bytes on addresses plus the bytes nobody holds equal the books, per protocol. ## What it can and cannot see The appendix reads each protocol's holders from its own source: ord's index export plus a block-by-block replay for sats, BTI's adapter state for runes and other UTXO-bound tokens, OPI for BRC-20, Counterparty's state for its assets, and so on. A token whose holders it cannot see contributes nothing to any address, and the rankings rule is that it is "not measured", never 0. The leaderboard's coverage line states what share of the books that leaves out. As of 2026-10-18, Omni, alkanes and three OP_RETURN script ledgers (brc20-opreturn, op20, brc100) were not measured. Alkanes holders were approved for measurement on 2026-10-19, and the leaderboard's coverage API on 2026-10-20 (pass finished 09:20 UTC, books at block 972,199) listed alkanes among the measured protocols. It gave Omni properties, BRC-100 and OP-20 as not measured, and placed 94.6 % of Book A on addresses. ## The leaderboard population The first seed landed on 2026-10-19 at 00:08 and recorded 125,438,419 sats and 4,460,161 addresses. On the latest reading the leaderboard ranked a population of 4,491,923 addresses, with holdings as of block 972,199 (as of block 972,199, 2026-10-20 09:22:01 UTC). The leaderboard ranks one row per address across every protocol the appendix can read, with a composition bar showing how its backing divides among the families. Following the rankings rules, the board says "as of block H", where H is the one block the appendix is synchronised to, and its API carries the exact, unrounded values. See [the frontier](/concepts/the-frontier/). ## Sats decide the top The leaderboard was held back until sats were in, because they decide the top of the table: "a leaderboard without sats ranks wrongly". Sats are the largest family by Book A, and each inscribed sat's bytes go whole to the one address that holds it. See [sats and ordinals](/concepts/sats-and-ordinals/). Sources: - Blockspace Holdings records - block.space docs: rankings · https://block.space/docs/rankings - block.space leaderboard API · https://block.space/api/leaderboard Live figures: holders as of block 972,199, 2026-10-20 09:22:01 UTC Updated: 2026-10-20 --- # Inscriptions Files bound to sats by ord: the witness envelope that carries them, the commit and reveal, recursion and delegation, cursed inscriptions, and how BTI books their bytes. URL: https://blockspace.wiki/concepts/inscriptions/ An [inscription](https://blockspace.wiki/glossary/inscription/) is a file bound to a sat. Blockspace Value Theory's protocol roster dates ordinals inscriptions to January 2023 and describes them as arbitrary files bound to individual sats, carried in a Taproot witness envelope. This page covers how the bytes are carried, how [BTI](https://blockspace.wiki/glossary/bti/) books them, and the variants BTI's documents cover: recursion, delegation and cursed inscriptions. ## Content, not a token Under BTI's law an inscription is content, and the sat it is bound to is the token (ruleset B14). The chain runs label → content → token, and only the token claims. So an inscription's bytes appear in the books of its sat: its file is the sat's [Book C](https://blockspace.wiki/glossary/book-c/), and the transaction that revealed it is the sat's [Book B](https://blockspace.wiki/glossary/book-b/) and [Book A](https://blockspace.wiki/glossary/book-a/). See [sats and ordinals](/concepts/sats-and-ordinals/). ord reported 128,169,401 inscriptions (as of block 972,304, 2026-10-20 10:17:29 UTC). ## The envelope The data-types reference describes how the file is carried. An inscription sits in an [envelope](https://blockspace.wiki/glossary/envelope/) inside a taproot script-path spend: the leaf script holds `OP_FALSE OP_IF … OP_ENDIF` with the content in between, and the ord envelope's marker is `6f7264`. Three consensus facts shape it: - each data push is capped at 520 bytes, which is why envelopes chunk their content into pushes of at most 520 bytes; - tapscript leaf scripts have no script-size limit, so one leaf can hold megabytes of pushes, bounded only by transaction and block weight; - witness bytes weigh 1 WU each, a quarter of base bytes. See [the witness discount](/concepts/witness-discount/). The reference adds that standard relay's 80-byte stack-item caps do not touch inscriptions, because the data lives in the leaf script, not in stack items. It also notes that a reveal transaction has base bytes of its own, and that "the commit tx is a second, unmarked cost". ## Commit and reveal A tapscript can only be revealed by spending an output whose taproot tweak commits to it. So an inscription takes two transactions: a commit and a reveal. BTI records the commit as an [enabler](https://blockspace.wiki/glossary/enabler/) of the reveal; the commit claims nothing itself, but its bytes join the reveal's pool and surface in Book A only. Case 7 of the BTI case studies (2026-08-10) is a 3,888,767-byte jpeg, inscription #127,057,930, revealed at block 960,962: | | bytes | |---|---| | the file (Book C) | 3,888,767 | | the whole reveal (Book B) | 3,911,459 | | reveal plus its 419-byte commit, mined 56,161 blocks earlier (Book A) | 3,911,878 | Of the reveal's structure, 22,457 bytes are envelope framing, about 7,500 push prefixes at 520-byte chunks. ord's content length for the inscription equals the envelope's body exactly, so BTI's extractor and the definitional source agree on the file. ## Inscriptions that carry tokens Some protocols write their operations as inscriptions. A BRC-20 mint is an inscription whose body is a small JSON text. Case 10, the first BRC-20 mint, has two claimants on one reveal: the sat (op `inscribe`) and the tick `ordi` (op `mint`). The tick shares only the envelope it was written in; the 71-byte JSON body is the sat's content, so the tick's Book C is 0. BRC-100 works the same way: its token table entry says the tick's Book C is 0 because the JSON body is the sat's content. ## Recursion BVT's roster lists recursive inscriptions, from 2023, as carried in the witness "by reference", and notes that they reduce per-item consumption. BVT's §3.6 adds that recursive inscriptions and better encoding lower per-item consumption while raising "the prestige of efficiency". Blockspace Labs' research project on permanent bytes includes a part called "Reuse, not repeat": how many bytes recursion (`/content/`, `/r/`) and delegation save. ## Delegation A [delegate inscription](https://blockspace.wiki/glossary/delegate-inscription/) displays another inscription's content. The block.space rankings documentation says such an inscription "bought a few hundred bytes and is that size": the largest-inscriptions board ranks bytes bought, not bytes shown. The holders appendix's inscription labels table carries a `delegate` column for this. ## Cursed inscriptions ord counts [cursed inscriptions](https://blockspace.wiki/glossary/cursed-inscription/) apart from blessed ones. Its latest reading: 472,043 cursed and 127,697,358 blessed (as of block 972,304, 2026-10-20 10:17:29 UTC). A cursed inscription has a negative number; a BTI finding of 2026-10-19 cites #−10,508, at block 791,263. That finding is open. Of the 100,000 largest inscriptions by body size, 582 had no sat binding in BTI's table, the first of them cursed, far below the ord export's ceiling. The finding gives two possible causes: an export that omits cursed inscriptions, or a mismatch in how the envelope's index is derived. Neither is confirmed as of 2026-10-19. Until it is answered, block.space shows those rows as "not yet attributed", with bytes, block and fee, never 0 and never dropped. blockspacelabs.com lists cursed inscriptions as a research study: which rules cursed each inscription, by height, and how the books bind them to sats. Blockspace Holdings' documents do not list the rules themselves. ## The largest The block.space board of largest inscriptions ranks by Book C, the file's own bytes with all framing removed: "the largest file ever committed to a Bitcoin block". The Ordinal Sats family holds 33.44 GB in Book C (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - block.space docs: data types · https://block.space/docs/datatypes - Blockspace Holdings records - block.space docs: rankings · https://block.space/docs/rankings - Blockspace Value Theory · https://block.space/docs/bvt - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - ord /status (the blockspace.to ord server) · https://blockspace.to/status - block.space protocols API · https://block.space/api/protocols Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC; protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Relay policy What a node will relay, as opposed to what is valid: the fee floor and sub-1 sat/vB relay, the standard size, data-carrier limits and full-RBF, from Blockspace Holdings' own node. URL: https://blockspace.wiki/concepts/relay-policy/ Bitcoin has two kinds of rules. Consensus rules decide what is valid in a block. Relay policy decides what a node will pass on to its peers and keep in its mempool before a block is found. block.space's data-types reference puts the difference as "what relays, not what's valid". This page describes the policy settings of [Blockspace Holdings' own Bitcoin node](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/), from its live readings and blockspacelabs.com, and what Blockspace Holdings' documents say about each. ## Blockspace Holdings' node The live reading of the node's policy (as of block 972,304, 2026-10-20 10:17:29 UTC): | setting | value | |---|---| | node version | /Satoshi:28.2.0/ | | minrelaytxfee (the fee floor) | 0 sat/vB | | incrementalrelayfee | 1 sat/vB | | full-RBF | on | | maxmempool | 300 MB | As of 2026-10-20 it is stock Bitcoin Core 28.2.0 with `minrelaytxfee=0`. ## The fee floor and sub-1 sat/vB relay The [fee floor](https://blockspace.wiki/glossary/fee-floor/) is the lowest [fee rate](https://blockspace.wiki/glossary/fee-rate/) a node will relay. The blockspacelabs.com site describes 1 sat/vB as "the default floor of Bitcoin Core". Blockspace Holdings' node runs with the floor at 0, so it relays and keeps transactions paying less than 1 sat/vB. It held 45,999 transactions, 25.2 MB, at a 0 floor when measured on 2026-10-20. blockspacelabs.com lists this as a **Live** project, "Sub-1 sat/vB relay", with the node's mempool figures. Its page, as of 2026-10-20 09:07:08 UTC at block 972,298, showed 38,991 transactions in the mempool (23.7 vMB), of which 38,265 paid below 1 sat/vB. The site counts a transaction as sub-1 when its base fee in sats is less than its vsize. Its research card "The sub-1 sat/vB share" gave the share as 98.1 % of transactions at that reading, and proposes a series hour by hour. The documents record that low rates were not only a relay matter. Blockspace Value Theory's reference data notes "sustained periods at 0.13–0.14 sat/vB, with AntPool accepting sub-1 sat/vB inscriptions" in early to mid 2026. ## Standard transaction size A [standard transaction](https://blockspace.wiki/glossary/standard-transaction/) may weigh at most 400,000 [WU](https://blockspace.wiki/glossary/weight-unit/), about 100,000 vB. The data-types reference calls this `MAX_STANDARD_TX_WEIGHT` and says a bigger transaction, such as the 3.94 MB Taproot Wizards block it cites, needs direct-to-miner submission. The reference gives the practical ceiling for witness payload in one standard transaction as about 397 kB. 4 MB relay is **not configured**: stock Core 28 treats a transaction over 400,000 WU as non-standard and will not relay it, and relaying 4 MB transactions needs a patched node. It is "just a research project", and blockspacelabs.com lists it as **Research**: "No node here relays 4 MB transactions today." The data-types reference lists other policy limits, among them: - P2WSH: at most 100 stack items, 80 bytes per item, and a witnessScript of at most 3,600 bytes; - tapscript: at most 80 bytes per initial stack item; - the taproot annex: still non-standard in Bitcoin Core. It notes that the 80-byte item caps do not constrain inscriptions, because envelope data lives inside the leaf script as pushes of up to 520 bytes (a consensus limit), not in stack items. "That asymmetry is exactly why the envelope pattern won." ## Data-carrier limits Consensus has never limited OP_RETURN size or count; the size story is entirely relay policy. The data-types reference gives the history: the long-lived default `-datacarriersize=83`, one nulldata output per transaction, and then Bitcoin Core 30.0 (October 2025) raising the default to 100,000 bytes and allowing several OP_RETURN outputs. Blockspace Holdings' node runs Core 28.2, and blockspacelabs.com gives its OP_RETURN limit as 83 bytes, the Core 28 default. The reference also records the 2025 dispute between Core and Knots over these limits, and Knots' smaller default. ## Full-RBF The node runs with [full-RBF](https://blockspace.wiki/glossary/full-rbf/) on. blockspacelabs.com's research card "Full-RBF in practice" proposes to count the replacements its mempool sees with full-RBF on, and which of them reach blocks. Blockspace Holdings' documents say no more than that about it. ## The research around it blockspacelabs.com's "Blockspace expansion policy" card describes a study of the levers that change how much blockspace is usable and who can reach it. On the relay side: the fee floor, the standard transaction size, data-carrier limits and full-RBF. On the consensus side: the block weight limit (4,000,000 WU) and the [witness discount](/concepts/witness-discount/). It is written descriptively, "as research rather than advocacy", stating no position the owner has not given. Two related cards, "Policy observatory" and "Low-fee propagation", propose to count mined transactions that standard relay would refuse and to follow which sub-1 sat/vB transactions get mined. They are described studies, with no results yet. Sources: - Blockspace Holdings records - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - block.space docs: data types · https://block.space/docs/datatypes - Blockspace Value Theory · https://block.space/docs/bvt Live figures: relay as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # Sats and ordinals Every sat is separately ownable and numbered by ord. How BTI treats the sat as a token, why rarity is not one, and the Ordinal Sats family on block.space. URL: https://blockspace.wiki/concepts/sats-and-ordinals/ [BTI](https://blockspace.wiki/glossary/bti/)'s token table calls the sat "the base token": every sat is separately ownable and moves with the output that holds it. This page covers how sats are identified, how BTI treats them as tokens, and what block.space shows of them under the family name [Ordinal Sats](https://blockspace.wiki/glossary/ordinal-sats/). ## Numbering: ord Sat identity is ord's numbering. [ord](https://blockspace.wiki/glossary/ord/) gives each sat an [ordinal number](https://blockspace.wiki/glossary/ordinal-number/), and BTI uses that number as the sat token's identity, its `canonical_ref` (ruleset B11). The token table marks ord's numbering as **definitional** (rule B14): ord's ruleset is the protocol here, so adopting its verdict is not a matter of trust. Blockspace Holdings' own ord server, which also serves blockspace.to, is BTI's source for the binding of inscriptions to sats, for sat numbers and for inscription numbers. An example from the BTI case studies: the 3.9 MB jpeg inscription of case 7 sits on sat 1,212,723,567,637,705. ## The sat as a token Ruleset v1's transferability rule says a token is exactly what can be transferred by itself, proven on chain. A sat passes. Several things associated with sats do not, and are labels on a sat instead: - an **inscription** is content bound to a sat; the sat is the token (B14). See [inscriptions](/concepts/inscriptions/); - **bitmap districts** and **sat names** are labels on inscribed sats; - a **CAT-21** cat is a label; the token is the sat, the first sat of output 0 of an `nLockTime=21` mint; - **rarity** is a property of a sat, not another token. The token table records the owner's ruling (2026-08-02) on this, and the ruleset adds (Q-B18d) that an uncommon sat's backing begins at separation: "the separation is the purchase". A sat claims bytes where a deliberate region exists for it (B11), as when an inscription is revealed onto it. When an inscribed sat is merely sent on, that is a [sighting](https://blockspace.wiki/glossary/sighting/): ord records the location change, the byte-diff is zero and the judgment is carriage (ruleset U5, which retired the older rule B15). ## The positional appendix Not every sat is catalogued. The token table lists the whole category of ordinal sats under a "positional appendix", deferred, with births to arrive with it. The design document gives the scale: the positional claim class, every output's bottom sat, would be about 3.6 billion rows, and nothing builds it yet. What BTI does catalogue are the sats something deliberate happened to: inscribed sats, through the ord adapter, and CAT-21 sats. ## Ordinal Sats on block.space On block.space the sat family's display name is Ordinal Sats; its key stays `sat` in every URL, API field and database row. It was renamed from "Individual Sats" on 2026-10-19. Its sub-items are Ordinal Inscriptions, bitmap, sat names and CAT-21. The family's live figures (as of block 972,299, 2026-10-20 09:30:48 UTC): - tokens: 125,519,930 - Book A: 56.13 GB, which is 41.97 % of all Book A and 7.22 % of the chain bytes in range - Book C: 33.44 GB - operations: 129,015,098 - first claim at block 767,430 ## Where sats are To say who holds a sat, the holders appendix tracks each catalogued sat's location. It loads the sat positions from an ord index export and then replays each new block, landing sats by ord's assignment rule from the input values, with fee sats going to the coinbase. It requires 100 random landings per pass to match ord's own answer, and treats a disagreement as the appendix's bug. The first seed, on 2026-10-19, placed 125,438,419 sats. See [holders](/concepts/holders/). ## Lost sats ord also counts [lost sats](https://blockspace.wiki/glossary/lost-sats/): sats that coinbase transactions never claimed, so they exist in no output. ord reported 2,895,844,904 lost sats (as of block 972,304, 2026-10-20 10:17:29 UTC). blockspacelabs.com lists them as a research study: where and when they were lost. Sources: - Blockspace Holdings records - block.space protocols API · https://block.space/api/protocols - ord /status (the blockspace.to ord server) · https://blockspace.to/status - The blockspacelabs.com page (index.html) · https://blockspacelabs.com Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC; protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Spent sats (blockspace.to) blockspace.to is an ord explorer and indexer that also keeps the sat ranges of spent outputs. What that adds, what uses it, and the live state of its index. URL: https://blockspace.wiki/concepts/spent-sats/ blockspace.to's line on the project list is the owner's: "Tracks spent sats. A Blockspace Labs product." blockspacelabs.com describes it as "an ord explorer and indexer that also tracks which sats have been spent", running a fork of [ord](https://blockspace.wiki/glossary/ord/) with `--index-spent-sats`. The project list marks it live since 2026-10-20 08:32 UTC, when the owner moved its nameservers. This page covers what [spent sats](https://blockspace.wiki/glossary/spent-sats/) are in Blockspace Holdings' documents, what uses them, and the live state of the index. ## What the fork keeps A BTI record of 2026-08-16 gives the test: on Blockspace Holdings' ord server, asking ord's `/output/:` for a spent outpoint returned `spent: True` with `sat_ranges` populated, "that only works with `--index-spent-sats`". The ranges are kept on a 16 TB hard disk; on 2026-08-16 the file was 6.6 TB and append-only. As of 2026-10-20 the service is "ord server + indexer (spent-sats fork)", on mainnet. ## What uses it The same ord server is a source for [BTI](https://blockspace.wiki/glossary/bti/). The indexers table lists the spent-sats ord fork as the source the ord adapter adapts, with **definitional** trust. It supplies the binding of inscriptions to sats, sat numbering and inscription numbers, and serves as the audit oracle for BTI's runes decoder and for CAT-21's claimant lookups. See [claims](/concepts/claims-t2/). The same record names what needs the spent ranges in particular: - **CAT-21 needs it, unavoidably.** A CAT-21 token is a sat (the first sat of output 0 of the mint), and the cat21 module makes one ord sat lookup per mint, 63,749 mints in all. - **Inscriptions do not need it in normal operation.** BTI's inscriptions module reaches the spent ranges only through its verification probe, which resolves a sample of inscriptions two ways, ord's binding against its own offset arithmetic, and reports how many agree. Its conclusion: an ord without `--index-spent-sats` can serve inscription-to-sat binding, but cannot serve CAT-21 and cannot run the verification probe. ## Live state ord's own status page (as of block 972,304, 2026-10-20 10:17:29 UTC): | | | |---|---| | inscriptions | 128,169,401 | | blessed | 127,697,358 | | cursed | 472,043 | | runes | 216,409 | | lost sats | 2,895,844,904 | ## Research on it blockspacelabs.com lists two research studies that would use the spent-sats data. Both are described studies, with no results published: - **Inscription permanence**: how often inscribed sats are spent or move, and where they go, from blockspace.to's spent sats and the holders appendix's record of sat moves. - **Lost sats**: the [lost sats](https://blockspace.wiki/glossary/lost-sats/) that coinbase transactions never claimed, so they exist in no output; where and when they were lost. ## Related How BTI and the holders appendix follow sats is on [sats and ordinals](/concepts/sats-and-ordinals/) and [holders](/concepts/holders/). The inscriptions the explorer shows are covered in [inscriptions](/concepts/inscriptions/). Sources: - Blockspace Holdings records - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - The project list at block.space/projects · https://block.space/projects - ord /status (the blockspace.to ord server) · https://blockspace.to/status Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # The frontier and "as of block H" How far each stage of BTI and its appendix has got, why the cursors are ordered books ≤ claims ≤ census, and why every block.space figure carries its height. URL: https://blockspace.wiki/concepts/the-frontier/ Every figure [BTI](https://blockspace.wiki/glossary/bti/) publishes is true up to some block. [The frontier](https://blockspace.wiki/glossary/the-frontier/) is the name for that block. Ruleset v1 gives its core meaning: the frontier is the height every registered protocol has been searched to. On block.space the rule for readers is plain: a board says [as of block H](https://blockspace.wiki/glossary/as-of-block-h/), and a number without its height is not shown. ## Three cursors BTI's design runs three stages, and each keeps its own [cursor](https://blockspace.wiki/glossary/cursor/), a saved height recording how far that stage has completed: | cursor | stage | what it means | |---|---|---| | census | T1, observation | every block up to here has been counted, byte by byte | | claims | T2, catalogue | every registered protocol has been searched up to here | | books | T3, accounting | the books are written up to here | The standing invariant is **books ≤ claims ≤ census**. Each stage reads only the tier beneath it, so no stage can pass the one below. When the engine follows the chain in steady state, the three advance together and are equal at every commit. When they differ, the books are only as current as the books cursor. On the latest reading (as of block 972,301, 2026-10-20 09:35:17 UTC): - census: block 972,302 - claims: block 972,301 - books: block 972,299 - chain tip, from bitcoind: block 972,304 Inside T2 each unit keeps its own cursor too, `claims:`, and the claims cursor can move only past windows every unit has covered and that have been reconciled. ## What moves a cursor, and what stops it - **Only completed windows count.** An increment commits in one database transaction. An interrupted window is abandoned whole, and rerunning resumes from the cursor, so the frontier only ever states completed windows. - **The clamp.** No increment may pass the indexed height of any source it depends on: `hi = min(hi, sources, caps)`, checked on every increment. A lagging indexer holds the claims cursor back, and the lag shows in the stage's status. - **Fail closed.** An unreachable source is a refusal, never a zero. The frontier's meaning, "every registered protocol searched to at least here", cannot be asserted about a protocol whose source could not be asked. - **Perpetual search.** The ruleset's standing law B35 says a dormant protocol is still searched at every height, forever. A protocol with no recent activity still has to be searched for the frontier to pass. - **Reorgs.** Facts and state above the fork height are deleted and the increments are rerun. That is cheap because increments are small, and correct because facts below the fork are append-only. ## "As of block H" The block.space rankings documentation sets the rule: every figure is bounded by a height. A board says "as of block H", where H is the one block the holders appendix is synchronised to. Where a ranking was folded at a different height, or the books are written to another, the detail line names those heights too. The appendix has its own cursor. It is one row, H, "the block to which every source is reconciled", the lowest of the per-source heights, the books included. The pages print "as of block H" from that row only. The holders data stood at block 972,199 (as of block 972,199, 2026-10-20 09:22:01 UTC). ## Several heights at once Because each stage and each source has its own cursor, one page can honestly carry several heights. The census is usually nearest the tip, the books follow behind, and the appendix waits for the books. That is why the wiki's live figures each carry their own "as of": a census figure and a books figure read at the same moment can be bounded by different blocks. The rankings rules add a related one: "Not measured" is never 0. A book the instrument has not measured for a protocol, or a holder the appendix cannot see, is written in words. A zero means a measured zero. See [not measured](https://blockspace.wiki/glossary/not-measured/). Sources: - Blockspace Holdings records - block.space docs: rankings · https://block.space/docs/rankings - block.space meter and summary APIs · https://block.space/api/summary - block.space leaderboard API · https://block.space/api/leaderboard Live figures: 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 Updated: 2026-10-20 --- # The three books Book A (inclusive), Book B (regional) and Book C (content): three answers to how many bytes back a token, with C ≤ B ≤ A on every entry. URL: https://blockspace.wiki/concepts/the-three-books/ [BTI](https://blockspace.wiki/glossary/bti/) gives three answers to the question "how many bytes back this token?", from the widest to the narrowest. They are [Book A](https://blockspace.wiki/glossary/book-a/), the inclusive book; [Book B](https://blockspace.wiki/glossary/book-b/), the regional book; and [Book C](https://blockspace.wiki/glossary/book-c/), the content book. The site documentation says 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, which is why there are three books. ## The three books - **Book A, inclusive.** The whole transactions bought for the token, shared where shared. When several tokens share a transaction, its bytes divide among them under the Shared Claim Axiom. Book A is the backing measure. - **Book B, regional.** The measured regions the token's operations wrote, read or moved through: the transaction's relevant structure and nothing else. - **Book C, content.** The artifact bytes alone: the body of the file or message, with all framing removed. Every entry is kept in both bytes and [vbytes](https://blockspace.wiki/glossary/vbytes/), and fees follow the bytes: a token's share of a transaction's fee follows its share of the transaction's bytes. ## How they are stored: the partition Each [book entry](https://blockspace.wiki/glossary/book-entry/), one row per transaction and token, stores [three disjoint components](https://blockspace.wiki/glossary/the-partition/): | component | meaning | |---|---| | content | the artifact body, the actual file or text | | structure | the rest of the bytes that exist because of the token: carrier framing, protocol outputs, funding inputs | | overhead | the token's share of the rest of a transaction that existed for it, enablers included; zero for riders | The books are running sums over them: ``` Book C = content Book B = content + structure Book A = content + structure + overhead ``` Because each book adds a non-negative component to the one before, C ≤ B ≤ A holds by construction. The books document notes some consequences. A rider shows itself, because its overhead is 0 and so A = B. Fees follow Book A, one fee share per row. Overhead is always published next to structure, because the two are columns of one row. ## Live totals Across all protocols BTI measures, the books hold (as of block 972,299, 2026-10-20 09:30:48 UTC): | book | bytes | share of the chain range | |---|---|---| | Book A | 133.75 GB | 17.21 % | | Book B | 126.98 GB | 16.34 % | | Book C | 36.38 GB | 4.68 % | The share is of the 777.04 GB of chain bytes in the attributed range. ## Worked examples **Bitcoin Stamp #0** (from the BTI case studies, 2026-08-10). A 534-byte transaction that existed for the stamp, with the stamp as its only claimant: content 116, structure 418, overhead 0. So C = 116, B = 534 and A = 534. Overhead appears only when an enabler's bytes join the pool or co-claimants leave a remainder to share. **A 3.9 MB jpeg inscription** (case 7). The reveal transaction is 3,911,459 bytes and its body is 3,888,767 bytes. The commit transaction that enabled it, 419 bytes mined 56,161 blocks earlier, joins the pool. So C = 3,888,767, B = 3,911,459 and A = 3,911,878. The commit's bytes reach Book A only. **The first BRC-20 mint** (case 10). One 338-byte reveal is claimed by two tokens, the sat and the tick `ordi`. The tick shares only the envelope it was written in, so it takes 53.5 bytes in Book B. The sat takes 284.5. Book C belongs to the sat alone (71 bytes, the mint JSON), because the inscription is the sat's content. **A pure-ledger transfer** (an Omni or Counterparty send). Content is 0, honestly, and structure and overhead carry the backing: a ledger token's bytes are its operations. ## Which book a board uses The block.space rankings each read one book by default. The largest inscriptions are ranked by Book C, the file's own bytes. The heaviest tokens are ranked by Book A, and their toggles switch to Book B and Book C. The leaderboard divides each token's bytes under the chosen book among its holders. ## Why three The measurements document gives EPOBC as the case the design exists for. Its colour lives entirely in a field every transaction already has, so its Book B is essentially nothing while its Book A is whole transactions. "The two books give opposite answers, and both are correct." The ratio between them is the [free-ride index](/concepts/carriage-and-the-free-ride-index/). Sources: - Blockspace Holdings records - block.space docs: BTI · https://block.space/docs/bti - block.space docs: rankings · https://block.space/docs/rankings - block.space docs: measurements · https://block.space/docs/measurements - block.space meter and summary APIs · https://block.space/api/summary Live figures: books as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Weight units and vbytes Three ways to size a Bitcoin transaction (raw bytes, weight units and vbytes), the exact formulas, and why BTI's books count raw bytes. URL: https://blockspace.wiki/concepts/weight-units-and-vbytes/ A Bitcoin transaction has three sizes. Its [raw bytes](https://blockspace.wiki/glossary/raw-bytes/) are its full serialized length. Its weight, in [weight units](https://blockspace.wiki/glossary/weight-unit/) (WU), is what the block limit counts. Its virtual size, in [vbytes](https://blockspace.wiki/glossary/vbytes/) (vB), is what fee markets price. This page gives the formulas from block.space's data-types reference and says which one [BTI](https://blockspace.wiki/glossary/bti/) uses where. ## The formulas The data-types reference (citing BIP 141) gives: ``` stripped_size = serialized size without marker/flag/witness (bytes) total_size = full serialized size (bytes) ← BTI's "raw bytes" weight = stripped_size * 3 + total_size (WU) vsize = ceil(weight / 4) (vbytes) ``` Put another way, every non-witness byte costs 4 WU and every byte on the [witness](https://blockspace.wiki/glossary/witness/) side, including the marker, flag and every length prefix, costs 1 WU. A legacy transaction with no witness has `weight = 4 × size` exactly, so its vsize equals its size. The reference also gives two exact inversions, used to recover the witness share of a transaction from the figures bitcoind reports: ``` stripped_size = (weight − total_size) / 3 witness_bytes = total_size − stripped_size = (4·total_size − weight) / 3 ``` ## The block limit The consensus block limit is 4,000,000 WU. Blockspace Value Theory (§3.1) works through what that allows: a block made almost entirely of witness data approaches 4 MB, while the vbyte capacity of a block is 1,000,000 vB (BVT's worked example in §3.6). BVT calls 4 MB × 144 blocks a day × 365 days ≈ 210 GB a year a ceiling, "not a schedule": the most that could be consumed if every block were filled to the weight limit with maximally discounted data, which has never been sustained. BVT also notes the limit is a social variable: the 4M weight limit is where the community currently believes the decentralization constraint binds, "revisable in either direction". ## Two worked transactions From the BTI case studies (2026-08-10), with the case studies' own check that `base × 3 + size = weight`: | transaction | size (bytes) | weight (WU) | vsize (vB) | |---|---|---|---| | the first BRC-20 mint, block 779,833 | 338 | 620 | 155 | | a 3.9 MB jpeg inscription reveal, block 960,962 | 3,911,459 | 3,911,741 | 977,936 | The jpeg reveal is almost entirely witness: its file is "nearly a full block", in the case study's words. The case study puts its bytes-to-vbytes ratio, commit included, at about 4.00. ## Which one BTI counts BTI's design states the rule: **raw bytes are the measure; vbytes are an observable**. The books apply no weight discounting to backing. But the design keeps both measures on every row, because the ratio of bytes to vbytes is the [witness discount](/concepts/witness-discount/), and that is worth measuring in its own right. The data-types reference opens with the same rule: "raw serialized bytes, no weight discounting". So block.space's boards offer a bytes and a vbytes toggle, and the books carry both. The chain totals the census reports, on the latest reading: - raw bytes: 777.04 GB - vbytes: 567.70 GB (as of block 972,302, 2026-10-20 10:16:21 UTC.) ## Fees are priced in vbytes Fee markets price vbytes. At a [fee rate](/concepts/fee-rate/) of f sat/vB, the data-types reference says, a witness byte costs f/4 sats and a non-witness byte costs f sats. That one fact explains much of how data is carried on Bitcoin. Large payloads overwhelmingly choose witness envelopes. OP_RETURN, whose bytes are all non-witness, costs about four times as much per byte, and the reference says it wins only for small payloads or where single-transaction atomicity matters. ## Size limits beyond the block Standard relay policy adds a limit of its own: a standard transaction may weigh at most 400,000 WU, about 100,000 vB. Bigger transactions are valid but must be sent to a miner directly. See [relay policy](/concepts/relay-policy/). Sources: - block.space docs: data types · https://block.space/docs/datatypes - Blockspace Value Theory · https://block.space/docs/bvt - Blockspace Holdings records - block.space docs: measurements · https://block.space/docs/measurements - block.space meter and summary APIs · https://block.space/api/summary Live figures: census as of block 972,302, 2026-10-20 10:16:21 UTC Updated: 2026-10-20 --- # The witness discount SegWit weighs witness bytes at a quarter of base bytes. What that does to fees, how BTI measures it per protocol, and what Blockspace Value Theory proposes it means. URL: https://blockspace.wiki/concepts/witness-discount/ The [witness discount](https://blockspace.wiki/glossary/witness-discount/) is the rule, introduced with SegWit, that a byte in a transaction's [witness](https://blockspace.wiki/glossary/witness/) counts 1 [weight unit](https://blockspace.wiki/glossary/weight-unit/) while every other byte counts 4. The first half of this page is the mechanism, from block.space's data-types reference, and the measurements [BTI](https://blockspace.wiki/glossary/bti/) has taken of it. The second half is what Blockspace Value Theory proposes it means. That half is theory, and it is labelled as such. ## The mechanism A segwit transaction carries one witness stack per input, after its inputs and outputs. The txid hashes the transaction without the witness and the wtxid hashes everything, which is what makes witness data structurally separable. Weight is `stripped_size × 3 + total_size`, so: - every non-witness byte costs 4 WU; - every witness byte costs 1 WU, whether it is a signature or a file; - the consensus block limit is 4,000,000 WU. The data-types reference sums it up: "witness bytes are real bytes on disk and on the wire, but count 1/4 toward the 4,000,000 WU consensus block limit." Fee markets price [vbytes](https://blockspace.wiki/glossary/vbytes/), so at a [fee rate](/concepts/fee-rate/) of f sat/vB a witness byte costs f/4 sats and a non-witness byte costs f sats. ## What it does to data on Bitcoin The reference's channel comparison follows from the discount: | channel | weight per data byte | sats per data byte at f sat/vB | |---|---|---| | taproot witness envelope | 1 WU | f/4 | | OP_RETURN | 4 WU | f | | bare multisig fake keys | 7.4 WU | 1.84f plus dust | It explains why every high-volume protocol, ordinals, BRC-20, Alkanes WASM and Counterparty v11, converged on the witness envelope, and why OP_RETURN keeps small structured messages such as runestones, where its single-transaction atomicity matters more than the price. ## Measured per protocol Because BTI keeps both raw bytes and vbytes on every row, the ratio of bytes to vbytes is the share of the discount a protocol takes. BTI's design names that ratio the witness subsidy. From the July 2026 measurement run: | protocol | bytes : vbytes | reading | |---|---|---| | inscriptions | 3.374 | pays for about 30 % of what it consumes | | stamps | 1.008 | essentially no discount, deliberately | | runes (runestone) | 1.0000 | zero discount, to four decimals | | Omni | 1.0142 | pre-segwit, as expected | The measurements document reads this as "a 3.37× gap between two protocols using the same chain in the same year": stamps chose to forgo the discount for permanence, and inscriptions took all of it. A single large file shows it most plainly. In case 7 of the BTI case studies, a 3.9 MB jpeg inscription, Book A is 3,911,878 bytes against 978,204.25 vbytes, a ratio the case study puts at about 4.00: "this artifact bought raw bytes at a quarter weight". blockspacelabs.com lists "The witness discount, by protocol" among its research projects: each token family's split of base and witness bytes, and what the discount saved it in fees. It is a described study; no results are published yet. ## What BVT proposes (theory) *This section reports Blockspace Value Theory, a living document and an untested thesis.* BVT §3.4 says version 2.0 of the theory was wrong to treat witness-borne tokens as proportionally less real blockspace. BVT proposes that the binding supply constraint is total verification burden, and that on that measure the channel does not matter: witness and OP_RETURN bytes are both downloaded, validated, propagated and archived by every node. It argues that pruning does not rescue the old view, because a pruned node has still paid the validation cost. From this BVT concludes: > 4 MB of witness data consumes 4 MB of the real kilobyte budget. 1 MB of OP_RETURN data consumes 1 MB. and > The 4× discount does not create four times more blockspace. It sells the same scarce resource at one quarter the price through one particular door. §3.5 calls the discount "a transfer of blockspace value" from the fee market to whoever routes data through the discounted channel, paid for by node operators. BVT's glossary defines the term in one line: "SegWit's 4× weight reduction on witness data. A price subsidy, not a capacity increase." BVT names the open question this leaves: if the market ever prices blockspace tokens by kilobytes consumed rather than by fees paid, witness-era accumulation would be worth four times what its cost basis suggests; if it prices by fees, it is worth what was paid. BVT calls "kilobytes or fees" the central open variable in the theory. See [Blockspace Value Theory](/concepts/blockspace-value-theory/). ## Why BTI counts raw bytes BTI's design follows BVT here as a measurement rule, not as a claim about value. The books count raw bytes with no weight discounting, and vbytes are carried beside them so the discount stays visible on every row. See [weight units and vbytes](/concepts/weight-units-and-vbytes/). Sources: - block.space docs: data types · https://block.space/docs/datatypes - Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: measurements · https://block.space/docs/measurements - Blockspace Holdings records - The blockspacelabs.com page (index.html) · https://blockspacelabs.com Updated: 2026-10-20 --- # bitmap.holdings Bitmap Holdings: "Bitmaps turn each Bitcoin block into digital land—programmable, ownable, eternal." URL: https://blockspace.wiki/projects/bitmap.holdings/ Status: live (a Blockspace Holdings property, hosted elsewhere) Site: https://bitmap.holdings ## What it is bitmap.holdings is the site of Bitmap Holdings. Its own headline is "The New Data Layer of Civilization", and its line: "Bitmaps turn each Bitcoin block into digital land—programmable, ownable, eternal." It says [Bitmaps](https://blockspace.wiki/glossary/bitmap/) turn each Bitcoin block into a coordinate that can be owned and programmed. ## Status Live at https://bitmap.holdings (as of 2026-10-20). It is a Blockspace Holdings property, hosted separately from the other projects. Blockspace Holdings counts it among its holdings (2026-10-20). A planned project list places it in a "companies and collections" group, linked to its own site. ## How it works The site describes plans, not a product. In its words, "We are exploring how to: Use Bitmaps to build applications; Integrate with games and metaverse platforms; Create on-chain identity and digital real estate; Monetize the data layer of Bitcoin." It argues that with Bitmaps "we can use Bitcoin not just for money—but for territory, identity, and culture", and it invites people working in those areas to get in touch. ## Key figures Not measured. This wiki reads no figures for bitmap.holdings. ## Glossary - **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." ## FAQ ### What is a Bitmap? In bitmap.holdings' own words, "Bitmaps turn each Bitcoin block into a piece of digital land." Each block becomes a coordinate, each coordinate becomes ownable, and each ownership becomes programmable. See [Bitmap](https://blockspace.wiki/glossary/bitmap/). ### Is bitmap.holdings part of Blockspace Holdings? Yes. It is one of Blockspace Holdings' properties, hosted separately from the other projects. Blockspace Holdings counts it among its holdings (as of 2026-10-20). ### Is it the bitmap that BTI catalogues? No source links the two. BTI's token catalogue has a "bitmap sats" entry, read by its opi-bitmap adapter, where the inscription is a district claim and the district number is a label on the sat. This wiki makes no claim about what bitmap.holdings holds. ### How do I get in touch? Its site has a contact form and a "Tweet us" link. It asks to hear from people working on Ordinals or Bitmaps, on-chain identity, metaverse or game integrations, or Bitcoin infrastructure. Sources: - bitmap.holdings, its own home page, read 2026-10-20 · https://bitmap.holdings - Blockspace Holdings records Updated: 2026-10-20 --- # block.space The Bitcoin Blockspace Meter: how much of Bitcoin's blockspace is attributed to tokens, token by token, byte by byte. URL: https://blockspace.wiki/projects/block.space/ Status: live Site: https://block.space ## 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](https://blockspace.wiki/glossary/the-meter/) displays the numbers that [BTI](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/the-census/), counts every transaction's bytes, weight and fee. [T2](https://blockspace.wiki/glossary/claims/) records which tokens each transaction touched, under each protocol's own published rules. [T3, the books](https://blockspace.wiki/glossary/the-books/), judges every claimed byte into [Book A](https://blockspace.wiki/glossary/book-a/) (the inclusive book), [Book B](https://blockspace.wiki/glossary/book-b/) (the regional book) and [Book C](https://blockspace.wiki/glossary/book-c/) (the content book), following [the partition](https://blockspace.wiki/glossary/the-partition/). Where several tokens share a transaction, its bytes divide among them under the [Shared Claim Axiom](https://blockspace.wiki/glossary/shared-claim-axiom/). Each block's bytes divide into [claimed](https://blockspace.wiki/glossary/claimed-bytes/), [carriage](https://blockspace.wiki/glossary/carriage/), [burned](https://blockspace.wiki/glossary/burned-bytes/) and [unclaimed](https://blockspace.wiki/glossary/unclaimed-bytes/), which sum to its exact size: this is the site's [conservation](https://blockspace.wiki/glossary/conservation/) rule, its trust anchor. The three heights the layers have reached are [the frontier](https://blockspace.wiki/glossary/the-frontier/). The [rankings](https://blockspace.wiki/glossary/rankings/) read the books and the [holders appendix](https://blockspace.wiki/glossary/the-appendix/). The [largest inscriptions board](https://blockspace.wiki/glossary/largest-inscriptions-board/) ranks inscriptions by Book C. The [heaviest tokens board](https://blockspace.wiki/glossary/heaviest-tokens-board/) ranks tokens by Book A. [the leaderboard](https://blockspace.wiki/glossary/the-leaderboard/) ranks addresses by their [share of backing](https://blockspace.wiki/glossary/share-of-backing/), with a [coverage](https://blockspace.wiki/glossary/coverage/) line for what it cannot place. Every board follows the [as of block H](https://blockspace.wiki/glossary/as-of-block-h/) caption rule, ranks by [backing](https://blockspace.wiki/glossary/backing/) in bytes or [vbytes](https://blockspace.wiki/glossary/vbytes/), and colours families by the [five-colour family key](https://blockspace.wiki/glossary/five-colour-family-key/), in which the sat family is [Ordinal Sats](https://blockspace.wiki/glossary/ordinal-sats/). A collections board was added to the rankings index; on 2026-10-20 it showed nothing ranked yet. [explore.block.space](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/book-a/): 133.75 GB attributed, 17.21 % of the 777.04 GB of blockspace in the written range; - [Book B](https://blockspace.wiki/glossary/book-b/): 126.98 GB; [Book C](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/the-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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counterparty/) asset whose description carries a file, written into output-side carriers: [bare multisig](https://blockspace.wiki/glossary/bare-multisig/) at first, [OLGA](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/transaction/) 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](https://blockspace.wiki/glossary/weight-unit/). The chain is every block from the genesis block forward. - **block subsidy**: The part of a miner's revenue for a [block](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/shared-claim-axiom/). In the [partition](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](/concepts/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](/concepts/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](/concepts/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/carriage/), [burned bytes](https://blockspace.wiki/glossary/burned-bytes/) and [unclaimed bytes](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/claimed-bytes/), [carriage](https://blockspace.wiki/glossary/carriage/), [burned](https://blockspace.wiki/glossary/burned-bytes/) and [unclaimed](https://blockspace.wiki/glossary/unclaimed-bytes/), 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](https://blockspace.wiki/glossary/book-a/) bytes the [leaderboard](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/), 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](https://blockspace.wiki/glossary/book-c/)), tokens by what they bought ([Book A](https://blockspace.wiki/glossary/book-a/)), and addresses by the blockspace behind what they hold. On 2026-10-20 the live index lists four boards: the [leaderboard](https://blockspace.wiki/glossary/the-leaderboard/), the [largest inscriptions](https://blockspace.wiki/glossary/largest-inscriptions-board/), the [heaviest tokens](https://blockspace.wiki/glossary/heaviest-tokens-board/) 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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/book-a/), [Book B](https://blockspace.wiki/glossary/book-b/) and [Book C](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/blockspace/) is attributed to tokens, token by token, byte by byte. [BTI](https://blockspace.wiki/glossary/bti/) counts every byte, catalogues each protocol's operations, and writes three books per token: [Book A](https://blockspace.wiki/glossary/book-a/), [Book B](https://blockspace.wiki/glossary/book-b/) and [Book C](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/not-measured/), never as 0. ### Is the code public? The code of the sibling explorer, [explore.block.space](https://blockspace.wiki/glossary/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: - The project list at block.space/projects · https://block.space/projects - block.space docs: BTI · https://block.space/docs/bti - block.space docs: rankings · https://block.space/docs/rankings - block.space docs: measurements · https://block.space/docs/measurements - Blockspace Holdings records - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space - block.space meter and summary APIs · https://block.space/api/summary - block.space frontier API (the three tier cursors and the chain tip) · https://block.space/api/frontier - block.space leaderboard API · https://block.space/api/leaderboard - block.space protocols API · https://block.space/api/protocols - BLOCKdotSPACE/blockspace-explorer README · https://github.com/BLOCKdotSPACE/blockspace-explorer 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 Updated: 2026-10-20 --- # blockspace.holdings Blockspace Holdings' own page: "We acquire & Hodl Blockspace Assets. We serve public Blockspace Infrastructure." URL: https://blockspace.wiki/projects/blockspace.holdings/ Status: live (since 2026-10-19) Site: https://blockspace.holdings ## What it is blockspace.holdings is the page of [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/). In its own words: "We acquire & Hodl Blockspace Assets. We serve public Blockspace Infrastructure." Its heading reads "The byte unit of value." Beside it sits a 1 kB [Bitbar](https://blockspace.wiki/glossary/bitbar/), "Exactly 1,024 bytes on Bitcoin Mainnet." The tagline, the 1,024-byte bitbar and the "[Hodl](https://blockspace.wiki/glossary/hodl/)" wordplay are fixed parts of the page. Its scope, in Blockspace Holdings' words (2026-10-19): "we will display all these projects as holdings. The most important are block.space, degent.club, scribb.it." It is the corporate hub of the 18 properties. ## Status Live at https://blockspace.holdings since 2026-10-19 (as of 2026-10-20). ## How it works It is one static page with no outside scripts, fonts or trackers, in light and dark. The cards are not kept by hand: they are generated from the same project list block.space/projects shows. The featured three come first, then the live domains A to Z, then the coming-soon ones. A card links only when its domain answers with the project's own site. blockspace.holdings gets no card of its own, and devcash.dev is left off. ## Key figures These come from Blockspace Holdings' records of its assets, not from a live feed. - The Bitbars on Bitcoin are 1,024, 65,536, 131,072 and 262,144 bytes (1, 64, 128 and 256 kB). The three larger ones were checked on ordinals.com at exactly their advertised sizes (2026-08-19). - The Space Blocks image is 1,047,584 bytes, 99.9 % of one 1,048,576-byte block. - [Litebars](https://blockspace.wiki/glossary/litebars/) Genesis has a supply of 650 and LITEBARS 10% a supply of 169,037, as read from Chikun Market's collections API. ## Glossary - **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. - **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 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. - **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. - **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. ## FAQ ### What is blockspace.holdings? The page of [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/), the company behind block.space and the other projects. It shows every project as a holding, with block.space, degent.club and scribb.it featured. ### Why does it say "Hodl"? The spelling is deliberate, and it stays. See [Hodl](https://blockspace.wiki/glossary/hodl/). ### Where do the cards come from? From the same project list that block.space/projects shows. The cards are generated from that list, not kept by hand. Each line comes from the project's own site or its own source. ### Why is devcash.dev not on the page? Blockspace Holdings chose on 2026-10-20 to leave it off blockspace.holdings. It stays on block.space/projects. Sources: - The project list at block.space/projects · https://block.space/projects - The blockspace.holdings page (site/index.html) · https://blockspace.holdings - Blockspace Holdings records Updated: 2026-10-20 --- # blockspace.loans A parked domain of Blockspace Holdings; no concept announced as of 2026-10-20. URL: https://blockspace.wiki/projects/blockspace.loans/ Status: coming soon (parked) ## What it is A domain of Blockspace Holdings with no project yet. The project list gives it no name and no line (as of 2026-10-20). ## Status Coming soon, as of 2026-10-20. The project list marks it "soon". The domain serves a generated "Coming soon" page. ## How it works Nothing is built, as of 2026-10-20. The concept under consideration, not confirmed, is "What blockspace is worth as collateral: today's sats/KB floor per family, from blockspace.markets": an information page only, with no lending service and no offer of credit. Until a concept is confirmed, the domain keeps its landing page. ## FAQ ### Does blockspace.loans offer loans? No. Nothing is built (as of 2026-10-20). The concept under consideration is an information page only, with no lending service and no offer of credit, and it is not confirmed. ### What does the domain show now? A generated "Coming soon" page, written from the domain's row in the project list. Sources: - The project list at block.space/projects · https://block.space/projects - Blockspace Holdings records - The blockspace.loans landing page and README · https://blockspace.loans Updated: 2026-10-20 --- # blockspace.markets Blockspace for sale, priced per kilobyte. URL: https://blockspace.wiki/projects/blockspace.markets/ Status: live (since 2026-10-19) Site: https://blockspace.markets ## What it is blockspace.markets is "blockspace for sale, priced per kilobyte". In its own words, it shows every asset listed for bitcoin on the venues the block.space [buy board](https://blockspace.wiki/glossary/buy-board/) watches, ranked by what a kilobyte of its blockspace costs. ## Status Live, as of 2026-10-20. The project list marks it live from 2026-10-19. ## How it works A static page is rebuilt every 10 minutes from the buy board's public listing data. The wallet and buying flow stay in one place, at block.space/buy. The page shows the cheapest blockspace of each kind (Counterparty and inscriptions), the 50 cheapest listings overall, and each venue's live listings with the time it was last read. A listing's price is the venue's asking price; its blockspace is what block.space's books attribute to the asset under [Book A](https://blockspace.wiki/glossary/book-a/), read at the books height named on the listing. The ranking is in [sats per kB](https://blockspace.wiki/glossary/sats-per-kb/). A listing is an offer, not a sale. ## Key figures The site has no live figure of its own in this wiki. At 09:22 UTC on 20 October 2026 the page ranked 167,648 listings: 143,232 inscriptions and 24,416 Counterparty listings. The cheapest blockspace then was 38 sats per kB for an inscription and 115 sats per kB for a Counterparty asset. ## Links - The site: https://blockspace.markets - To buy: https://block.space/buy ## Glossary - **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](https://blockspace.wiki/glossary/shared-claim-axiom/). In the [partition](https://blockspace.wiki/glossary/the-partition/) it is content + structure + overhead, "bytes bought for you at all", and it is the backing measure. Fees follow Book A. - **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](https://blockspace.wiki/glossary/book-a/)), per kilobyte (1 kB = 1,000 B). A listing is an offer, not a sale. - **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. ## FAQ ### Can I buy on blockspace.markets? No. The page only shows listings. Buying happens at block.space/buy, the one place with the wallet flow, which the page links to. ### How is the price per kilobyte worked out? The venue's asking price, divided by the blockspace block.space's books attribute to the asset under [Book A](https://blockspace.wiki/glossary/book-a/), as the [buy board](https://blockspace.wiki/glossary/buy-board/) computes it. See [sats per kB](https://blockspace.wiki/glossary/sats-per-kb/). ### How fresh is it? The page is rebuilt every 10 minutes and every section says the time it is as of. If the board returns nothing, the last page stays, with its own as-of time. Sources: - The project list at block.space/projects · https://block.space/projects - The blockspace.markets site: README, tools/build.py and the page · https://blockspace.markets - Blockspace Holdings records Updated: 2026-10-20 --- # blockspace.news The day in Bitcoin blockspace, in numbers, from block.space. URL: https://blockspace.wiki/projects/blockspace.news/ Status: live (since 2026-10-19; first edition 2026-10-20) Site: https://blockspace.news ## What it is blockspace.news is "the day in Bitcoin blockspace, in numbers, from block.space": a daily [edition](https://blockspace.wiki/glossary/edition/) of numbers and links. In its own words, every figure is read from block.space's public API, and nothing is estimated. ## Status Live, as of 2026-10-20. The project list marks it live from 2026-10-19. The first edition appeared at 00:15 UTC on 2026-10-20. ## How it works Each day at 00:15 UTC the site saves a snapshot of block.space's public API (https://block.space/api/meter, /api/summary and /api/protocols, and the top 100 of /api/largest-inscriptions and /api/heaviest-tokens). An edition is the difference between that day's snapshot and the one before: - the books height then and now, and the blocks written in between; - the [Book A](https://blockspace.wiki/glossary/book-a/) bytes added per family, largest first; - new entrants to the 100 largest inscriptions on the [largest inscriptions board](https://blockspace.wiki/glossary/largest-inscriptions-board/); - the rank moves in the top 100 of the [heaviest tokens board](https://blockspace.wiki/glossary/heaviest-tokens-board/). Every figure is given [as of block H](https://blockspace.wiki/glossary/as-of-block-h/), the height [the books](https://blockspace.wiki/glossary/the-books/) are written to. Every edition is kept, so the archive holds them all. ## Key figures The site has no live figure of its own in this wiki. The edition of Tuesday 20 October 2026 compared the 00:15 UTC snapshot with one taken at 14:22 UTC on 2026-10-19. It counted 67 blocks (972,164 to 972,230), 115 MB of blockspace and 310,987 transactions. Between the books at block 972,099 and block 972,199 it found runes adding the most Book A bytes, 39.9 MB, 58.4 % of the day's. It found no new entrants among the 100 largest inscriptions and no moves in the top 100 heaviest tokens. ## Links - The site: https://blockspace.news, with the archive at https://blockspace.news/archive/ and the feed at https://blockspace.news/feed.xml - Its data: block.space's public API and its boards (listed above). ## Glossary - **as of block H**: The caption rule every block.space ranking follows. H is the one block the [holders appendix](https://blockspace.wiki/glossary/the-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. - **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](https://blockspace.wiki/glossary/shared-claim-axiom/). In the [partition](https://blockspace.wiki/glossary/the-partition/) it is content + structure + overhead, "bytes bought for you at all", and it is the backing measure. Fees follow Book A. - **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. - **heaviest tokens board**: block.space/heaviest-tokens: the 100,000 heaviest tokens by [Book A](https://blockspace.wiki/glossary/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. - **largest inscriptions board**: block.space/largest-inscriptions: the 100,000 largest inscriptions by content bytes ([Book C](https://blockspace.wiki/glossary/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. - **the books**: T3, BTI's accounting layer, and what it writes: [Book A](https://blockspace.wiki/glossary/book-a/), [Book B](https://blockspace.wiki/glossary/book-b/) and [Book C](https://blockspace.wiki/glossary/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. ## FAQ ### Where do the numbers come from? Every figure is read from block.space's public API and bounded by the height its books are written to. The site says nothing is estimated, and it makes no prose claims beyond the data. ### When does a new edition appear? Once a day. A snapshot is taken at 00:15 UTC, and the [edition](https://blockspace.wiki/glossary/edition/) is the difference between that day's snapshot and the one before. ### What happens if the books are rewound? A rewound or rewritten set of [books](https://blockspace.wiki/glossary/the-books/) is reported as "no comparison", never as a negative. ### Is there a feed? Yes. Each edition has its own page by date, the archive lists them all, and an Atom feed is at /feed.xml. Sources: - The project list at block.space/projects · https://block.space/projects - The blockspace.news site: README, tools/build.py and the editions · https://blockspace.news - Blockspace Holdings records - block.space meter and summary APIs · https://block.space/api/summary - block.space protocols API · https://block.space/api/protocols Updated: 2026-10-20 --- # blockspace.space A parked domain of Blockspace Holdings; no concept announced as of 2026-10-20. URL: https://blockspace.wiki/projects/blockspace.space/ Status: coming soon (parked) ## What it is A domain of Blockspace Holdings with no project yet. The project list gives it no name and no line (as of 2026-10-20). ## Status Coming soon, as of 2026-10-20. The project list marks it "soon". The domain serves a generated "Coming soon" page. ## How it works Nothing is built, as of 2026-10-20. The concept under consideration, not confirmed, is "Where the space in Bitcoin's blocks goes: every byte of the chain by what it carries (frames, outpoints, sequences, amounts, scripts, witness, data), from block.space's T1 census." Until a concept is confirmed, the domain keeps its landing page. ## FAQ ### What will blockspace.space be? Not decided, as of 2026-10-20. The concept under consideration is a view of where the space in Bitcoin's blocks goes. It is not confirmed, and the domain keeps its landing page until then. ### What does the domain show now? A generated "Coming soon" page, written from the domain's row in the project list. Sources: - The project list at block.space/projects · https://block.space/projects - Blockspace Holdings records - The blockspace.space landing page and README · https://blockspace.space Updated: 2026-10-20 --- # blockspace.to "Tracks spent sats. A Blockspace Labs product." URL: https://blockspace.wiki/projects/blockspace.to/ Status: live (since 2026-10-20 08:32 UTC) Site: https://blockspace.to ## What it is blockspace.to "tracks spent sats". It is "a Blockspace Labs product": an [ord](https://blockspace.wiki/glossary/ord/) explorer and indexer that also tracks which sats have been spent (see [spent sats](https://blockspace.wiki/glossary/spent-sats/)). [Blockspace Labs](https://blockspace.wiki/glossary/blockspace-labs/) lists it as a Live product. It indexes [inscriptions](https://blockspace.wiki/glossary/inscription/) and [runes](https://blockspace.wiki/glossary/rune/) on Bitcoin mainnet. ## Status Live at https://blockspace.to since 2026-10-20 08:32 UTC; the page there reads "Ordinals" (as of 2026-10-20). ## How it works blockspace.to runs a fork of ord, "ord server + indexer (spent-sats fork)", with spent-sat indexing switched on. It is part of Blockspace Holdings' own Bitcoin node and indexers. Its public page https://blockspace.to/status reports the indexes it keeps (sats, inscriptions, runes, addresses, transactions) and its counts. block.space's inscription content depends on it. ## Key figures From https://blockspace.to/status, as of block 972,304, 2026-10-20 10:17:29 UTC: - indexed to block 972,304; - [inscriptions](https://blockspace.wiki/glossary/inscription/): 128,169,401 (127,697,358 blessed, 472,043 [cursed](https://blockspace.wiki/glossary/cursed-inscription/)); - [runes](https://blockspace.wiki/glossary/rune/): 216,409; - [lost sats](https://blockspace.wiki/glossary/lost-sats/): 2,895,844,904. ## Glossary - **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. - **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. - **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. - **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. - **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. - **lost sats**: Sats that coinbase transactions never claimed, so they exist in no output. ord's /status counts them. - **ord**: The ordinals indexer and explorer. Its fork, run by [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/), 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. - **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. - **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. - **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. ## FAQ ### What does blockspace.to do? It is an [ord](https://blockspace.wiki/glossary/ord/) explorer and indexer that also tracks which sats have been spent. In its own line: "Tracks spent sats. A Blockspace Labs product." See [spent sats](https://blockspace.wiki/glossary/spent-sats/). ### How many inscriptions does it index? 128,169,401 [inscriptions](https://blockspace.wiki/glossary/inscription/), as of block 972,304, 2026-10-20 10:17:29 UTC: 127,697,358 blessed and 472,043 cursed. ### What are lost sats? Sats that coinbase transactions never claimed, so they exist in no output. ord counts 2,895,844,904 of them (as of block 972,304, 2026-10-20 10:17:29 UTC). See [lost sats](https://blockspace.wiki/glossary/lost-sats/). ### Who runs it? [Blockspace Labs](https://blockspace.wiki/glossary/blockspace-labs/), the research and development arm of [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/). It runs on [Blockspace Holdings' own Bitcoin node and indexers](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/), and block.space's inscription content depends on it. Sources: - The project list at block.space/projects · https://block.space/projects - Blockspace Holdings records - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - ord /status (the blockspace.to ord server) · https://blockspace.to/status - block.space docs: data types · https://block.space/docs/datatypes Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # blockspace.wiki "A place to write all information and documentation about blockspace." URL: https://blockspace.wiki/projects/blockspace.wiki/ Status: live (since 2026-10-20) Site: https://blockspace.wiki ## What it is blockspace.wiki is this site: "everything about Bitcoin blockspace, written down". In Blockspace Holdings' words (2026-10-20), it is "a place to write all information and documentation about [blockspace](https://blockspace.wiki/glossary/blockspace/)". It has a page for each project with its own glossary and FAQ, the concepts (Blockspace Value Theory, [BTI](https://blockspace.wiki/glossary/bti/), the three books and more), the protocols, the basics, how it's measured, the data and APIs, answers, research and a timeline. It is the knowledge hub of [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/), where every project's entries are gathered under one shared glossary. ## Status Live at https://blockspace.wiki since 2026-10-20 (as of 2026-10-20), with its layout, search and machine surfaces. The project pages and their glossaries are being added. ## How it works Every page names its sources from one bibliography. One builder renders the pages, the glossary, the search index and the [machine surfaces](https://blockspace.wiki/glossary/machine-surfaces/) from the same content. The build fails on a page without sources, a dead internal link, an undefined glossary term or a figure it cannot find. Every hour the live figures are read again from Blockspace Holdings' own Bitcoin node and indexers (block.space, ord, the Bitcoin node and the Degent collection list) and the site is rebuilt; a source that fails keeps its last reading and its "as of". Every project page links its site, and every concept links its related terms: the [spiderweb](https://blockspace.wiki/glossary/spiderweb/). ## Glossary - **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 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. - **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. - **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. - **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. ## FAQ ### What is blockspace.wiki? This site. In Blockspace Holdings' words, "a place to write all information and documentation about [blockspace](https://blockspace.wiki/glossary/blockspace/)": a page per project with its glossary and FAQ, the concepts, the protocols, and the data. ### Where do its facts come from? Only from Blockspace Holdings' own documents and the live data of [its own Bitcoin node and indexers](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/). Every page lists its sources, a claim with no source is not written, and every live figure carries its "as of". ### Is the theory presented as fact? No. Blockspace Value Theory is a living document and an untested thesis; BTP and BYTES are drafts describing things that do not exist. Theory pages say so. ### Can agents read it? Yes. It publishes [machine surfaces](https://blockspace.wiki/glossary/machine-surfaces/): a sitemap, robots.txt that welcomes crawlers, llms.txt and llms-full.txt (the whole wiki as Markdown), JSON-LD, an Atom feed and /.well-known/blockspace.json. Sources: - Blockspace Holdings records - The project list at block.space/projects · https://block.space/projects - blockspace.wiki README · https://blockspace.wiki Updated: 2026-10-20 --- # blockspacelabs.com Blockspace Labs: "Research and development for Bitcoin blockspace." URL: https://blockspace.wiki/projects/blockspacelabs.com/ Status: live (since 2026-10-20 08:32 UTC) Site: https://blockspacelabs.com ## What it is [Blockspace Labs](https://blockspace.wiki/glossary/blockspace-labs/) is, in its own words, "research and development for Bitcoin blockspace", a part of [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/). Its card on block.space/projects reads "Research and development (R&D)." Its projects are cards with a status. The Live ones run today on Blockspace Holdings' own Bitcoin node and indexers: the [sub-1 sat/vB relay](https://blockspace.wiki/glossary/sub-1-sat-vb-relay/), blockspace.to and its [spent sats](https://blockspace.wiki/glossary/spent-sats/), the [Blockspace Token Indexer](https://blockspace.wiki/glossary/bti/), the byte census, who holds blockspace, and the blockspace price. The Research ones are descriptive studies: 4 MB transaction relay, blockspace expansion policy, what to store on Bitcoin, the policy observatory, low-fee propagation, the sub-1 sat/vB share, [full-RBF](https://blockspace.wiki/glossary/full-rbf/) in practice, the witness discount by protocol, the envelope taxonomy, inscription permanence, [lost sats](https://blockspace.wiki/glossary/lost-sats/), [cursed inscriptions](https://blockspace.wiki/glossary/cursed-inscription/), testing the BVT, Blockspace Value Theory, fork and reorg watch, and Litecoin and Dogecoin blockspace. Blockspace Value Theory is, in the site's words, "a living document and an untested thesis". ## Status Live at https://blockspacelabs.com since 2026-10-20 08:32 UTC (as of 2026-10-20). The research cards are descriptive "for now": there are no results pages and no tooling behind them yet. ## How it works The site is one static page with no outside assets and no scripts. Its figures come from Blockspace Holdings' own Bitcoin node and indexers: the Bitcoin node (mempool and network info), the ord server behind blockspace.to, block.space's APIs and the buy board. The figures are refreshed every hour. A source that fails keeps its last reading with its own "as of". ## Key figures The node's relay policy, as of block 972,304, 2026-10-20 10:17:29 UTC: - node: /Satoshi:28.2.0/; - [minimum relay fee](https://blockspace.wiki/glossary/fee-floor/): 0 sat/vB; incremental relay fee: 1 sat/vB; - full-RBF: on; maximum mempool: 300 MB. In the Labs reading of 2026-10-20 09:07 UTC, 38,265 of the 38,991 transactions in the node's mempool paid below 1 sat/vB. From ord, as of block 972,304, 2026-10-20 10:17:29 UTC: 2,895,844,904 [lost sats](https://blockspace.wiki/glossary/lost-sats/); 472,043 cursed and 127,697,358 blessed inscriptions. ## Glossary - **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. - **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. - **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. - **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](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/) runs with minrelaytxfee=0. - **full-RBF**: A relay policy setting of a Bitcoin node (fullrbf), about replacing unconfirmed transactions. [Blockspace Holdings' own Bitcoin node](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/) runs with it on; the Labs study "Full-RBF in practice" proposes to count the replacements its mempool sees. - **lost sats**: Sats that coinbase transactions never claimed, so they exist in no output. ord's /status counts them. - **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. - **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. ## FAQ ### What is Blockspace Labs? The research and development arm of [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/), at blockspacelabs.com. Its site lists research projects as cards, each marked Live or Research, with figures measured on [Blockspace Holdings' own Bitcoin node and indexers](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/). ### Does the Labs node really relay transactions below 1 sat/vB? Yes. It runs stock Bitcoin Core with a minimum relay fee of 0 sat/vB (as of block 972,304, 2026-10-20 10:17:29 UTC), so it relays and keeps them. See [sub-1 sat/vB relay](https://blockspace.wiki/glossary/sub-1-sat-vb-relay/). ### Does it relay 4 MB transactions? No. Stock Bitcoin Core treats a transaction over 400,000 weight units (100 kvB) as [non-standard](https://blockspace.wiki/glossary/standard-transaction/), so 4 MB relay needs a patched node. In Blockspace Holdings' words it is "just a research project". ### Are the research projects producing results? Not yet, as of 2026-10-20. In Blockspace Holdings' words, the Labs projects stay "descriptive research projects for now". The cards say what each study is and what data it uses; nothing is built behind them. ### How is blockspace.to related to Labs? blockspace.to is a Blockspace Labs product: an ord explorer and indexer that also tracks [spent sats](https://blockspace.wiki/glossary/spent-sats/). Sources: - The project list at block.space/projects · https://block.space/projects - Blockspace Holdings records - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - ord /status (the blockspace.to ord server) · https://blockspace.to/status Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC; relay as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # counters.fun Counters with XCP liquidity pools. On-chain files only. URL: https://blockspace.wiki/projects/counters.fun/ Status: live Site: https://counters.fun Source: https://github.com/BitcoinCounters/counters.fun ## What it is counters.fun is the market layer for Bitcoin [Counters](https://blockspace.wiki/glossary/counter/). In its own words: "Counters are files in Bitcoin witness data, owned through Counterparty assets. This is where they get markets. Nothing here is hosted: every image is read out of a Bitcoin block." Its card line is "Counters with XCP liquidity pools. On-chain files only." It shows the counters that have XCP [pools](https://blockspace.wiki/glossary/liquidity-pool/), the ones on their way to one, and pages to mint or pool one yourself. ## Status Live at https://counters.fun (as of 2026-10-20). ## How it works Neither upstream answers the question the site is built on: the counters server ([counters.gallery](/projects/counters.gallery/)) knows files and numbers but not markets, and [Counterparty](https://blockspace.wiki/glossary/counterparty/) knows pools but not counter numbers. So every five minutes counters.fun joins the two, and rolls up depth, 24-hour volume and price change. The home page shows what can be bought, one venue at a time: the pool (consensus's quote at any size), the [Counterparty DEX](https://blockspace.wiki/glossary/counterparty-dex/) (open orders) and [dispensers](https://blockspace.wiki/glossary/dispenser/). Prices keep their own unit and nothing converts between them. On-chain content is re-served from the site itself, sandboxed. The mint page builds a [counter](https://blockspace.wiki/glossary/counter/), a [reinscription](https://blockspace.wiki/glossary/reinscription/) or a [fairminter](https://blockspace.wiki/glossary/fairminter/) deploy, and the pool page opens, adds to or withdraws from a pool and can lock the [LP tokens](https://blockspace.wiki/glossary/lp-token/) at the unspendable address. ## Key figures This wiki reads no live market figures from counters.fun. Its README, undated, records that 98 of the 168 counters indexed when it was written were pointers, and that MEMENOME, 69 KB of on-chain JavaScript, was then the only counter with a pool. For the current number of counters, see [counters.gallery](/projects/counters.gallery/). ## Glossary - **counter**: A Bitcoin Counter is "a numbered file event": a file committed to Bitcoin as the description of a [Counterparty](https://blockspace.wiki/glossary/counterparty/) asset, carried in a [Counterparty taproot envelope](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/fairminter/) deploy, and they reached the chain inside [witness data](https://blockspace.wiki/glossary/witness/). Either test alone is nothing. - **Counterparty**: The protocol whose assets carry [counters](https://blockspace.wiki/glossary/counter/). For counters it supplies identity, ownership, naming, transfer and, since its v11 [taproot envelope](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/inscription/) on its own output. The stored value is `counterparty/ord`. The first five [counters](https://blockspace.wiki/glossary/counter/) 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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/reveal-transaction/) pair. The message, an asset's description included, travels as data pushes in the reveal's input-0 [witness](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counterparty-plus-ord/) envelope, and both carry [counters](https://blockspace.wiki/glossary/counter/) equally. - **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. - **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. - **fairminter**: A Counterparty message that deploys a fair-minted asset. A fairminter deploy whose description is a file is itself a [counter](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/liquidity-pool/) at soft cap with every satoshi it raised, minting the [LP tokens](https://blockspace.wiki/glossary/lp-token/) to the unspendable address. - **liquidity pool**: A constant-product reserve pair on [Counterparty](https://blockspace.wiki/glossary/counterparty/), with its own [LP token](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counter/) that have pools against XCP. - **LP token**: The token a Counterparty [liquidity pool](https://blockspace.wiki/glossary/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. - **pointer counter**: A [counter](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. - **reinscription**: New content attached to a [Counterparty](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. - **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](https://blockspace.wiki/glossary/counter/) is keyed to. An unrevealed commit is nothing. - **rolling hash**: How independent counters indexers check that they agree. Each [counter](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/consensus-hash/). - **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. - **XCP asset**: An asset in the [Counterparty](https://blockspace.wiki/glossary/counterparty/) ledger. BTI's token catalogue calls XCP assets "the first blockspace tokens (2014)", counts XCP itself as one, and lists [counters](https://blockspace.wiki/glossary/counter/) as a subset. An asset's description can hold a file; when it reaches the chain in a [Counterparty taproot envelope](https://blockspace.wiki/glossary/taproot-envelope/), that description is a counter. On counters.fun's mint page, a named asset burns 0.5 XCP. ## FAQ ### Why are some counters missing from counters.fun? Its one rule is that only counters whose file is on Bitcoin are displayed. A [pointer counter](https://blockspace.wiki/glossary/pointer-counter/) is a valid counter, but showing it would mean fetching bytes from someone else's server, so counters.fun does not render or trade it. ### Which wallets work with it? Both Counterparty browser wallets, XCP Wallet and Horizon Wallet, through one adapter. Every flow is signed as a PSBT, because Horizon cannot sign a raw transaction; when a wallet cannot broadcast, the app falls back to Esplora. ### What is price per KB? [Price per KB](https://blockspace.wiki/glossary/price-per-kb/) is the market cap spread over the bytes the asset carries on chain: price × circulating supply ÷ KB, in the price's own unit. It is shown on every pooled card, dispenser card and DEX row. ### Can I buy from a dispenser by sending it BTC? No. Since block 866,000 a bare BTC payment to a [dispenser](https://blockspace.wiki/glossary/dispenser/) buys nothing. counters.fun's buy composes a Counterparty dispense, shows the price plus the miner fee, and the wallet signs it. ### What can I mint there? Three things through one commit and reveal path: a new [counter](https://blockspace.wiki/glossary/counter/), a [reinscription](https://blockspace.wiki/glossary/reinscription/) on an asset you own, or a [fairminter](https://blockspace.wiki/glossary/fairminter/) deploy whose description is the file. The XCP-69 preset follows xcp.fun's template and opens a [liquidity pool](https://blockspace.wiki/glossary/liquidity-pool/) at soft cap. Sources: - The project list at block.space/projects · https://block.space/projects - counters.fun README (BitcoinCounters/counters.fun) · https://github.com/BitcoinCounters/counters.fun - Bitcoin Counters v3, indexer and wallet: README (BitcoinCounters/counters) · https://github.com/BitcoinCounters/counters - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md - XCP wallet and transactions: a field guide · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/xcp-wallet-transactions.md - Blockspace Holdings records Updated: 2026-10-20 --- # counters.gallery Bitcoin Counters explorer: numbered inscriptions in Bitcoin witness data, owned through Counterparty assets. URL: https://blockspace.wiki/projects/counters.gallery/ Status: live Site: https://counters.gallery Source: https://github.com/BitcoinCounters/counters ## What it is counters.gallery is the explorer for Bitcoin [Counters](https://blockspace.wiki/glossary/counter/). In its own words: "Explore Bitcoin Counters: numbered inscriptions stored in Bitcoin witness data and owned through Counterparty assets, numbered from zero." A counter is "a numbered file event": a file committed permanently to Bitcoin as the description of an [XCP asset](https://blockspace.wiki/glossary/xcp-asset/), carried in a [Counterparty taproot envelope](https://blockspace.wiki/glossary/taproot-envelope/). [Counterparty](https://blockspace.wiki/glossary/counterparty/) carries identity, ownership, naming, transfer and the content itself; the counters protocol only says which events qualify and how they are numbered. ## Status Live at https://counters.gallery (as of 2026-10-20). Its status endpoint reports version 11.5.0; counters versions name the Counterparty Core release they target. ## How it works The `counters` tool indexes, mints, transfers and serves. For each block from 902,000 it fetches the block's issuances and [fairminter](https://blockspace.wiki/glossary/fairminter/) deploys from Counterparty Core, keeps valid ones with a non-empty description and drops rows Core derives on its own, checks that the transaction is a taproot [reveal transaction](https://blockspace.wiki/glossary/reveal-transaction/), then numbers the survivors in order and stores the content. It never reimplements Counterparty consensus, and it never advances past Counterparty's parsed height. The explorer and a read-only JSON API serve the index under fixed rendering rules: only on-chain files are shown, a [pointer counter](https://blockspace.wiki/glossary/pointer-counter/) is shown as text, HTML and SVG run sandboxed, and a [reinscription](https://blockspace.wiki/glossary/reinscription/) adds a new counter to the same asset. A [counterparty + ord](https://blockspace.wiki/glossary/counterparty-plus-ord/) counter is also an ordinals [inscription](https://blockspace.wiki/glossary/inscription/). The market layer over this index is [counters.fun](/projects/counters.fun/). The project also includes counters-proto, the older v2 protocol with its own `COUNT` envelope; its counters do not qualify under v3. ## Key figures - 554 counters, indexed to block 972,303 (https://counters.gallery/status, read 2026-10-20). - In the rendering audit of counters #0 to #86 (2026-07-17), 46 of the 87 were pointers, 19 text, 11 images, 3 audio, 4 HTML and 6 decoded stamps. ## Glossary - **counter**: A Bitcoin Counter is "a numbered file event": a file committed to Bitcoin as the description of a [Counterparty](https://blockspace.wiki/glossary/counterparty/) asset, carried in a [Counterparty taproot envelope](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/fairminter/) deploy, and they reached the chain inside [witness data](https://blockspace.wiki/glossary/witness/). Either test alone is nothing. - **Counterparty**: The protocol whose assets carry [counters](https://blockspace.wiki/glossary/counter/). For counters it supplies identity, ownership, naming, transfer and, since its v11 [taproot envelope](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/inscription/) on its own output. The stored value is `counterparty/ord`. The first five [counters](https://blockspace.wiki/glossary/counter/) 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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/reveal-transaction/) pair. The message, an asset's description included, travels as data pushes in the reveal's input-0 [witness](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counterparty-plus-ord/) envelope, and both carry [counters](https://blockspace.wiki/glossary/counter/) equally. - **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. - **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. - **fairminter**: A Counterparty message that deploys a fair-minted asset. A fairminter deploy whose description is a file is itself a [counter](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/liquidity-pool/) at soft cap with every satoshi it raised, minting the [LP tokens](https://blockspace.wiki/glossary/lp-token/) to the unspendable address. - **liquidity pool**: A constant-product reserve pair on [Counterparty](https://blockspace.wiki/glossary/counterparty/), with its own [LP token](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counter/) that have pools against XCP. - **LP token**: The token a Counterparty [liquidity pool](https://blockspace.wiki/glossary/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. - **pointer counter**: A [counter](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. - **reinscription**: New content attached to a [Counterparty](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. - **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](https://blockspace.wiki/glossary/counter/) is keyed to. An unrevealed commit is nothing. - **rolling hash**: How independent counters indexers check that they agree. Each [counter](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/consensus-hash/). - **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. - **XCP asset**: An asset in the [Counterparty](https://blockspace.wiki/glossary/counterparty/) ledger. BTI's token catalogue calls XCP assets "the first blockspace tokens (2014)", counts XCP itself as one, and lists [counters](https://blockspace.wiki/glossary/counter/) as a subset. An asset's description can hold a file; when it reaches the chain in a [Counterparty taproot envelope](https://blockspace.wiki/glossary/taproot-envelope/), that description is a counter. On counters.fun's mint page, a named asset burns 0.5 XCP. ## FAQ ### What is a counter? A [counter](https://blockspace.wiki/glossary/counter/) is a file committed to Bitcoin as the description of a [Counterparty](https://blockspace.wiki/glossary/counterparty/) asset, carried in [witness data](https://blockspace.wiki/glossary/witness/) by a [Counterparty taproot envelope](https://blockspace.wiki/glossary/taproot-envelope/), and numbered gap-free in order of creation from #0. ### Why do counters start at block 902,000? That is where Counterparty's taproot encoding activated. Before it, an asset description could not reach the chain in witness data, so no counter could exist. Counter #0, XDUALS, came five blocks later, at 902,005. ### Does the explorer show files hosted somewhere else? No. A counters server only shows on-chain files. A [pointer counter](https://blockspace.wiki/glossary/pointer-counter/) is shown as its pointer text and never fetched, and HTML and SVG run sandboxed. ### Can a counter's number change? Numbers are append-only, but numbers near the tip are provisional until confirmations pass, because a reorg rolls back and re-numbers identically. Amendment A1 (2026-09-24) removed one derived event, #163, and every later counter moved down by one. ### How can two explorers be sure they agree? Each counter extends a [rolling hash](https://blockspace.wiki/glossary/rolling-hash/). Two indexers agree on the whole history if and only if their latest rolling hash matches. Sources: - The project list at block.space/projects · https://block.space/projects - Bitcoin Counters v3, indexer and wallet: README (BitcoinCounters/counters) · https://github.com/BitcoinCounters/counters - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md - Counters server: rendering rules · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/rules.md - Counters notes · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/notes.md - The counters server /status (the index behind counters.gallery) · https://counters.gallery/status - Blockspace Holdings records Updated: 2026-10-20 --- # degent.club The Decentralized Gentlemen Club: a community-driven ordinal collection of unique Pepes in tuxedos, built on Bitcoin, with a non-custodial mint. URL: https://blockspace.wiki/projects/degent.club/ Status: live (since 2026-10-19) Site: https://degent.club Source: https://github.com/DegentClub/degent ## What it is degent.club is the [Decentralized Gentlemen Club](https://blockspace.wiki/glossary/decentralized-gentlemen-club/). In its own words it is "a community-driven 10K ordinal collection of unique Pepes in tuxedos, built on Bitcoin". The collection is 10,000 when fully minted: 4,112 inscribed (as of 2026-09-25 23:24:51 UTC). Its README describes the project as the collection plus "the 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". Each piece is a [Degent](https://blockspace.wiki/glossary/degent/). The project is maintained by [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/) with its community. ## Status Live at https://degent.club (as of 2026-10-20). It has been public since 2026-10-19 13:36Z. Blockspace Holdings names it one of its three most important holdings, with block.space and scribb.it. ## How it works The website is one React + Vite app: home, the collection gallery, the Full Block Exhibit, the [Atelier](https://blockspace.wiki/glossary/atelier/), the comic, the blog, the club, and the [Degent mint](https://blockspace.wiki/glossary/degent-mint/) at https://degent.club/mint. The mint and its SDK live in the public DegentClub/degent repository, which builds on a shared platform, DegentClub/scribbit (the platform behind [Scribbit](https://blockspace.wiki/glossary/scribbit/)), pinned as a git submodule. A minted Degent must meet the club's rules (a square image, a Pepe in a tuxedo with a bowtie, the [frame and placard](https://blockspace.wiki/glossary/frame-and-placard/)), and the frame and placard are part of the mint's automated art review. Day-to-day changes go through pull requests under [lazy consensus](https://blockspace.wiki/glossary/lazy-consensus/); significant ones need an [Architecture Decision Record](https://blockspace.wiki/glossary/architecture-decision-record/). ## Key figures - 4,112 Degents inscribed (as of 2026-09-25 23:24:51 UTC), of 10,000 when fully minted. - In a count on 2026-10-20, the 4,112 inscribed Degents totalled 1.51 GB, and the largest was 3.96 MB. ## Glossary - **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. - **Atelier**: A section of the degent.club website and a service in the Degent code. Its code renders the Degent [frame and placard](https://blockspace.wiki/glossary/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. - **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). - **Degent**: A Degent is an [inscription](https://blockspace.wiki/glossary/inscription/) in the [Decentralized Gentlemen Club](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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". - **frame and placard**: The ornamental gold picture frame and the placard reading `DEGEN`, `DEGENT` or `REGEN` that every [Degent](https://blockspace.wiki/glossary/degent/) carries. The club's minting rules require it ("Must be framed and include a placard"), and the [Degent mint](https://blockspace.wiki/glossary/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. - **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. - **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. ## FAQ ### How many Degents are there? The collection is 10,000 when fully minted. Today there are 4,112 inscribed (as of 2026-09-25 23:24:51 UTC). The 10,000 is the size of the finished collection, not a count of Degents that exist. ### What does a Degent have to look like? The club's minting rules ask for a square JPEG of at least 200KB, a Pepe character in a tuxedo with a mandatory bowtie, and the [frame with a placard](https://blockspace.wiki/glossary/frame-and-placard/) saying "DEGEN", "DEGENT" or "REGEN". You may mint as many as you want. ### Why have older pages shown other counts? A review of the site found three conflicting counts: the old site's 4,027 minted and 1,470 MB, 4,112 in the collection list, and 4,113 and 1,508 MB in an earlier analysis. It also calls the old "10K = 3+ GB" a projection presented as fact. ### Can I use the Degent art or name in my own project? No. The code is Apache-2.0 and the docs CC BY 4.0, but the artwork, the comic, the collection's images, the names and the [frame and placard](https://blockspace.wiki/glossary/frame-and-placard/) are not licensed. A fork must use its own name and art. Using the names to refer to the project is fine. ### Who decides changes to the code? Each component's owning team reviews and merges by pull request, under [lazy consensus](https://blockspace.wiki/glossary/lazy-consensus/). Significant decisions need an [Architecture Decision Record](https://blockspace.wiki/glossary/architecture-decision-record/). Licensing, trademarks and the Code of Conduct are decided by Blockspace Holdings. Sources: - The project list at block.space/projects · https://block.space/projects - DegentClub/degent README · https://github.com/DegentClub/degent - Blockspace Holdings records - DegentClub/degent GOVERNANCE · https://github.com/DegentClub/degent - DegentClub/degent ART-AND-TRADEMARKS · https://github.com/DegentClub/degent - DegentClub/degent TRADEMARKS · https://github.com/DegentClub/degent Live figures: degent as of 2026-09-25 23:24:51 UTC Updated: 2026-10-20 --- # devcash.dev Devcash: "Cash for the developer economy: a bounty platform and a decentralized exchange." URL: https://blockspace.wiki/projects/devcash.dev/ Status: live (hosted separately) Site: https://devcash.dev ## What it is [Devcash](https://blockspace.wiki/glossary/devcash/) is, in its card's words, "Cash for the developer economy: a bounty platform and a decentralized exchange." Its own site says: "Devcash (DEV) is cash for the developer economy. It is the official currency of Blockchain Developers United." It is a project of [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/) listed on block.space/projects. ## Status Live at https://devcash.dev (as of 2026-10-20). It is the one project hosted separately from the others. It is left off blockspace.holdings but stays on block.space/projects. ## How it works The site copy describes two services. The **[bounty](https://blockspace.wiki/glossary/bounty/) platform** is "a decentralized bounty platform where users utilize DEV to crowdsource developer talent or perform developer tasks and earn DEV". People post bounties or hunt them, and a bounty can carry an ETH or a DEV reward. The **Devcash DEX** is "a decentralized exchange with an ETH/DEV market", "fully automated on Ethereum smart contracts" with zero-fee trading. DEV is an ERC-20 token, and its allocation is an [initial bounty offering](https://blockspace.wiki/glossary/initial-bounty-offering/). The site is a Nuxt front end. ## Key figures From the site's copy (last changed 2023-04-05): a token supply of 2.1B DEV, token type ERC-20, allocated by IBO. This wiki reads no live figures for Devcash. ## Glossary - **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. - **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". - **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. - **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. ## FAQ ### What is Devcash? In its own words, "Devcash (DEV) is cash for the developer economy. It is the official currency of Blockchain Developers United." It offers a [bounty](https://blockspace.wiki/glossary/bounty/) platform and a decentralized exchange. See [Devcash](https://blockspace.wiki/glossary/devcash/). ### How does the bounty platform work? Users post a task and crowdsource developer talent, or hunt bounties: they perform developer tasks and earn DEV. A bounty can carry an ETH or a DEV reward. ### Where is it hosted? On its own server, separately from Blockspace Holdings' other projects (as of 2026-10-20). ### Is it on blockspace.holdings? No. Blockspace Holdings chose on 2026-10-20 to leave it off blockspace.holdings. It stays on block.space/projects. Sources: - The project list at block.space/projects · https://block.space/projects - Devcash site copy, from the reference clone (locales/en.json) · https://devcash.dev - Blockspace Holdings records Updated: 2026-10-20 --- # litepedia.space "Wikipedia on Litecoin. The encyclopedia uploaded to Litecoin, where anyone can pay LTC to make an edit, with a robust editing system." URL: https://blockspace.wiki/projects/litepedia.space/ Status: coming soon (a Coming soon page) Site: https://litepedia.space ## What it is In Blockspace Holdings' words (2026-10-20), [Litepedia](https://blockspace.wiki/glossary/litepedia/) is "a litecoin wikipedia project where we will upload wikipedia to litecoin and let people pay LTC to make edits (while having a robust editing system)". Its card reads: "Wikipedia on Litecoin. The encyclopedia uploaded to Litecoin, where anyone can pay LTC to make an edit, with a robust editing system." LTC is Litecoin's coin. litepedia.space belongs to the research group, beside [Blockspace Labs](https://blockspace.wiki/glossary/blockspace-labs/) and blockspace.to, under [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/). ## Status Coming soon (as of 2026-10-20). litepedia.space serves a "Coming soon" page until its own site is built. ## How it works Not yet built. The aim is to put the encyclopedia on Litecoin, where an edit is paid for in LTC. That needs a Litecoin node and an inscription indexer for Litecoin. Blockspace Holdings runs no Litecoin node as of 2026-10-20. Blockspace Labs' Litecoin and Dogecoin blockspace study covers the same ground. ## Glossary - **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. - **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. ## FAQ ### What is Litepedia? [Litepedia](https://blockspace.wiki/glossary/litepedia/) is a Blockspace Holdings project to upload Wikipedia to Litecoin and let people pay LTC (Litecoin's coin) to make edits, with a robust editing system. ### Can I read or edit it yet? No. As of 2026-10-20 litepedia.space shows a Coming soon page. Nothing has been uploaded to Litecoin. ### What does it need before it can start? A Litecoin node and an inscription indexer for Litecoin, to put content on-chain. Blockspace Holdings runs no Litecoin node as of 2026-10-20. Sources: - The project list at block.space/projects · https://block.space/projects - Blockspace Holdings records - The litepedia.space landing page (index.html) · https://litepedia.space Updated: 2026-10-20 --- # mintbitbars.xyz Bitbar minting app. URL: https://blockspace.wiki/projects/mintbitbars.xyz/ Status: live (page and image only; the Mint button's QR server does not answer) Site: https://mintbitbars.xyz Source: https://github.com/antron3000/Bitbar-Minting-App ## What it is mintbitbars.xyz is, in its own title's words, the "Bitbar Minting App": a page that shows a [bitbar](https://blockspace.wiki/glossary/bitbar/) and a "Mint Bitbar" button. Its card line on block.space/projects is "Bitbar minting app." No other description of it exists in Blockspace Holdings' records. ## Status The page is live at https://mintbitbars.xyz (as of 2026-10-20). Since 2026-10-19 it has been served from the code of antron3000/Bitbar-Minting-App, page and image only. The server that the Mint button's QR code comes from did not answer when checked on 2026-10-19. ## How it works The repository has three parts. The page shows the 1kB bitbar SVG and, on Mint, a payment box: use an ordinals wallet, send 0.00002 BTC to the address shown, and wait. A small server watches that address through a public block explorer API, records each payment and its sender in SQLite, and marks payments of at least 1,641 sats as needing a bitbar. A minter script polls the server for pending mints and inscribes the file with [ord](https://blockspace.wiki/glossary/ord/) (fee rate 3, postage 546 sats) to the sender's address. ## Key figures - The 1kB bitbar image the page shows is exactly 1,024 bytes. - The minter's log records 7 mints, from 2024-11-30 to 2024-12-01. This wiki reads no live figures for mintbitbars.xyz. ## Glossary - **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. - **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. - **ord**: The ordinals indexer and explorer. Its fork, run by [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/), serves blockspace.to and is the definitional source for BTI's inscription-to-sat binding, sat numbers and inscription numbers. ## FAQ ### What is a bitbar? A [bitbar](https://blockspace.wiki/glossary/bitbar/) is a bar-shaped [inscription](https://blockspace.wiki/glossary/inscription/) whose size is its name. The 1kB bitbar is exactly 1,024 bytes. ### Can I mint a bitbar there today? The page answers, but on 2026-10-19 the server behind its Mint button's QR code did not answer, and only the page and image are served. No source says whether payments are being turned into mints. ### How was a mint meant to work? The page asks you to use an ordinals wallet (it recommends Unisat), send 0.00002 BTC to the address it shows, and wait: the bitbar is minted to the sending address, at a standard fee rate of 3 sats/vB. ### Where is its code? In the public repository antron3000/Bitbar-Minting-App: the page, a payment-watching server and a minter script. Sources: - The project list at block.space/projects · https://block.space/projects - The mintbitbars.xyz checkout (antron3000/Bitbar-Minting-App): index.html, server/, minter/ · https://github.com/antron3000/Bitbar-Minting-App - Blockspace Holdings records Updated: 2026-10-20 --- # scribb.it Scribbit: a planned way to write a document or record directly into Bitcoin. "Write it once. Keep it forever." URL: https://blockspace.wiki/projects/scribb.it/ Status: coming soon (app coming soon; the domain is not yet public) ## What it is scribb.it is the home of [Scribbit](https://blockspace.wiki/glossary/scribbit/), a project of [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/). Its site calls it "a planned way to write a document or record directly into Bitcoin. You pay the network fee, and the bytes sit in a Bitcoin block that every [archival node](https://blockspace.wiki/glossary/archival-node/) keeps." The line on the site, "Write it once. Keep it forever.", comes from Blockspace Holdings' design brief and is not yet confirmed as Scribbit's line (as of 2026-10-20). block.space/projects carries the line "Built in-house." Blockspace Holdings names Scribbit one of its three most important holdings, beside block.space and degent.club (2026-10-19), and it is featured on blockspace.holdings. ## Status Coming soon (as of 2026-10-20). The app does not exist yet: no Scribbit code has been written. - **The site** was built on 2026-10-20. It is static: six pages and a facts list that gives every figure with its source. It describes; it does not transact. - **The domain** shows the registrar's placeholder page (as of 2026-10-20). The site goes public once the domain's nameserver change at the .it registry completes. - **The direction** of the product is open. Which of the planned promises are commitments, and the content policy and terms of use, are not yet set (as of 2026-10-20). ## What is planned Everything in this section is planned. It comes from Blockspace Holdings' design brief (October 2026), and none of it is a confirmed commitment yet. - **A [non-custodial](https://blockspace.wiki/glossary/non-custodial/) write path onto [Bitcoin L1](https://blockspace.wiki/glossary/bitcoin-l1/).** The user's own wallet funds and signs; Scribbit would never hold the user's money or keys. - **The network fee only, zero platform fee.** The user would pay what miners charge to put the bytes in a block, and nothing else. - **Up to about 400 KB** per [payload](https://blockspace.wiki/glossary/payload/) (see the limits below). - **For contracts, records, attestations and structured data, not art.** The site lists signed agreements, records that must not change later, proof that a file existed at a given block, and JSON, CSV or plain text. ## How it works (planned) The planned flow has five steps: payload, commit and reveal, batch, settle, cite. The mechanics are those of [ord](https://blockspace.wiki/glossary/ord/), the [inscription](https://blockspace.wiki/glossary/inscription/) indexer Blockspace Holdings runs at blockspace.to. 1. **Payload.** The user chooses the file. It is stored with a [content type](https://blockspace.wiki/glossary/content-type/) such as `application/pdf`. The site advises recording the file's [SHA-256](https://blockspace.wiki/glossary/sha-256/) hash first: it is how anyone later proves the bytes on chain are that file. 2. **Commit and reveal.** The payload goes inside an [envelope](https://blockspace.wiki/glossary/envelope/), a piece of [taproot](https://blockspace.wiki/glossary/taproot/) script that never runs, in data pushes of at most 520 bytes each. The [commit transaction](https://blockspace.wiki/glossary/reveal-transaction/) pays to a Taproot address whose script holds the envelope; the [reveal transaction](https://blockspace.wiki/glossary/reveal-transaction/) spends it and publishes the script, payload included, in its [witness](https://blockspace.wiki/glossary/witness/). 3. **[Batch](https://blockspace.wiki/glossary/batch/).** One commit and one reveal can carry several inscriptions, so they share the fixed cost of the transactions. Whether a batch would hold several customers' payloads in one reveal is not decided. 4. **Settle.** The reveal waits in the [mempool](https://blockspace.wiki/glossary/mempool/) until a miner includes it in a block: its first [confirmation](https://blockspace.wiki/glossary/confirmation/). A [reorg](https://blockspace.wiki/glossary/reorg/) can undo recent confirmations, so how many to wait for is a choice. 5. **Cite.** The user keeps a [citation](https://blockspace.wiki/glossary/citation/): the [inscription id](https://blockspace.wiki/glossary/inscription-id/), the block, the content type, the length and the SHA-256 hash. ## Cost, by the three books (planned) The cost is best read with block.space's [three books](/concepts/the-three-books/): the payload is [Book C](https://blockspace.wiki/glossary/book-c/), the operation is [Book B](https://blockspace.wiki/glossary/book-b/), and the whole transaction is [Book A](https://blockspace.wiki/glossary/book-a/). The fee is the transaction's size in [vbytes](https://blockspace.wiki/glossary/vbytes/) times the [fee rate](https://blockspace.wiki/glossary/fee-rate/). A payload sits in the witness, so every 4 bytes of payload cost about 1 vB. **A real example.** Inscription `2e2fd1b1ea70bc719eefd8efeaf224287409004cb3645d59bb2ef936a8aa358ci0`, a PDF titled "Forms Explained", was mined in block 965,177. | | | |---|---| | content type | application/pdf | | content length | 387,641 bytes | | sha256 | `f209bebb4739fbbb9a03a18fb2525a0a3bdbc8528247212425c746fcd2dec44b` | | reveal weight | 390,907 WU | | reveal virtual size | 97,727 vB | | fee | 49,842 sats ([sat](https://blockspace.wiki/glossary/sat/)) | | fee rate | 0.51 sat/vB | | Book C | 387,641 bytes (96,910.25 vB) | | Book B | 390,223 bytes | | Book A | 390,631 bytes (97,903 vB) | The fee, sizes and hash are read from the ord server at blockspace.to; the books are block.space's, as of block 972,199 ([the inscription on block.space](https://block.space/inscription/2e2fd1b1ea70bc719eefd8efeaf224287409004cb3645d59bb2ef936a8aa358ci0)). For one large file, the gap between the three books is small: the whole reveal is 0.8 % more than the payload alone. ## Limits (planned) - **Why about 400 KB.** Bitcoin Core's `MAX_STANDARD_TX_WEIGHT` is 400,000 weight units (in Bitcoin Core 28.2.0, the version Blockspace Holdings runs), and witness bytes weigh 1 WU each (BIP 141). So a [standard transaction](https://blockspace.wiki/glossary/standard-transaction/) can carry a little under 400,000 bytes of payload once its own framing is counted. Bigger inscriptions exist: the largest block.space ranks is 3,969,429 bytes, in block 873,893, in a transaction of 3,993,319 WU (as of block 972,199). A transaction that big is [non-standard](https://blockspace.wiki/glossary/standard-transaction/): default nodes do not relay it. Scribbit plans to stay inside the standard limit. - **Permanence is Bitcoin's**, not Scribbit's. Once mined, the bytes cannot be edited or deleted by anyone; archival nodes keep every block. - **Resolvability depends on indexers.** Bitcoin nodes store the bytes but do not know what an inscription is; an [indexer](https://blockspace.wiki/glossary/indexer/) such as ord finds them. The ord index at blockspace.to counts 128,169,401 inscriptions (127,697,358 blessed, 472,043 [cursed](https://blockspace.wiki/glossary/cursed-inscription/)), as of block 972,304, 2026-10-20 10:17:29 UTC. - **Everything is public.** For a confidential document, the site suggests writing its SHA-256 hash instead. - **"Permanence defeats takedown, not liability."** Whoever writes content remains responsible for it (the design brief). - **Fees change** with demand for blockspace; a quote holds only for the moment it is made. ## Glossary - **archival node**: A Bitcoin full node that keeps every block, as opposed to a pruned node, which discards old block data. - **batch**: Several inscriptions written by one [commit transaction](https://blockspace.wiki/glossary/reveal-transaction/) and one [reveal transaction](https://blockspace.wiki/glossary/reveal-transaction/), sharing their fixed cost. - **Bitcoin L1**: Bitcoin's base layer: the blockchain itself, not a sidechain or second-layer network. - **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. - **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](https://blockspace.wiki/glossary/shared-claim-axiom/). In the [partition](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/the-partition/) it is content only, "the artifact itself". - **citation**: What a writer keeps after writing an [inscription](https://blockspace.wiki/glossary/inscription/): its [inscription id](https://blockspace.wiki/glossary/inscription-id/), block, [content type](https://blockspace.wiki/glossary/content-type/), length and [SHA-256](https://blockspace.wiki/glossary/sha-256/) hash. - **confirmation**: A block containing the transaction. Each later block adds one more. - **content type**: The label stored with a [payload](https://blockspace.wiki/glossary/payload/) (such as application/pdf) that tells readers how to open it. - **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. - **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. - **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. - **indexer**: Software that reads every block and builds a searchable view of it. [ord](https://blockspace.wiki/glossary/ord/) is the indexer for inscriptions. - **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. - **mempool**: The waiting room of unconfirmed transactions that miners choose from. - **non-custodial**: Never holding the user's funds or keys: the user's own wallet funds and signs. - **ord**: The ordinals indexer and explorer. Its fork, run by [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/), serves blockspace.to and is the definitional source for BTI's inscription-to-sat binding, sat numbers and inscription numbers. - **payload**: The file being written into an [inscription](https://blockspace.wiki/glossary/inscription/). - **reorg**: When a competing chain replaces recent blocks, undoing their confirmations. - **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](https://blockspace.wiki/glossary/counter/) is keyed to. An unrevealed commit is nothing. - **sat**: One hundred-millionth of a bitcoin, the unit fees are paid in. - **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. - **SHA-256**: A cryptographic hash. The same file always gives the same 64-character hash, and any change gives a different one. - **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. - **Taproot**: The 2021 Bitcoin upgrade whose script-path spends carry inscription envelopes. - **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. ## FAQ ### Can I use Scribbit today? No. The app is coming soon (as of 2026-10-20) and no Scribbit code exists. The scribb.it site describes the planned product only: it connects no wallet, takes no payment and sends no transaction. ### Will Scribbit hold my money? As planned, Scribbit is [non-custodial](https://blockspace.wiki/glossary/non-custodial/): your own wallet funds and signs the transactions. This is not yet a confirmed commitment (as of 2026-10-20). ### What will it cost? As planned, the network fee only, with zero platform fee (not yet confirmed, as of 2026-10-20). For scale, a real 387,641-byte PDF paid 49,842 sats for its whole [reveal transaction](https://blockspace.wiki/glossary/reveal-transaction/) in block 965,177. ### Why about 400 KB? Bitcoin Core relays a transaction only up to 400,000 [weight units](https://blockspace.wiki/glossary/weight-unit/), and a [witness](https://blockspace.wiki/glossary/witness/) byte weighs one unit. So a standard reveal can carry a little under 400,000 bytes of [payload](https://blockspace.wiki/glossary/payload/). ### Can I delete or change what I write? No. Once a reveal is mined, nobody can edit or delete its bytes. To correct a record, the site suggests writing a new one that refers to the old one by its [inscription id](https://blockspace.wiki/glossary/inscription-id/). Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json - Blockspace Holdings records - The project list at block.space/projects · https://block.space/projects - The blockspace.holdings page (site/index.html) · https://blockspace.holdings - ord /status (the blockspace.to ord server) · https://blockspace.to/status Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # spaceblocks.art Space Blocks: one image that fills a 1 MB block, inscription #83,851,681, 1,047,584 bytes. URL: https://blockspace.wiki/projects/spaceblocks.art/ Status: live (since 2026-10-19) Site: https://spaceblocks.art ## What it is spaceblocks.art is the home of [Space Blocks](https://blockspace.wiki/glossary/space-blocks/). In its own words: "Space Blocks: one image that fills a 1 MB block. Inscription #83,851,681, 1,047,584 bytes, 99.9 % of a 1 MB block." Its second page shows the other works that fill a block. ## Status Live at https://spaceblocks.art since 2026-10-19 (as of 2026-10-20). ## How it works It is a static site, built from block.space's public API (https://block.space/api/largest-inscriptions), with the thumbnails copied into the site, so the pages load nothing from another origin. The Space Blocks facts are fixed and checked against block.space on each build. The site is rebuilt daily at 00:40 UTC. Its whole-blocks page lists the [whole-block](https://blockspace.wiki/glossary/whole-block/) works, largest first. ## Key figures From the site's build of block 972,262: - inscription #83,851,681, block 881,188; - 1,047,584 bytes, 99.9 % of a 1,048,576-byte block; JPEG, 1537 × 1537; - rank #157 of the 100,000 largest inscriptions on block.space; - 110 whole-block works listed on the whole-blocks page. ## Glossary - **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. - **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. - **whole-block**: block.space's size class for an [inscription](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/space-blocks/) itself, at 1,047,584 bytes, fills a 1 MB block and is below this class. ## FAQ ### What is Space Blocks? [Space Blocks](https://blockspace.wiki/glossary/space-blocks/) is inscription #83,851,681: one JPEG, 1537 × 1537, of 1,047,584 bytes, inscribed in block 881,188. ### Does it really fill a block? It fills 1,047,584 of the 1,048,576 bytes of a 1 MB block, 99.9 %. ### What are the other works on the site? The page "Other works that fill a block" lists the inscriptions block.space classes as [whole-block](https://blockspace.wiki/glossary/whole-block/), content over 3,500,000 bytes: 110 of them as of block 972,262, largest first, each linking to its record on block.space. ### Who made it? No source names an artist or gives a story (as of 2026-10-20), so the site shows only the facts. Sources: - The project list at block.space/projects · https://block.space/projects - The spaceblocks.art site: README, index.html, whole-blocks/ and tools/build.py · https://spaceblocks.art - Blockspace Holdings records Updated: 2026-10-20 --- # Alkanes Contract tokens called through protostones inside a runestone. metashrew's trace is the record; every contract that ran claims the bytes. URL: https://blockspace.wiki/protocols/alkanes/ An [alkane](https://blockspace.wiki/glossary/alkane/) is a token of the Alkanes protocol. BTI's token table calls alkanes "protostone VM tokens" and names each one by its AlkaneId, written `block:tx`. DIESEL is `2:0`. ## How Alkanes puts data on Bitcoin Alkanes messages are [protostones](https://blockspace.wiki/glossary/protostone/). They ride inside a runestone, in the OP_RETURN output that Runes uses, under the protorunes field, tag 16383. The case studies note that the tag is odd, so plain runes ignores it and never treats it as a [cenotaph](https://blockspace.wiki/glossary/cenotaph/). The data-types reference lists two Alkanes channels: protostones in OP_RETURN, and Alkanes WebAssembly in the witness [envelope](https://blockspace.wiki/glossary/envelope/). Case 2 of the BTI case studies decodes one carrier. A single 30-byte OP_RETURN holds a rune mint of UNCOMMON•GOODS and a protostone that mints DIESEL. Case 6 shows a runestone with two protostones, the first pointing at the second through a "shadow" output number past the real outputs. BTI's ruling on protorunes is short: a carrier convention, not to be built, because "the bytes belong to alkanes". ## How BTI attributes the bytes Alkanes is catalogued by the metashrew adapter, which reads [metashrew](https://blockspace.wiki/glossary/metashrew/). Its trust is "definitional" in the [trust triad](https://blockspace.wiki/glossary/trust-triad/): the indexer table says alkanes.wasm "IS the protocol". A [second-source adapter](https://blockspace.wiki/glossary/second-source-adapter/), alkanes-explorer, extracts the same trace feed independently. It records one row per executed trace for the executing contract only, and writes no bytes. The carrier bytes alone do not say which contracts ran, whether a call reverted, or what a number means as a call. The trace says it. Per the adapter, every contract whose code ran claims the transaction, plus the alkanes whose balances moved. Net movement decides the operation label: units that came out without coming in are a mint. The case studies show three shapes: - **Two protocols, one carrier** (case 2, block 911,180). The rune mint and the DIESEL mint each claim the whole 371-byte transaction. Each is backed by exactly half, 185.5 bytes, and its own message is a separate sub-span of the shared output. - **Five claimants** (case 5, block 911,180). A DIESEL swap through a router and pool contracts gives five alkanes identical whole-transaction claims. Each takes 90 of the 450 bytes. The case notes that a divisor counting region rows instead of tokens would have been "invisible here in every aggregate except the conservation line" (finding F1 confirmed the shipped function counts tokens). - **Blocked above the source** (case 6, block 961,190). metashrew stood at 949,716 when the case was studied, 11,474 blocks below the transaction. The bytes were fully measured and claimed by nobody. The answer for a transaction beyond a source's tip is a refusal, not a guess. Finding F8 adds an operational fact. Because the catalogue pass clamps at the lowest source tip, a lagging metashrew holds back even natively decoded runes in the same transactions. The indexer table calls metashrew "routinely the pass's binding clamp". See [the frontier](/concepts/the-frontier/). Factory and router calls carry no envelope, so their [Book C](https://blockspace.wiki/glossary/book-c/) is 0. Blockspace Holdings' records list 68 MB of Alkanes content, protostone payloads and WebAssembly, carried in runestone envelopes. ## Live figures The family's books (as of block 972,299, 2026-10-20 09:30:48 UTC): | measure | value | |---|---| | Book A | 11.95 GB | | Book C | 0.07 GB | | share of the chain's bytes (Book A) | 1.54 % | | share of all Book A bytes | 8.93 % | | tokens | 104,023 | | operations | 107,371,036 | | first height | 880004 | ## Holders The alkanes holders study (measured 2026-10-19) found the family's weight concentrated. DIESEL alone held 10.99 GB, 92.1 % of the family's Book A. The top 10, 100 and 1,000 tokens held 95.5 %, 98.9 % and 99.9 %. It rejected two routes. The alkanes-explorer database holds no balances. Replaying metashrew's views would mean reimplementing contract execution, and spent outputs still answered. The chosen route reads metashrew's database as a secondary instance, filters out spent outputs, and then updates per block. That route covered 84,557 tokens holding 99.10 % of the family's bytes, across 60,384 holder scripts. Tokens with no current holder (0.107 GB) are a gap row, "no current holder". Read on 2026-10-20, the leaderboard's coverage table placed 99.10 % of the family's Book A on 60,421 addresses. ## Not covered by a source The July 2026 measurement run gives no bytes:vbytes ratio for Alkanes, and no Blockspace Holdings document describes the WebAssembly envelope's layout. Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - block.space protocols API · https://block.space/api/protocols - block.space leaderboard coverage API (holders measured per protocol) · https://block.space/api/leaderboard/coverage Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # ARC-20 and Atomicals Atomicals' fungible ARC-20 tickers, whose units ride sats, and its NFTs (containers and dmitems). One definitional indexer, one quarantine, one named gap: realms. URL: https://blockspace.wiki/protocols/arc-20-and-atomicals/ Atomicals defines two kinds of token that BTI measures. [ARC-20](https://blockspace.wiki/glossary/arc-20/) tickers are fungible, and the books keep them under the key `arc20`. Atomicals NFTs, [containers and dmitems](https://blockspace.wiki/glossary/atomicals-container/), are a second family, `atomicals-nft`. Both are catalogued by one adapter, as BTI's rule of one adapter per indexer requires: "atomicals catalogues ARC-20 AND the NFTs". ## How Atomicals puts data on Bitcoin Atomicals writes to the witness. The data-types reference lists it among the envelope protocols and gives its marker, `atom`, among those a reader scans for inside an `OP_FALSE OP_IF … OP_ENDIF` block. The Atomicals observation says every `atom` witness envelope ever revealed "remains consensus-valid data". An Atomical's identity comes from its commit. Ruleset v1's fact table gives it as `atomical_id = commit_txid ‖ LE32(commit_vout)`: the commit transaction's id followed by the commit output's number. A ticker or a container name is an alias. ARC-20 is coloured sats. The token table says "one unit = one sat by protocol design — the units RIDE sats, the ticker is the claimant". The Atomicals observation adds the consequence: spent through a wallet that does not know the protocol, the units scramble or burn under the protocol's own rules. BTI's token table writes it as "decays by scrambling"; the observation calls it [decay-by-amnesia](https://blockspace.wiki/glossary/decay-by-amnesia/). ## How BTI attributes the bytes The atomicals adapter reads atomicals-go, an indexer with its own database. Its trust is "definitional" in the [trust triad](https://blockspace.wiki/glossary/trust-triad/): the indexer's ruleset is the protocol. It has two modules, `arc20` and `atomicals-nft`. The ruleset's facts and the adapters table record four quirks: - **NFT binding is outpoint-positional**, and the rule forks at block 819,181 (raw input index before, first-in-first-out after). BTI does not re-derive it and adopts the source's verdicts. - **A quarantine.** From block 848,521 atomicals-go writes negative amounts into its own ledger, a bug measured at 131,329 lines in 65,036 transactions. Rows that touch one are quarantined: they get no supply change and are counted, and their claims stand. The owner ruled on 2026-08-11 that "the source ledger is corrupt state, not protocol state". - **Some measured scramble is the implementation's.** Before the fork, part of what measures as scramble is atomicals-go burning where the reference would colour an exact-remainder output. BTI adopts it under the writer rule and records it. - **Realms are a named gap.** The source holds zero [realms](https://blockspace.wiki/glossary/atomicals-realm/) against about 28 % of the footprint (verified 2026-08-10). The adapter fails closed, the gap is counted per window and claimed by nobody, and a test turns red the day realm rows appear. Two more rulings narrow the family. `Dmint` is a mint rule, a state field, not an object. A container's membership is a group: it has aggregated books but claims nothing. ARC-20 carries no file in the books. Its [Book C](https://blockspace.wiki/glossary/book-c/) is 0, and its weight is structure and overhead. ## Live figures ARC-20 tickers (as of block 972,299, 2026-10-20 09:30:48 UTC): | measure | value | |---|---| | Book A | 4.95 GB | | share of the chain's bytes (Book A) | 0.64 % | | share of all Book A bytes | 3.70 % | | tickers | 657 | | operations | 8,284,671 | | first height | 808081 | Atomicals NFTs (as of block 972,299, 2026-10-20 09:30:48 UTC): | measure | value | |---|---| | Book A | 0.07 GB | | share of the chain's bytes (Book A) | 0.01 % | | tokens | 32,230 | | operations | 32,517 | | first height | 808579 | | last height | 929700 | The token table counted 1,766 containers and 30,464 dmitems on 2026-08-10, 32,230 in all. Holders: read on 2026-10-20, the leaderboard's coverage table placed 99.96 % of ARC-20's Book A on 105,769 addresses, with 302 of the 657 tickers having a holder. It placed 98.24 % of the NFTs' Book A on 8,249 addresses. ## The natural experiment The Atomicals observation, a companion to [Blockspace Value Theory](https://blockspace.wiki/glossary/bvt/), proposes that Atomicals is "the control group BVT has been missing": its consumption is permanent, its interpretation layer died but can be rebuilt from chain data and published rules, and its live supply shrinks with every spend by a wallet that does not know the protocol. It lists what can be measured, among them total kB consumed and live against destroyed supply over time. That is a proposal, not a measured result; see [Atomicals as a natural experiment](/concepts/atomicals-natural-experiment/). ## Not covered by a source Blockspace Holdings' documents give no bytes:vbytes ratio for Atomicals, and no measured decay-by-amnesia curve. They do not describe the `atom` envelope's fields beyond its marker. Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: Atomicals · https://block.space/docs/atomicals - Atomicals as a natural experiment for BVT · https://block.space/docs/atomicals - block.space protocols API · https://block.space/api/protocols - block.space leaderboard coverage API (holders measured per protocol) · https://block.space/api/leaderboard/coverage Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Bitmap Bitmap districts are labels on inscribed sats: BTI's opi-bitmap adapter adds a source under Ordinal Sats, never a family of its own. URL: https://blockspace.wiki/protocols/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." [Bitmap](https://blockspace.wiki/glossary/bitmap/) writes a claim to a block, a district, as an inscription. In [BTI](https://blockspace.wiki/glossary/bti/) a district is not a token. It is a [label](https://blockspace.wiki/glossary/label/) on an inscribed sat, and Bitmap's bytes are counted under [Ordinal Sats](https://blockspace.wiki/glossary/ordinal-sats/). Bitmap has no family of its own in the books, so this page has no live share. ## How Bitmap writes to Bitcoin A district claim is an ord [inscription](https://blockspace.wiki/glossary/inscription/). The BTI protocol review of 2026-08-29 worked one by hand: a 397-byte transaction at block 900,095 holding seven envelopes, each a 13-byte `text/plain` body spelling `900095.bitmap`. All seven bound to the same sat. The review's other example, at block 933,996, is a single inscription whose content is `933996.bitmap`. ## How BTI attributes its bytes Ruling U3 decides what Bitmap is. "A token is exactly what can be transferred by itself, proven on chain; everything else is a label on one." The inscription is content bound to a sat, and the sat is the token (B14). The token table therefore lists bitmap sats as a sub-subset: inscribed sats whose inscription is a district claim, where the district number is a label (an owner ruling of 2026-08-02). In the adapter rulings' words, "bitmap catalogues inscribed sats, not 'districts'". The opi-bitmap [metaprotocol adapter](https://blockspace.wiki/glossary/metaprotocol-adapter/) adapts opi-bitmap, one of the three OPI indexers. They sync independently, so each has its own adapter and its own height clamp. Its trust is derived. Because Bitmap claims the same token the ord adapter claims, the two claims collapse to one claimant: two claims on one token give n = 1, never a division. Their regions are unioned, not summed. In the 900,095 example, the Bitmap claim's regions (31 bytes of output 0 and one 35-byte envelope span) are a strict subset of the inscriptions claim's. The books read content 91, structure 275, overhead 0: Book C 91, Book B and Book A 366 bytes, with 31 bytes of output 1 unattributed. The review's conclusion: a label-writing second source "cannot change n or add a byte". ## Quirks on record - **Genesis.** Claims begin at block 792,435, matching BTI's `bitmap-genesis` landmark. - **One district per block.** At the claims frontier of 964,607 the review counted 964,604 district labels, exactly one per block. The review calls this the first-is-first rule, enforced by the label table's key. - **Sightings and the second source.** opi-ord, a second source on inscribed sats, sights the Bitmap-shaped carriers among others, and its claims are diffed against the ord adapter's window by window. ## What the live data shows Bitmap appears in the live protocols API as a source inside the `sat` family. On 2026-10-20 at 09:42 UTC it listed the bitmap source with 972,116 sat tokens and 304,024,598 bytes attributed, within the family figures of Ordinal Sats. These overlap with the inscriptions source, since both claim the same sats. bitmap.holdings is the owner's Bitmap site, hosted elsewhere; see [bitmap.holdings](/projects/bitmap.holdings/). Sources: - Blockspace Holdings records - bitmap.holdings, its own home page, read 2026-10-20 · https://bitmap.holdings - block.space protocols API · https://block.space/api/protocols Updated: 2026-10-20 --- # BRC-100 An inscription-borne tick ledger with a two-step transfer; its only mirror died, so BTI was ruled its indexer on 2026-08-11. URL: https://blockspace.wiki/protocols/brc-100/ BRC-100 is a fungible tick ledger written in inscriptions. In [BTI](https://blockspace.wiki/glossary/bti/)'s token table its tokens are BRC-100 ticks, each identified as `brc100:`, case-folded. BTI is its indexer: it is a [native protocol](https://blockspace.wiki/glossary/native-protocol/), read by BTI's own brc100 decoder. ## How BRC-100 writes to Bitcoin BRC-100 operations are JSON bodies in ord [inscriptions](https://blockspace.wiki/glossary/inscription/). Each operation therefore has two claimants: the tick, and the sat that carries the inscription. The ruleset records the protocol's facts as BTI reads them: - `p` is case-insensitive, and uppercase is 54 % of the population; - a tick of 4 bytes is reserved (the protocol voids its own first deploys, `ordi` and `sats`); ticks of 3 or 5 to 100 bytes are legal; - a deploy sets `max`, `lim`, `mma` and `dec` (at most 18, default 18), and mints count against `mma`; - a transfer has two steps. The transfer-inscribe has no ledger consequence: it arms a note on the inscription's destination output and locks the amount. The send is any spend of that output, and the output that covers the note's sat position receives the units. BTI's BRC-100 study (2026-08-05) measured 200,065,278 bytes in 2,601 blocks, 4.55 % of every byte Bitcoin confirmed while it ran. In block 822,364 it took 6,384 of 6,511 transactions and 97.21 % of the block. One tick, `bos`, is 98.5 % of it. The study found that an earlier, lowercase-only count had seen only 46 % of the payloads. ## How BTI attributes its bytes BTI first meant to adapt inBRC's keyed mirror, the only source that ever existed. It never answered: probed on 2026-08-05 and again on 2026-08-11, it timed out on every route. A source that does not answer would stall the whole roster, so BRC-100 was ruled natively indexed on 2026-08-11. BTI's decode is the record (B32), and no adapter exists or is planned. The decoder claims for the tick only; the sat's claim is the ord adapter's. The transfer-inscribe writes no tick claim, a lesson the ruleset credits to an off-by-one found in BRC-20. The send claims. The tick's Book C is 0 by the ruleset, because the JSON body is the sat's content (B14); the envelope span is shared with the sat's claim and divided by the books. Mint2, mint3, burns, `cop` and all application state are typed [residue](https://blockspace.wiki/glossary/residue/): seven occurrences in 621,485 payloads. The transferability gate passed on 2026-08-11 and was re-verified on BTI's own node: a transfer-inscribe of 36,000 `bos` at block 820,820, and a send six blocks later that landed the units on the buyer's dust output while the seller was paid 716,400 sats. ## Findings of the August review The BTI protocol review of 2026-08-29 found three things. - **Book C is not zero.** BRC-100 carried 20.1 MB of Book C where the ruleset says 0, traced to a 2026-08-16 schema ruling that span-covering claims own content atoms, which had not entered the ruleset text. - **It had not ended.** Its apparent end at block 955,000 was only the books' horizon; a `bos` claim stood at block 964,137. - **Tick length is counted in bytes.** A single CJK character is 3 bytes and so a legal tick, while a single emoji, at 4 bytes, is rejected as reserved. The review calls this a documented convention, not an error. ## Live figures BRC-100 holds 0.14 GB in Book A, 0.02 % of the chain's bytes and 0.11 % of all Book A, with 0.02 GB in Book C. The books count 560 ticks across 715,589 operations, from block 805913 to 972145 (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # BRC-20 Tick ledgers written as JSON inscriptions, and since 2026-08-11 also on bare OP_RETURN. A BRC-20 mint has two claimants, the sat and the tick. BRC-100 is covered here too. URL: https://blockspace.wiki/protocols/brc-20/ A [BRC-20 tick](https://blockspace.wiki/glossary/brc-20-tick/) is a fungible token named by its tick. BTI's token table says a tick is a token because its units transfer by themselves under the protocol's ledger rules. The inscription that carries an operation is not the token. Its identity is the case-folded tick. ## How BRC-20 puts data on Bitcoin BRC-20 operations are JSON bodies. Most are [inscriptions](https://blockspace.wiki/glossary/inscription/), inside ord's witness [envelope](https://blockspace.wiki/glossary/envelope/). Case 10 of the BTI case studies is the first BRC-20 mint, at block 779,833, one block after the `ordi` deploy. Its body is 71 bytes of JSON in a 338-byte reveal. Case 3's body reads `{"p":"brc-20","op":"mint","tick":"牛b","amt":"1000"}`, 53 bytes. A second population writes the same JSON shape, `{"p":"brc-20"}`, into a bare OP_RETURN output. The census marks it by the prefix `7b227022` (`{"p`). When BTI gated them in on 2026-08-11, the full decode found 652,884 parseable carriers, 36.3 MB in the adapters table's figure. ## How BTI attributes the bytes BRC-20 has two carriers and one namespace, and three sources: | source | kind | trust | what it records | |---|---|---|---| | opi-brc20 | [metaprotocol adapter](https://blockspace.wiki/glossary/metaprotocol-adapter/) on the [OPI](https://blockspace.wiki/glossary/opi/) BRC-20 ledger | derived | the inscribed ledger: deploys, mints, transfers | | brc20-opreturn | [native decoder](https://blockspace.wiki/glossary/native-protocol/) | native | the OP_RETURN population, with BTI's replay as the record | | brc20-prog | [second-source adapter](https://blockspace.wiki/glossary/second-source-adapter/) on the BRC2.0 EVM | derived, two hops | sightings of tick movements the EVM executed | A tick seen on both carriers is one token with two sources. Ticks found only on OP_RETURN, such as 'prompt', 'lol' and 'gamestop', whose lengths the inscribed rules exclude, enter by their OP_RETURN deploy. **The co-claim.** A BRC-20 mint inscription has two claimants: the sat it is inscribed on and the tick. They divide the bytes they share. In case 10 the tick's regions are only the 107-byte envelope span, so it takes 53.5 bytes of [Book B](https://blockspace.wiki/glossary/book-b/) and the sat takes 284.5. [Book C](https://blockspace.wiki/glossary/book-c/) belongs to the sat alone. The JSON is the inscription's content, and "the ledger claims where it was written, not what the picture is". The two claims are labelled differently: the tick's is `mint`, the sat's is `inscribe`. **A bias that was found and fixed.** In the case studies the brc20 adapter could not recover the signer of a taproot key-path spend, so its claims failed closed to riding while the sat's were dedicated. Finding F7 called this a directional bias toward the sat. It was ruled on 2026-08-10: one shared retry helper now serves brc20 and alkanes too, and "the asymmetry is closed". **The OP_RETURN record.** Ruleset v1's fact table says no ledger for OP_RETURN BRC-20 exists anywhere: OPI only reads inscriptions, and BRC2.0 was checked and is not one either. So BTI's replay is the record (B32). Its rules are recorded too: - mints are deploy-gated: 240,060 of 538,648 mints name a tick not yet deployed, and are [residue](https://blockspace.wiki/glossary/residue/); - a mint credits the `add` field where it is present and valid, otherwise the first non-OP_RETURN output; - a transfer debits the first input's previous output and credits the minimum-value non-OP_RETURN output, a counted convention that decodes both a listing and a marketplace sale; - amounts are scaled to 18 decimals, and the last mint is clamped to the supply left. The transferability gate was passed on chain: deploy at block 896,552, mint at 896,558, and transfer at 896,583 to a different script. ## BRC-100 BRC-100 is a separate family in the books, with its own tick ledger written in inscriptions. Its only external source, inBRC's mirror, stopped answering (first probed dead 2026-08-05, again 2026-08-11), so BTI was ruled its indexer on 2026-08-11. The decoder records these facts: - `p` is case-insensitive; - 4-byte ticks are reserved; - a transfer is a [two-step transfer](https://blockspace.wiki/glossary/two-step-transfer/): the transfer inscription writes no tick claim, and the send that spends it does; - every operation has two claimants, the tick and the carrying sat, and the tick's Book C is 0 under B14. The adapters table measured 200 MB in 2,601 blocks, and at block 822,364 BRC-100 was 97.21 % of its block. Live (as of block 972,299, 2026-10-20 09:30:48 UTC): Book A 0.14 GB, 0.02 % of the chain, 560 ticks, 715,589 operations, first height 805913. The live API reports 0.02 GB of Book C for the family. Blockspace Holdings' documents do not explain how that matches the tick's Book C of 0. The leaderboard's coverage table lists BRC-100 holders as not measured. ## Live figures BRC-20's books (as of block 972,299, 2026-10-20 09:30:48 UTC): | measure | value | |---|---| | Book A | 17.49 GB | | Book C | 2.42 GB | | share of the chain's bytes (Book A) | 2.25 % | | share of all Book A bytes | 13.08 % | | ticks | 372,135 | | operations | 95,940,625 | | first height | 779832 | Read from the protocols API on 2026-10-20 (books at block 972,199), the sources split as follows. opi-brc20: 17.38 GB over 372,001 ticks. brc20-opreturn: 110.3 MB over 188 ticks. brc20-prog: 0.94 MB over 229 ticks. One tick, SATS, is its own sub-item at 3.79 GB. `sats` is the largest tick by content, 605 MB of mints, so a board ranking BRC-20 content must say it is the sum of many small files. Holders: read on 2026-10-20, the leaderboard's coverage table placed 99.08 % of BRC-20's Book A on 1,574,070 addresses. ## Not covered by a source Blockspace Holdings' documents give no bytes:vbytes ratio for BRC-20 on its own; the July 2026 run measured inscriptions as a whole. OP-20, which uses BRC-20's OP_RETURN shape plus a required `add` credit address, is its own family in the books and is not described here. Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: rankings · https://block.space/docs/rankings - block.space protocols API · https://block.space/api/protocols - block.space leaderboard coverage API (holders measured per protocol) · https://block.space/api/leaderboard/coverage Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Charms A zero-knowledge token protocol whose spells state the resulting charms in the clear; it moved from witness to OP_RETURN, and its Bitcoin-side supply is a lower bound. URL: https://blockspace.wiki/protocols/charms/ Charms is a zero-knowledge token protocol. In [BTI](https://blockspace.wiki/glossary/bti/)'s token table its tokens are Charms, each identified by a charm id, with the note "supply is a lower bound". BTI is its indexer: it is a [native protocol](https://blockspace.wiki/glossary/native-protocol/), read by BTI's own charms decoder. ## How Charms writes to Bitcoin BTI's Charms attribution study (2026-08-04) rests on one finding: "the spell states the resulting charms in the clear". A spell is the message that moves charms. A Groth16 proof travels with it and only certifies that the app's own rules were obeyed. So there is no virtual machine to run and no state to fetch: the token layer can be read from block bytes with a parser. The study places Charms alone in a bucket it calls "complete-and-readable", between commitment-only protocols (excluded, because their state lives off chain) and OP_NET (complete, but readable only by executing it). Spells use two carriers, with one marker: - up to version 8, a taproot [witness envelope](https://blockspace.wiki/glossary/envelope/) that opens `OP_FALSE OP_IF` and pushes `spell`; - from version 9, an [OP_RETURN](https://blockspace.wiki/glossary/op-return/) that pushes `spell`. The data-types reference names single-transaction atomicity as one reason a small message chooses OP_RETURN, and lists Charms among them. ## A controlled witness-discount measurement The study calls the carrier move the roster's cleanest witness-subsidy experiment, because the payload stayed the same while the carrier changed. It recorded that the same spell of about 800 bytes costs 4.16 times more block weight in OP_RETURN than in the witness, against a theoretical floor of 4.00. Protocol-wide bytes per vbyte fell from 2.627 in the witness era to 1.110 in the OP_RETURN era. The ratio stays above 1.0 even then, because Charms transactions still spend inputs whose signatures sit in the witness. See [the witness discount](/concepts/witness-discount/). ## How BTI attributes its bytes The decoder runs in replay mode over both carriers. Some points from the study: - **Identity is on the wire.** A charm's ref is its app triple, `//`, copied verbatim from the spell. The verifying key is part of the identity, so an app that upgrades its code mints a new token. BTI does not merge the two, and keeps the app identity as an alias so the versions can be found together. - **The proof is framing.** "A zero-knowledge proof is protocol framing, not artifact body": its bytes are carrier span, in Book B, never Book C. The August review confirmed that the decoder declares content 0 for every claim. - **Cross-chain leakage.** A spell can beam a charm out to Cardano, which lowers Bitcoin-side supply with nothing destroyed, and a charm can arrive with no Bitcoin genesis. The study calls this a fifth decay category. In its words, "Bitcoin-side supply is a lower bound on global supply, not a measurement", and the roster records that the bound is declared unconditionally. - **Commits.** Each witness-era spell needs a commit transaction, an [enabler](https://blockspace.wiki/glossary/enabler/) whose bytes join the spell's Book A only. ## Findings of the August review The BTI protocol review of 2026-08-29 found 99.56 % of Charms' Book B on riding claims, the largest such share among the native protocols it audited, and that the decoder declares dedicated outputs on riding verdicts, where ruling B30(1)(iii) reserves the funding remainder for dedicated claims. How much of that riding Book B is over-claimed was not measured. ## Live figures Charms holds 63,321,013 bytes in Book A and 0 in Book C. The books count 28 charms across 82,119 operations, from block 895211 to 971336 (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # CoinSpark A coloured-output asset protocol whose default route moves units with no CoinSpark bytes at all: the most extreme free-ride measurement recorded. URL: https://blockspace.wiki/protocols/coinspark/ CoinSpark is a ledger-protocol family in [BTI](https://blockspace.wiki/glossary/bti/)'s token table. Its tokens are CoinSpark assets, each identified by an asset ref; in case 19 of the BTI case studies, the ref is the genesis txid. BTI is its indexer: it is a [native protocol](https://blockspace.wiki/glossary/native-protocol/), read by BTI's own coinspark decoder. ## How CoinSpark writes to Bitcoin CoinSpark messages ride [OP_RETURN](https://blockspace.wiki/glossary/op-return/) outputs. A genesis message carries the marker `53504b67`, "SPKg". In case 19, the retry genesis's OP_RETURN output is 51 bytes: 11 bytes of framing and a 40-byte payload. Besides its own genesis and transfer operations, units can move by the default route, which, in the roster's words, "moves units in txs with no CoinSpark bytes". ## How BTI attributes its bytes The decoder runs in replay mode, as a coloured-OUTPUT walk. Ruling U4 names CoinSpark's per-claimant sub-spans as a deliberate finer decomposition of a shared carrier (B30(2)/B23), and CoinSpark is one of the protocols converged onto BTI's single Book B convention (B38). A unit moved by the default route wrote no CoinSpark byte, so its claim declares only the carrying structure, with dedication None. Such a claim is judged [carriage](https://blockspace.wiki/glossary/carriage/): measured in full, zero in every book in the default mode. Case 18 shows it on a 423-byte transaction: an Open Assets issuance with CoinSpark units drifting through. The CoinSpark claim's 170 declared bytes go to carriage, and Open Assets keeps 253. The token table says CoinSpark "conserves, custody drifts", and that its validation asterisk is a bound on supply (B8). Supply deltas gate on recorded validity, while claims gate on the claim gate alone (B4a). ## The failed genesis Case 19 is CoinSpark's first on-chain bytes, at block 308,878. The genesis underpaid the protocol's minimum fee, so CoinSpark's own rules voided it and no asset ever existed. With no token there is no claim, and CoinSpark is not on the allowlist for attempted claims, so its 888 bytes are [residue](https://blockspace.wiki/glossary/residue/): measured demand, claimed by nobody. The retry in the next block worked. Its claim is riding, because one output was a leg no protocol rule required; it keeps 514 bytes in Books A and B, and the unnamed 34-byte output stays unattributed. ## The free-ride index: three regimes The July 2026 measurement run recorded "a three-regime collapse: 1.00 → 0.91 → 0.09" in CoinSpark's [free-ride index](https://blockspace.wiki/glossary/free-ride-index/) (Book B ÷ Book A). Measured separately, its regimes read: genesis 0.913, dedicated transfer 0.963, protocol-unaware carriage 0.405, with a per-claim floor of 0.026. In its late regime CoinSpark moved token state by the default route, with no carrier bytes at all, "so almost everything it claims under the inclusive book is somebody else's payment". The measurements document calls it "the most extreme free-ride measurement recorded". See [carriage and the free-ride index](/concepts/carriage-and-the-free-ride-index/). ## Findings of the August review The BTI protocol review of 2026-08-29 found that 99.58 % of CoinSpark's claims were default-route drift declared None, which is why its operation count is so large beside its bytes. It also found that 29.3 % of the bytes inside CoinSpark's own carrier transactions reached no book: carriage co-claimants enter the divisor and are then zeroed, so the dedicated claimant keeps only its share. And the decoder's own log printed footprint and undivided union under the headings "Book A" and "Book B": 980,710,160 bytes, against 1,999,031 bytes in the books. ## Live figures CoinSpark holds 1,999,031 bytes in Book A, and 0 in Book C. The books count 1,649 assets across 2,785,647 operations, from block 308879 to 972263 (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space docs: measurements · https://block.space/docs/measurements - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Colu Colored Coins 2.0: a coloured-UTXO protocol over two carriers, OP_RETURN and bare multisig, whose identity is a pure function of chain data. URL: https://blockspace.wiki/protocols/colu/ Colu is the company behind Colored Coins 2.0. In [BTI](https://blockspace.wiki/glossary/bti/)'s token table its tokens are Colu assets, each identified by an asset id. BTI is its indexer: it is a [native protocol](https://blockspace.wiki/glossary/native-protocol/), read by BTI's own colu decoder. ## How Colu writes to Bitcoin BTI's Colu attribution study (2026-08-05) gives the encoding. Every message is an [OP_RETURN](https://blockspace.wiki/glossary/op-return/) whose push begins with the magic `43 43` (ASCII "CC"), a version byte (0x01 in 2015 and 2016, 0x02 from 2016) and an opcode. Over blocks 300,000 to 699,999 the study counted 63,916 issuances, 208,578 transfers and 288 declared burns. The two versions overlapped for 5,767 blocks, so a reader must accept both. Some issuance and transfer opcodes (0x02, 0x03, 0x11, 0x12) split their metadata: the hash goes into a [bare multisig](https://blockspace.wiki/glossary/bare-multisig/) output beside the OP_RETURN. The study proved this by joining carriers: every 0x02 and 0x11 transaction in the sampled range has a 71-byte multisig carrier. A Book B built from the OP_RETURN marker alone would miss those bytes. This is the roster's "two carrier kinds". An asset's identity does not depend on its metadata. The study overturned the earlier view that it did: a Colored Coins asset id is `Base58Check(padding ‖ hash160 ‖ divisibility)`, computed from the issuance transaction's own first input and on-chain policy bits. The metadata behind the torrent hash is gone (a live probe found zero peers), and a name is only a [label](https://blockspace.wiki/glossary/label/). ## How BTI attributes its bytes The decoder runs in replay mode, a coloured-UTXO walk over both carrier kinds, and the roster notes that every block must be read. Book C is zero for every Colu claim. The hashes are pointers to off-chain bodies, not bodies, so the study classes Colu as a pure-ledger protocol. In its words, Colu spent "331,440 bytes of Bitcoin, permanently, to commit to a name nobody can read". Colu has two ways for units to leave. Declared burn opcodes were used 288 times, all of them 0x25, between blocks 438,725 and 487,748. Separately, unrouted units default to the last output, the custody drift CoinSpark also shows. The study says supply deltas must keep the two kinds of burn apart. ## Findings of the August review The BTI protocol review of 2026-08-29 found that Colu and Open Assets answer one question in opposite ways. When a protocol-unaware spend destroys the colour, Open Assets declares the claim None, zero in every book, while Colu declares it riding and keeps its full measured Book B. Those burn claims carried 38,748,707 bytes, 25.16 % of Colu's Book B. Ruling U4 says such a question should be answered once, in the shared layer. The review also corrected the token table. Its note says five transactions co-carry Colu's marker with another protocol's; the review found four, and they are not Colu: 3-byte payloads with zero claims. ## Live figures Colu holds 0.15 GB in Book A, 0.02 % of the chain's bytes and 0.12 % of all Book A, with 0 bytes in Book C. The books count 54,888 assets across 412,068 operations, from block 364548 to 972125 (as of block 972,299, 2026-10-20 09:30:48 UTC). The BTI handoff of 2026-08-16 recorded 138 MB for Colu in the books then covering blocks 0 to 779,999. Sources: - Blockspace Holdings records - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Counterparty XCP assets, the first blockspace tokens (2014), with Stamps and Counters as subsets: one asset, one claim, however many sources sight it. URL: https://blockspace.wiki/protocols/counterparty/ [XCP assets](https://blockspace.wiki/glossary/xcp-asset/) are the assets of the [Counterparty](https://blockspace.wiki/glossary/counterparty/) ledger. [BTI](https://blockspace.wiki/glossary/bti/)'s token table calls them "the first blockspace tokens (2014)" and counts XCP itself as one. Each asset's identity is its own immutable id in Counterparty's ledger. Three subsets sit inside the family: stamp assets, [counters](https://blockspace.wiki/glossary/counter/), and the older counters-proto assets. ## How Counterparty writes to Bitcoin The block.space data-types reference lists Counterparty's classic channels as small [OP_RETURN](https://blockspace.wiki/glossary/op-return/) messages, ARC4-encrypted, and [bare multisig](https://blockspace.wiki/glossary/bare-multisig/) outputs; its earliest channel was fake P2PKH data outputs. Counterparty Core v11.0.0 added a [taproot envelope](https://blockspace.wiki/glossary/taproot-envelope/), active from block 902,000. The message then travels in the reveal's input-0 [witness](https://blockspace.wiki/glossary/witness/), and the output side holds only the literal `CNTRPRTY` marker. The same release removed P2SH encoding. ## How BTI attributes its bytes The counterparty [metaprotocol adapter](https://blockspace.wiki/glossary/metaprotocol-adapter/) reads Counterparty Core, the asset ledger of issuances, sends, dispenses and destroys. Its trust is derived. The stamps, counters and countersproto adapters are further sources on the same tokens. Ruling B36(1) makes them sightings of one asset: "one asset, one claim, however many sources sight it", and the best available description wins. Two sources on one token collapse to one claimant; they never divide the bytes. Some case law: - A dispense row designates the payment outputs as protocol outputs, and the ordinary counterfactual then decides (B22/B28(1)). Failed dispenses keep their claims (B36(2)). - SRC-721 is a [label](https://blockspace.wiki/glossary/label/) on an XCP asset, never a second claimant (B36(3)). - A pure-ledger send has Book C of 0, honestly: the token's bytes are its operations. ## Stamps A [Bitcoin Stamp](https://blockspace.wiki/glossary/bitcoin-stamp/) is an XCP asset whose description carries a file, catalogued by the stamps adapter. The stamp number is a label. Case 15 of the BTI case studies is Stamp #0 (block 779,652): a 534-byte transaction whose three bare multisig outputs hold a base64 PNG of 85 bytes. Both sources sight one asset, so n = 1, and its entry is content 116, structure 418, overhead 0. The adapter counts each carrier's full 114-byte output and marks as content only the file's own bytes inside the fake keys. A reissuance of a stamp asset carries no file, so its Book C is 0 while Books A and B still claim (B7). In the July 2026 measurement run, Stamps measured 1.008 bytes per vbyte, "essentially no discount, deliberately". The same run measured the switch to [OLGA](https://blockspace.wiki/glossary/olga/) (chunked P2WSH outputs): 1.84 times cheaper per content byte and 2.96 times cheaper per file byte, a mean file growing from 366 B to 3,421 B, and 98.3 % adoption within 2,500 blocks. ## Counters A counter is "a numbered file event": the description of a Counterparty asset, recorded by a valid issuance or [fairminter](https://blockspace.wiki/glossary/fairminter/) deploy, whose bytes reached the chain inside the taproot envelope. Counterparty supplies identity, ownership, naming, transfer and the content; the counters protocol adds nothing on chain and only numbers the qualifying events, from #0 (XDUALS, block 902,005). Explore them at [counters.gallery](/projects/counters.gallery/); counters.fun pairs them with XCP pools ([counters.fun](/projects/counters.fun/)). The case studies show both envelope styles. In case 8, the [counterparty + ord](https://blockspace.wiki/glossary/counterparty-plus-ord/) envelope is also an inscription, so the asset and the sat are two tokens and divide the 290-byte transaction (129.5 and 160.5 bytes). In case 9 the native envelope is invisible to ord, so the asset is the sole claimant of all 302 bytes. Two documents disagree on what the counters unit writes. The BTI protocol review of 2026-08-29 found that it opens no claims of its own by design: under B36(1) it adds its span and content regions to the surviving Counterparty claim, so it never shows as a source on the family. A finding of 2026-10-18 says the unit has written no claims and no contributions in any window since its log begins (2026-08-30), so no "Counters" sub-item exists, while the counters' bytes are all in the books as Counterparty claims. Most of its 163 refusals are envelopes it could not decode. As of 2026-10-20 the question is open. ## Findings of the August review The same review recorded two population-level facts. Every 2014 proof-of-burn that created XCP attributes zero bytes (2,547 claims, 582,126 bytes judged carriage), because the burn rows carry an empty message; the review notes that a dispense trigger is ruled the other way. And one asset, ORDIPEPE, held 18.07 % of the family's Book A then, almost all of it from dispense triggers; the one the review traced was a 100-input transaction whose only output paid the dispenser. The review calls this lawful. ## Live figures Counterparty assets hold 1.21 GB in Book A, 0.16 % of the chain's bytes and 0.91 % of all Book A, and 0.06 GB in Book C. The books count 277,435 assets across 4,121,036 operations, from block 278319 to 972299 (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: measurements · https://block.space/docs/measurements - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md - Counters notes · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/notes.md - The project list at block.space/projects · https://block.space/projects - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # EPOBC Colours written into the nSequence field every input already has: zero carrier bytes, the limiting case of the free-ride index. URL: https://blockspace.wiki/protocols/epobc/ EPOBC is a coloured-coin protocol whose tokens, in [BTI](https://blockspace.wiki/glossary/bti/)'s token table, are EPOBC colours, each identified by a colour id. BTI is its indexer: it is a [native protocol](https://blockspace.wiki/glossary/native-protocol/), read by BTI's own epobc decoder. The token table records that "a licensed bank issued 100k EUR on it". ## How EPOBC writes to Bitcoin EPOBC writes its message into a field that already exists: an input's nSequence, four bytes that every input carries. The data-types reference credits the design to ChromaWay (2014): a 6-bit tag in the low bits (genesis `0b100101` = 37, transfer `0b110011` = 51), plus padding rules on output values. It calls it "the canonical 'zero extra bytes' colored-coin design", and notes that modern uses of the field (RBF signalling, BIP 68 relative locks) make such tagging prone to collisions today. Because the field is mandatory, the reference says BTI should attribute zero incremental bytes to the channel. This is an [appropriated field](https://blockspace.wiki/glossary/appropriated-field/). ## How BTI attributes its bytes The decoder runs in replay mode over only the 8,694 tagged blocks. Its selection follows the writer's rule (B43): the protocol fact on record is "nSequence bits 0–11 only". Case 20 of the BTI case studies is the landmark bank issuance at block 354,320: a 10,000,000-unit genesis, 100,000 EUR in cents, five weeks before LHV Pank's wallet launch. The 436-byte transaction has two inputs and two outputs. Input 0's nSequence is 37. The census records the carrier as a 4-byte span with zero incremental bytes. The claim is a [dedicated](https://blockspace.wiki/glossary/dedicated/) mint, and its regions cover the whole transaction, with the four nSequence bytes as the carrier span. A supply delta of +10,000,000 is written at that height. The books read content 0, structure 436, overhead 0, so Book A = Book B = 436 bytes, and the fee share is the whole 4,400 sats. The case study's "instructive number" is "span = 4 B, incremental cost = 0 B": zero marginal bytes is not zero span. The books price the whole dedicated transaction, while the census records that the carrier itself added nothing. ## Zero carrier bytes The measurements document gives EPOBC's finding from the July 2026 measurement run: six years of operation, bank-issued, colour encoded entirely in the input-0 nSequence field. Its free-carrier fraction is 1.0 and the incremental cost of carrying the token is zero bytes, "the limiting case of the free-ride index". It "falsifies 'a blockspace token must consume blockspace' in its naive form". EPOBC consumed the span of the transactions it colours, but the marginal bytes due to the colouring are none. Under Book B, in the document's words, it claims essentially nothing; under Book A it claims whole transactions. "The two books give opposite answers, and both are correct", which is the case the three-book design exists for. The two documents differ on Book B. The July measurement says it claims essentially nothing; case 20, worked on the books in August 2026, gives the dedicated genesis a Book B of the whole 436 bytes. The case studies explain the mechanism in finding F4: under B30(1)(iii), the funding remainder of a dedicated sole claimant enters structure, so its Book B is the transaction's size. See [the three books](/concepts/the-three-books/) and [carriage and the free-ride index](/concepts/carriage-and-the-free-ride-index/). ## Findings of the August review The BTI protocol review of 2026-08-29 found EPOBC's last height, 614,796, to be a landmark decision rather than an observation: 3,117 nSequence-tagged transactions above it were refused as residue before the colour test ran, while 986 EPOBC-coloured outputs were still live. It also found that the decoder cannot see EPOBC's own decay, since an untagged spend of a coloured output is never walked, so its supply is an unstated upper bound. ## Live figures EPOBC holds 13,870,895 bytes in Book A, and 0 in Book C. The books count 131 colours across 19,735 operations, from block 288200 to 614796 (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: measurements · https://block.space/docs/measurements - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Mezcal Runes-lite JSON mezcalstones in OP_RETURN from block 898,750; BTI's decoder transcribes the author's reference indexer, quirks and all. URL: https://blockspace.wiki/protocols/mezcal/ Mezcal is a fungible token protocol. In [BTI](https://blockspace.wiki/glossary/bti/)'s token table its tokens are Mezcals, each identified by a mezcal id `block:tx`. The name is an alias, unique by protocol rule. The genesis mezcal is `mezcal/1:0`, named `taco`. BTI is its indexer: it is a [native protocol](https://blockspace.wiki/glossary/native-protocol/), read by BTI's own mezcal decoder. ## How Mezcal writes to Bitcoin The roster describes Mezcal as "runes-lite JSON mezcalstones": JSON messages in an [OP_RETURN](https://blockspace.wiki/glossary/op-return/), with etchings, mints and edicts shaped like those of [Runes](https://blockspace.wiki/glossary/rune/). Its genesis block is 898,750. The genesis mezcal at `1:0` is hardcoded: `taco`, with an amount of 1e10 per mint and a cap of 21,000 mint events. The ruleset records that 25,919 mints of it are on chain, so the cap decides about 5,000 of them. Mints can be priced: every price term must be paid to its `pay_to` in full, and a flex mint (amount 0 with a price) mints the amount received divided by the price. ## How BTI attributes its bytes The decoder is a transcription of the protocol author's reference indexer (https://github.com/bitapeslabs/mezcal, pinned to one revision), the same stance BTI takes with Runes, where it transcribes ord's rune updater. Its JavaScript coercion quirks are ported as the writer's rule (U2): - amounts parse as JavaScript BigInt, so `"0x10"` is 16; - the symbol is one code point; - the mezcalstone schema is strict, so an unknown key makes it a [cenotaph](https://blockspace.wiki/glossary/cenotaph/); - any unparseable first OP_RETURN in a transaction that carries mezcal balances is a cenotaph that burns them; - mint ids are normalised through `Number()` (`"01:0"` becomes `"1:0"`), but edict ids are not. The roster says every block is walked, because balances drift through plain spends, and unrelated OP_RETURNs can burn them. The first mezcal-shaped carrier, at block 898,685, came 65 blocks before genesis and indexes as nothing. Mezcal entered the roster on 2026-08-11 through ruling U3's transferability gate. The gate's evidence: a mint of 1e10 `taco` onto an output at block 898,763, then an edict at 898,768 that spends it, clamps its 2e10 ask to the 1e10 available, and lands it on a different script. ## Findings of the August review The BTI protocol review of 2026-08-29 confirmed the cap. 4,981 mints hit the closed `taco` cap within 625 blocks of genesis and were recorded as [attempts](https://blockspace.wiki/glossary/attempt/), within 19 rows of the ruleset's estimate. Other attempts were 6 cenotaphs, 3 taken names and 1 unknown token. The review found Mezcal alive but sparse, with its last claim then at block 964,603. It also found 11 of 49 mezcal token identities, all etchings between blocks 898,778 and 901,414, with no claim, no attempt and no aggregate. Under rules U2 and U5 a token with no grounded record should not exist; the review judged the mechanism probable, an etching that registers its token before an early return. ## Live figures Mezcal holds 6,561,376 bytes in Book A and 0 in Book C. The books count 38 mezcals across 29,807 operations, from block 898750 to 972033 (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Omni The Mastercoin-lineage ledger, TetherUS included. BTI decodes Class C messages in OP_RETURN itself; a ledger token's bytes are its operations. URL: https://blockspace.wiki/protocols/omni/ An [Omni property](https://blockspace.wiki/glossary/omni-property/) is a token of the Omni protocol, of the Mastercoin lineage. BTI's token table names it by its property id, assigned by replaying the protocol. A human name is an alias: TetherUS is property 31, and BTI writes it as `omni/31`. ## How Omni puts data on Bitcoin The data-types reference lists three Omni channels over time: - **Class A** (named in the reference as Mastercoin Class A): data in fake pay-to-pubkey-hash addresses, 20 bytes per output, with 546 sats of dust each. The reference calls the general trick undetectable by construction. - **Class B**: data in fake public keys inside bare multisig outputs, which stay in the UTXO set until spent. - **Class C**: a message in an OP_RETURN output. Case 17 of the BTI case studies decodes a Class C simple send at block 560,000. The OP_RETURN output is 31 bytes, its script 22 bytes, beginning with the marker `6f6d6e69` ("omni"). The payload reads version 0, type 0 (simple send), property 31 (TetherUS), and an amount of 738,052,430,000 base units. A second, 546-sat output is the reference output: the recipient. ## How BTI attributes the bytes Omni is a [native protocol](https://blockspace.wiki/glossary/native-protocol/): BTI's own decoder reads the chain, and there is no external indexer. The decoder reads **Class C only**. The adapters table says that is 99.67 % of Omni's bytes. Ruleset v1 names Class B as a coverage gap (B4b). omni-core is on the watchlist; deploying it would move Omni from native toward reconciled. Omni carries no file. The books document gives it as the pure-ledger shape: "content 0 honestly; structure and overhead carry the backing — a ledger token's bytes are its operations". The case studies show both sides of the dedication test: - **Dedicated** (case 17, block 560,000). Every output serves the send or is change, so the claim covers the whole 257-byte transaction: content 0, structure 257, overhead 0, and the whole 50,000-sat fee. The case reconciled with the live database to the byte. - **All riding** (case 21, block 550,000). A TetherUS send in a transaction that also paid 48,625 sats that no Omni rule required. The [dedicated](https://blockspace.wiki/glossary/dedicated/) test answers no, so the claim keeps only its frame, the reference output and its carrier: 75 bytes. With no dedicated claimant, the other 328 bytes "stay with the transaction", bought by nobody. In the ruleset's words, "every claimant aboard was a passenger". ## Live figures The family's books (as of block 972,299, 2026-10-20 09:30:48 UTC): | measure | value | |---|---| | Book A | 6.66 GB | | share of the chain's bytes (Book A) | 0.86 % | | share of all Book A bytes | 4.98 % | | properties | 404 | | operations | 19,432,030 | | first height | [not measured](https://blockspace.wiki/glossary/not-measured/) | | last height | 971614 | The protocols API gives no first height for Omni, so this page says not measured rather than zero. On 2026-10-18 the [heaviest tokens board](https://blockspace.wiki/glossary/heaviest-tokens-board/) placed `omni/31` third of all tokens by Book A, at 6.5 GB. It showed unnamed: the board had no label for it. ## Holders The leaderboard cannot place Omni's bytes on addresses. Read on 2026-10-20, its coverage table listed Omni as not measured, because Blockspace Holdings keeps no Omni ledger. ## Measured findings - In the July 2026 measurement run, Omni had a bytes:vbytes ratio of 1.0142, "pre-segwit, as expected": almost no [witness discount](https://blockspace.wiki/glossary/witness-discount/). Inscriptions measured 3.374 and runestones 1.0000. - The same run lists Omni, with Counterparty and early OP_RETURN, as what was on the chain at height 600,000, when data payload was 9.2 % of block bytes. Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: measurements · https://block.space/docs/measurements - block.space protocols API · https://block.space/api/protocols - block.space leaderboard coverage API (holders measured per protocol) · https://block.space/api/leaderboard/coverage Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # OP-20 BRC-20's JSON shape on OP_RETURN plus a required credit address; no indexer has ever existed, so BTI's replay is the record. URL: https://blockspace.wiki/protocols/op20/ OP-20 is a fungible tick ledger. In [BTI](https://blockspace.wiki/glossary/bti/)'s token table its tokens are OP-20 ticks, each identified by the case-folded tick, written `op20/…`. BTI is its indexer: it is a [native protocol](https://blockspace.wiki/glossary/native-protocol/), read by BTI's own op20 decoder. The roster records that no indexer for it has ever existed, so BTI's replay is the record (ruling B32). ## How OP-20 writes to Bitcoin OP-20 uses BRC-20's JSON shape, but in an [OP_RETURN](https://blockspace.wiki/glossary/op-return/) rather than an inscription, and with one extra field. Its mint carries `add`, a credit address, and that field is required. The ruleset gives the reason: OP-20 mints were paid over Lightning through a bot, so the transaction's signer is not the minter. The launch coverage it quotes said there was "no official index or transaction transfer tool available". ## How BTI attributes its bytes The ruleset describes the decoder as the same machine as BTI's BRC-20-on-OP_RETURN decoder, with that one protocol fact added: `add` is the mint's credit instruction. The shared machine is deploy-gated (a mint naming an undeployed tick is [residue](https://blockspace.wiki/glossary/residue/)). A transfer debits the first input's previous output script and credits the minimum-value output that is not an OP_RETURN, and the last mint is clamped to what remains. OP-20 entered the roster on 2026-08-11 through ruling U3's transferability gate, with this chain of evidence: 1. a deploy at block 895,638; 2. a mint at 895,843 that credits its `add` address; 3. a transfer of 500 to the same holder at 896,654; 4. a transfer of 300 to a different script at 896,662, within the balance. ## Findings of the August review The BTI protocol review of 2026-08-29 found OP-20 quiet since block 959,972, with its decoder still running. Its top three ticks (`op_return`, `op_pepe` and `oink`) were at their deploy caps, which the review called "a sufficient explanation for a mint-only micro-protocol going silent". It also found a blind spot of known size. The OP-20 and BRC-20-on-OP_RETURN decoders choose blocks by the census marker `{"p`. A block whose only JSON OP_RETURN starts with a space after the brace, `{ "p`, is never fetched. That leaves 441 carriers in 16 blocks out of reach. Whether any of them is a real record the census cannot say, so the review recorded it as a blind spot, not a proven loss. ## Live figures OP-20 holds 1,722,430 bytes in Book A and 0 in Book C. The books count 99 ticks across 7,104 operations, from block 895541 to 959972 (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Open Assets An asset protocol of coloured outputs that BTI decodes itself with a coloured-UTXO walk; B/A 0.72 in the July 2026 measurement run. URL: https://blockspace.wiki/protocols/open-assets/ Open Assets is a ledger-protocol family in [BTI](https://blockspace.wiki/glossary/bti/)'s token table. Its tokens are Open Assets assets, each identified by an issuer-scoped asset id. BTI is its indexer: it is a [native protocol](https://blockspace.wiki/glossary/native-protocol/), decoded by BTI's own openassets decoder with no external service between. ## How Open Assets writes to Bitcoin The sources describe one carrier: an [OP_RETURN](https://blockspace.wiki/glossary/op-return/) output beginning with the Open Assets marker `4f410100`. In case 18 of the BTI case studies, an issuance's marker output is 49 bytes, and its metadata is a URL (`u=https://cpr.sm/…`, a Coinprism definition). The asset's definition lives at that URL, not on chain, so the issuance carries no content region. ## How BTI attributes its bytes The decoder runs in replay mode, a coloured-UTXO walk: the state it keeps to process each next block includes the coloured outpoints. The roster records one hard constraint: "a mid-chain cold start misclassifies 52–92% of OA txs". Case 18 is the transaction that forced regions into BTI's schema (ruling A2). One 423-byte transaction is an Open Assets issuance with CoinSpark units drifting through it on CoinSpark's default route. The issuance is [dedicated](https://blockspace.wiki/glossary/dedicated/) and claims the whole transaction; the CoinSpark claim declares only carrying structure, with dedication None. The two overlap on some atoms and not on others, and no single number per claim can express that. Divided by atom, Open Assets takes 253 bytes in Book B and the CoinSpark claim 170. The CoinSpark bytes become [carriage](https://blockspace.wiki/glossary/carriage/), so Open Assets' Book A is 253, not 423, even though it was the transaction's only dedicated claimant. The case studies call this the canonical mixed-transaction fixture, "the single easiest place for a rebuild to 'fix' conservation in the wrong direction". The token table records how Open Assets decays: "by total uncolouring". The BTI protocol review of 2026-08-29 tested that decay label against the data and refuted it: 78.2 % of units had uncoloured, but only 0.89 % of assets, and 114,602 coloured outputs were still live. The same review found Open Assets and Colu answering one question in opposite ways: when a protocol-unaware spend destroys the colour, Open Assets declares the claim None (zero in every book) while Colu declares it riding. ## The free-ride index In the July 2026 measurement run, Open Assets measured **B/A = 0.72**: in the measurements document's words, "29% of its inclusive claim is riding on payments that were happening anyway". The [free-ride index](https://blockspace.wiki/glossary/free-ride-index/) is Book B ÷ Book A, the share of a family's inclusive claim that is its own measured structure. See [carriage and the free-ride index](/concepts/carriage-and-the-free-ride-index/). The August review's own table read Open Assets' B/A as 0.9992 on the books then covering up to block 959,999. The two readings come from different runs, and the July figure is the one the measurements document publishes. ## Live figures Open Assets holds 0.12 GB in Book A, 0.02 % of the chain's bytes and 0.09 % of all Book A. Its Book C is 0 bytes. The books count 55,179 assets across 260,766 operations, from block 299220 to 972256 (as of block 972,299, 2026-10-20 09:30:48 UTC). The BTI handoff of 2026-08-16 recorded 119 MB for Open Assets in the books then covering blocks 0 to 779,999. Sources: - Blockspace Holdings records - block.space docs: measurements · https://block.space/docs/measurements - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Ordinal Sats The sat family: inscribed sats, bitmaps, sat names and CAT-21 sats. How ord binds files to sats, how BTI books them, and the family's live share. URL: https://blockspace.wiki/protocols/ordinal-sats/ [Ordinal Sats](https://blockspace.wiki/glossary/ordinal-sats/) is the display name of the sat family on block.space. It was renamed from "Individual Sats" on 2026-10-19, and the key stays `sat` in every URL, API field and database row. BTI's token table calls the sat "the base token": every sat is separately ownable and moves with its output, and its identity is ord's numbering, the [ordinal number](https://blockspace.wiki/glossary/ordinal-number/). ## How the data reaches the chain Most of the family's bytes are [inscriptions](https://blockspace.wiki/glossary/inscription/). ord binds content to a sat through a witness [envelope](https://blockspace.wiki/glossary/envelope/): an `OP_FALSE OP_IF … OP_ENDIF` block inside a taproot script-path spend, marked `6f7264` ("ord"). The data-types reference gives the reasons the channel won. Each data push is capped at 520 bytes, so content is chunked, but a tapscript leaf has no script-size limit, so one leaf can hold megabytes. Witness bytes weigh one weight unit each, a quarter of base bytes. An inscription takes two transactions: a commit and a [reveal](https://blockspace.wiki/glossary/reveal-transaction/). [CAT-21](https://blockspace.wiki/glossary/cat-21/) uses no envelope. Its mint is any transaction with `nLockTime = 21`, a field every transaction already has. ## What BTI counts as the token Under ruleset v1's rule U3, a token is "exactly what can be transferred by itself, proven on chain". An inscription is content, not a token: the inscribed sat is the token that claims the bytes (case law B14). The family has these parts in the token table and on block.space: | sub-item | what narrows the sat | catalogued by | |---|---|---| | Ordinal Inscriptions | ord bound content to it | the ord adapter (module inscriptions) | | [Bitmaps](https://blockspace.wiki/glossary/bitmap/) | the inscription is a district claim; the district number is a label | the opi-bitmap adapter | | [Sat names](https://blockspace.wiki/glossary/sat-name/) | the inscription names the sat; the name is a label | the opi-sns adapter | | [CAT-21](https://blockspace.wiki/glossary/cat-21/) sats | an `nLockTime = 21` mint; the cat is a label on the first sat of output 0 | the ord adapter (module cat21) | Rarity is not a sub-item. The owner ruled on 2026-08-02 that rarity is a property of a sat, not another token. Uninscribed sats would arrive with the positional appendix, which the token table lists as deferred. The ord adapter's trust is "definitional" in the [trust triad](https://blockspace.wiki/glossary/trust-triad/): ord's ruleset is the protocol for which sat an inscription is bound to. A [second-source adapter](https://blockspace.wiki/glossary/second-source-adapter/), opi-ord, sights the same sats through [OPI](https://blockspace.wiki/glossary/opi/). It writes no bytes and cannot create a token. As everywhere in BTI, the bytes come from the raw chain, never from ord. ## How the bytes are booked An inscription reveal is usually dedicated to its sat, and the sat's claim covers the whole transaction. The commit that enabled it is an [enabler](https://blockspace.wiki/glossary/enabler/): its bytes join the pool and reach [Book A](https://blockspace.wiki/glossary/book-a/) only. Case 7 of the BTI case studies is a 3.9 MB jpeg at block 960,962. Its body is 3,888,767 bytes (Book C), the reveal is 3,911,459 bytes (Book B), and the 419-byte commit brings Book A to 3,911,878. A sat often shares a reveal with other tokens. In case 10, the first BRC-20 mint, the sat and the tick `ordi` divide the envelope they share. The sat takes 284.5 bytes of Book B and all 71 bytes of Book C, because the mint JSON is the sat's content. Case 3 adds a rune on the same reveal, so three tokens share it. Sending an inscribed sat is a [sighting](https://blockspace.wiki/glossary/sighting/). ord records the new location, but the byte difference is zero, so the send is judged [carriage](https://blockspace.wiki/glossary/carriage/) and adds nothing to the books (U5). A marketplace sale has no record in the protocol, so it stays unattributed, an understatement the ruleset accepts on purpose. The [largest inscriptions](https://blockspace.wiki/glossary/largest-inscriptions-board/) ranks inscriptions by [Book C](https://blockspace.wiki/glossary/book-c/), the file's own bytes. A [delegate inscription](https://blockspace.wiki/glossary/delegate-inscription/) is ranked by the few hundred bytes it bought, not the content it shows. ## Live figures The family's books (as of block 972,299, 2026-10-20 09:30:48 UTC): | measure | value | |---|---| | Book A | 56.13 GB | | Book C | 33.44 GB | | share of the chain's bytes (Book A) | 7.22 % | | share of all Book A bytes | 41.97 % | | tokens (sats with claims) | 125,519,930 | | operations | 129,015,098 | | first height | 767430 | The protocols API splits the family by claim source. Read on 2026-10-20 (books at block 972,199), the inscriptions source covered 125,448,674 sats, sat names 4,956,536, bitmaps 972,116 and CAT-21 63,668. The sub-items overlap, because one sat can be sighted by several sources, so they do not add up to the family total. ord itself counts 128,169,401 inscriptions, 472,043 of them [cursed](https://blockspace.wiki/glossary/cursed-inscription/) (as of block 972,304, 2026-10-20 10:17:29 UTC). On 2026-10-19, 582 of the 100,000 largest inscriptions had no sat binding below the export ceiling, which block.space shows as "not yet attributed". Holders: read on 2026-10-20, the leaderboard's coverage table placed 99.88 % of the family's Book A on 3,034,207 addresses (see [holders](/concepts/holders/)). ## Measured findings In the July 2026 measurement run, inscriptions had a bytes:vbytes ratio of 3.374. The measurements page reads this as paying for about 30 % of what they consume, the largest [witness discount](https://blockspace.wiki/glossary/witness-discount/) measured. The same run found that data payload peaked at 45.4 % of block bytes at height 833,000, during the inscription era, and fell to 31.9 % by 850,000 after runes moved to OP_RETURN. Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: measurements · https://block.space/docs/measurements - block.space docs: rankings · https://block.space/docs/rankings - block.space protocols API · https://block.space/api/protocols - block.space leaderboard coverage API (holders measured per protocol) · https://block.space/api/leaderboard/coverage - ord /status (the blockspace.to ord server) · https://blockspace.to/status Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC; protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Pipe A September-2023 OP_RETURN token protocol, the Runes precursor, with art in tapscript; no indexer has ever existed, so BTI's replay is the record. URL: https://blockspace.wiki/protocols/pipe/ Pipe is a fungible token protocol. In [BTI](https://blockspace.wiki/glossary/bti/)'s token table its tokens are Pipe tokens, identified by the ticker under Pipe's rules. BTI is its indexer: it is a [native protocol](https://blockspace.wiki/glossary/native-protocol/), read by BTI's own pipe decoder, and the roster records that "no indexer has ever existed". ## How Pipe writes to Bitcoin BTI's Pipe attribution study (2026-08-04) describes Pipe as the Runes precursor: a September-2023 [OP_RETURN](https://blockspace.wiki/glossary/op-return/) token protocol with a public specification, now dormant. Its carrier is an OP_RETURN whose first push is the single byte `0x50`, ASCII "P", the smallest protocol magic on the roster. The study names three record families: - **PIPE**: fungible deploy, mint and transfer records, in the OP_RETURN; - **PIPE|ART**: an `image/png` body revealed in tapscript, in the [witness](https://blockspace.wiki/glossary/witness/); - **PIPE|DMT**: a mint-on-block variant, in the OP_RETURN. Because the fungible layer is in base bytes and the art is in witness bytes, the study measured Pipe at 1.873 bytes per vbyte, "the roster's most witness-subsidised token protocol" of those it had studied in full. The art is where Pipe's Book C comes from: the study estimated about 41 MB of real PNG bodies, each claimed by one token. ## How BTI attributes its bytes The decoder runs in replay mode. With no indexer anywhere, the roster says "conservation is the only oracle". Some points from the study: - **Identity needs the id.** A token's ref is `pipe/:`. Pipe lets the same ticker be deployed more than once, and the `id` keeps them apart. - **Byte order from the chain.** The ticker travels as an integer, rendered as letters in bijective base 26, packed big-endian. The specification does not say so; the order had to be measured on chain, and the study calls it the highest-risk fact in the design. - **A one-byte marker.** Every Pipe record shares the marker `50`, so the marker finds the transactions and the decoder re-reads each one. For PIPE|ART, the census's ord-shaped parser reports a body of 2 bytes where the body is about 304, so Book C cannot be read from the census alone. - **Residue from the start.** The study found that Pipe's first transfer is invalid, because it spends a pre-protocol output: a protocol whose opening move is a failed operation. ## Findings of the August review The BTI protocol review of 2026-08-29 checked whether each family's end date was a real stop or an artefact of the books' horizon. Of the five families it audited, Pipe was the one genuinely dead: one carrier above block 950,155, correctly filed as not Pipe. ## Live figures Pipe holds 0.08 GB in Book A, 0.01 % of the chain's bytes and 0.06 % of all Book A, with 0.04 GB in Book C. The books count 56,122 tokens across 203,418 operations, from block 809608 to 950155 (as of block 972,299, 2026-10-20 09:30:48 UTC). The BTI handoff of 2026-08-16 measured 44.7 MB for Pipe in claim regions over blocks 801,993 to 817,999. Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Runes Fungible tokens whose messages, runestones, ride an OP_RETURN output. BTI decodes them itself; ord is only its audit oracle. URL: https://blockspace.wiki/protocols/runes/ A [rune](https://blockspace.wiki/glossary/rune/) is a fungible token of the Runes protocol. BTI's token table names it by its rune id, the block and transaction of its [etching](https://blockspace.wiki/glossary/etching/) (`block:tx`); the name is an alias. UNCOMMON•GOODS is rune `1:0`, which the table calls "rune #0". ## How runes put data on Bitcoin A rune's messages are runestones, carried in an OP_RETURN output tagged `OP_13`. The data-types reference describes the channel. An OP_RETURN output is provably unspendable and Bitcoin Core never puts it in the UTXO set. Its bytes are base bytes, four weight units each, so they get no [witness discount](https://blockspace.wiki/glossary/witness-discount/). The reference says OP_RETURN pays four times the witness price per byte and wins for small messages, where single-transaction atomicity matters. It lists Runes as one of those. A runestone is a list of integers. Case 1 of the BTI case studies decodes one: a pointer and one [edict](https://blockspace.wiki/glossary/edict/), which moves 10,000 raw units of LUNARBITS•ON•THE•MOON to output 1. The whole carrier is a 14-byte script. The runestone can also carry an etching, which creates a rune, or a mint of an existing rune. ## How BTI attributes the bytes Runes is a [native protocol](https://blockspace.wiki/glossary/native-protocol/). BTI's own runes decoder reads the chain from bitcoind. It is a transcription of ord's rune updater, and it keeps a balance state machine by replay. ord's decode and rune endpoints are used only to cross-check. The adapters table says runes "does NOT belong under the ord adapter". It is the one native unit allowed a clamp on ord, which only stops the pass from running ahead of the oracle. The case studies show the main shapes: - **A dedicated transfer** (case 1, block 961,197). Every output serves the rune or is change, so the claim is [dedicated](https://blockspace.wiki/glossary/dedicated/) and covers the whole 408-byte transaction: content 0, structure 408, overhead 0. The edict's own 8 bytes are a named sub-span of the carrier output. - **Two protocols in one runestone** (case 2, block 911,180). One 30-byte OP_RETURN mints UNCOMMON•GOODS and carries an Alkanes [protostone](https://blockspace.wiki/glossary/protostone/). The rune and the alkane each take half of the 371 bytes, 185.5 bytes each. - **A rune on an inscription** (case 3, block 905,952). A rune mint, a BRC-20 mint and an inscribed sat share one 367-byte reveal. The rune and the sat take 171 bytes each, and the tick takes 25. - **A [cenotaph](https://blockspace.wiki/glossary/cenotaph/) that still etches** (case 11, block 840,101). A malformed runestone still created INSCRIBERUNES, with no terms. The claim is labelled `mint`, and the riding gate keeps two unrelated outputs out of its books. - **A failed mint of a rune that does not exist** (case 12, block 840,000). Someone minted `8400000:1`, a typo. ord records nothing for a mint of an unknown rune, so there is no claim, only a [residue](https://blockspace.wiki/glossary/residue/) row: measured demand, never backing. - **A rune drifting through a plain spend** (case 16, block 840,109). Runes on the inputs moved by the protocol's default route, with no runestone at all. That is a [sighting](https://blockspace.wiki/glossary/sighting/), judged [carriage](https://blockspace.wiki/glossary/carriage/): zero in every book. Ruleset v1's fact table adds one rule for runes: an edict or pointer aimed at a provably unspendable output is a burn. The case studies found no reachable cenotaph that exercises the burn arm by hand, and left it to a fixture drawn from the replay (finding F6). Runes carry no file, so their [Book C](https://blockspace.wiki/glossary/book-c/) is 0 honestly. A rune's backing is its structure and overhead. ## Live figures The family's books (as of block 972,299, 2026-10-20 09:30:48 UTC): | measure | value | |---|---| | Book A | 33.05 GB | | share of the chain's bytes (Book A) | 4.25 % | | share of all Book A bytes | 24.71 % | | tokens | 216,402 | | operations | 249,889,795 | | first height | 840000 | ord, as the audit oracle, counts 216,409 runes (as of block 972,304, 2026-10-20 10:17:29 UTC). Two runes stand out. Read from the protocols API on 2026-10-20 (books at block 972,199), UNCOMMON•GOODS (`1:0`) had 23.87 GB of Book A across 165,758,746 book entries, and COOK•THE•MEMPOOL (`840000:65`) had 0.84 GB. The API lists both as sub-items of the family. On 2026-10-18 the [heaviest tokens board](https://blockspace.wiki/glossary/heaviest-tokens-board/) put UNCOMMON•GOODS at rank 1 of all tokens by Book A. Holders: read on 2026-10-20, the leaderboard's coverage table placed 99.95 % of the family's Book A on 1,098,444 addresses. ## Measured findings In the July 2026 measurement run, runestones had a bytes:vbytes ratio of 1.0000, "zero discount, to four decimals". Inscriptions, on the same chain in the same year, measured 3.374. The same run gives runes a place in the chain's history. Data payload peaked at 45.4 % of block bytes at height 833,000 and fell to 31.9 % at 850,000. The measurements page reads the fall as "runes replacing inscription bodies with 20-byte runestones": a more efficient protocol cut the chain's data share while the number of tokens grew, and backing per token fell. Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: measurements · https://block.space/docs/measurements - block.space protocols API · https://block.space/api/protocols - block.space leaderboard coverage API (holders measured per protocol) · https://block.space/api/leaderboard/coverage - ord /status (the blockspace.to ord server) · https://blockspace.to/status Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC; protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # SPOOL ascribe's edition registry in OP_RETURN, from 2014 to 2017: editions are tokens, pieces are labels, and fuel transactions are enablers. URL: https://blockspace.wiki/protocols/spool/ SPOOL is the protocol ascribe used to register and move editions of digital works. In [BTI](https://blockspace.wiki/glossary/bti/)'s token table its tokens are SPOOL editions, each identified by an edition id. BTI is its indexer: it is a [native protocol](https://blockspace.wiki/glossary/native-protocol/), read by BTI's own spool decoder. ## How SPOOL writes to Bitcoin Every SPOOL operation is a transaction of plain outputs plus an [OP_RETURN](https://blockspace.wiki/glossary/op-return/) that names the verb. BTI's SPOOL attribution study (2026-07-29) found two generations. - **Generation 1** (`ASCRIBESPOOL` plus a verb, from block 334,920, 2014-12-19). A federation-signed REGISTER pays one 600-sat output per edition, and a TRANSFER pays the new owner and carries `ASCRIBESPOOLTRANSFER`. There is no edition number in the message. - **Generation 2** (`ASCRIBESPOOL01` plus a verb and its arguments, from block 359,506, 2015-06-05). Outputs of 3,000 sats go to a file-hash address, a piece-hash address and the owner. The message carries an explicit edition number, so which token an operation acts on is read off the chain. The study dates the last SPOOL bytes to block 490,705 (2017-10-19). The ascribe federation fuelled holders' operations: FUEL and REPLENISH outputs funded the transactions that moved editions. ## How BTI attributes its bytes The decoder runs in replay mode; the roster notes that edition identity and the fuel graph are both path-dependent. The study proved that an edition transfers by itself, repeatedly: ten editions of one piece moved separately over three years. That makes the edition a token under ruling U3. A piece (PIECE) never moved by itself, so it is a [label](https://blockspace.wiki/glossary/label/), a notarization that claims nothing; the adapter rulings count PIECE at 53.7 % of SPOOL's bytes, correctly unclaimed. Ruling B27(1) says `LOAN` is a transfer, because custody really moves for the term. SPOOL has no burn mechanism, the study found, and no spend a wallet can make removes an edition. About 99 % of SPOOL outputs are unspent, because about 99 % of editions were never traded. ## Fuel, an enabler in the pool Case 14 of the BTI case studies is SPOOL fuel. At block 335,677 a 258-byte REPLENISH transaction paid a 20,000-sat fuel output. Three blocks later a 223-byte TRANSFER spent that output to move edition 2 of a piece. The transfer is a dedicated claim over its whole 223 bytes. The fuel transaction carries no claim of its own; it is an [enabler](https://blockspace.wiki/glossary/enabler/), so its bytes join the transfer's pool. The books read content 0, structure 223, overhead 258: Book B = 223 and Book A = 481, with both transactions' 20,000 sats of fees. The enabler's bytes reach Book A only. Only consumed fuel attributes; an unspent fuel output enabled nothing. The axiom documentation states the consequence: fuelled operations are the sole source of SPOOL's B/A spread, about 0.82 fuelled against about 1.0 elsewhere. The BTI protocol review of 2026-08-29 read SPOOL's [B/A](https://blockspace.wiki/glossary/free-ride-index/) as 0.8412 over the whole family. See [carriage and the free-ride index](/concepts/carriage-and-the-free-ride-index/). ## Live figures SPOOL holds 12,550,600 bytes in Book A and 0 in Book C: a ledger operation has no artifact body. The books count 93,692 editions across 99,089 operations, from block 334985 to 541926 (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space docs: the axiom · https://block.space/docs/axiom - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # SRC-20 and SRC-101 SRC-20 ticks written in the Stamps carriers, and SRC-101 names, both catalogued by the stamps adapter. URL: https://blockspace.wiki/protocols/src-20/ SRC-20 is a fungible tick ledger written in the same output-side carriers as [Stamps](https://blockspace.wiki/glossary/bitcoin-stamp/). SRC-101 is a name protocol from the same indexer. [BTI](https://blockspace.wiki/glossary/bti/) measures them as two families, `src20` and `src101_name`. ## How SRC-20 writes to Bitcoin The data-types reference gives the "direct" SRC-20 encoding, citing stampchain's specification. The payload is a 2-byte big-endian length, the lowercase prefix `stamp:`, then JSON. The whole is ARC4-encrypted with the first input's funding txid, byte-reversed, as the key. The ciphertext fills the first two key slots of each 1-of-3 [bare multisig](https://blockspace.wiki/glossary/bare-multisig/) output, 31 usable bytes per fake key and 62 per output. A decoder collects those slots in order, strips each key's first and last byte, decrypts, checks the prefix and takes `length` bytes. Stamps from before block 796,000 ride Counterparty issuances over the same carrier. From block 833,000 the Stamps family also writes [OLGA](https://blockspace.wiki/glossary/olga/) P2WSH chunks. Those outputs look exactly like real P2WSH, so BTI finds them from context: a Counterparty issuance in the transaction, or the SRC-20 direct pattern. The BVT document's roster calls Stamps and SRC-20 "deliberately un-prunable; the most expensive channel per byte". In the July 2026 measurement run, Stamps measured 1.008 bytes per vbyte, essentially no witness discount. ## How BTI attributes SRC-20 bytes The stamps [metaprotocol adapter](https://blockspace.wiki/glossary/metaprotocol-adapter/) adapts the stamps indexer, which decodes Counterparty's format itself and indexes stamp validity, numbering, SRC-20 ticks and SRC-101 names. Its trust is derived. Ruling B6 settles what the token is: a direct-era SRC-20 stamp number names an artifact, and the tick is the token, so demand stays queryable through the tick's operations. In the token table's words, "the tick ledger rides the stamp assets". The stamps rule for protocol outputs (B29(6)) is that they are the decoded message's destinations; a dust-value heuristic is kept as a counted fallback. A data carrier's span is the full output serialization (B30(2)/B23); in the case studies' words, the value and varint "carry the data as surely as the dust does". The indexer table records one caution for the stamps indexer: exit code 5 is a consensus failure, never force-restarted. Because every source gate fails closed, an unreachable stamps source stops the whole catalogue pass, not just its own unit. ## SRC-101 names An SRC-101 name is a token because the name itself changes hands: BTI proved 48 self-transfers on chain (B5), which is ruling U3's standing test. Each name's identity is `/`. A root is a collection, not a token, so a DEPLOY is typed non-token consumption: no claimant exists for it (U3, U5). A name expires as a supply-only burn at its mint height plus `dua` × 144 blocks, where `dua` counts days (B12). The token table puts SRC-101 in its own namespace, not under Counterparty (a taxonomy fix of 2026-08-03). ## Live figures SRC-20 ticks hold 0.56 GB in Book A, 0.07 % of the chain's bytes and 0.42 % of all Book A, with 0.08 GB in Book C. The books count 1,710 ticks across 1,433,793 operations, from block 788041 to 972298. SRC-101 names hold 1,948,985 bytes in Book A: 1,863 names across 1,961 operations, from block 871148 to 949910. Its Book C is 0 bytes (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: measurements · https://block.space/docs/measurements - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # TAP TAP ticks and DMT, catalogued through tap-reader, a mirror of Trac's feed, with two hops of derived trust. URL: https://blockspace.wiki/protocols/tap/ TAP is a fungible tick ledger. [BTI](https://blockspace.wiki/glossary/bti/)'s token table lists "TAP ticks (+DMT)" as their own category: a tick is a token, because its units transfer by themselves under the protocol's ledger rules. Each tick's identity is the tick as the source reports it. ## How TAP writes to Bitcoin BTI's TAP attribution study (2026-08-05) describes TAP, the "TRAC Alpha Protocol", as an inscribed token protocol in the BRC-20 lineage: its operations are written as ord [inscriptions](https://blockspace.wiki/glossary/inscription/), and a separate indexer decides which of them are valid. Its ledger is a namespace of tickers. DMT (Digital Matter Theory) is not a second protocol but a flag on a TAP deployment: a deploy record carries a `dmt` boolean and an element reference, and a DMT ticker lives in the same namespace as a plain one. The study measured DMT as the dominant population, with 76 to 1,415 element events per block against 1 to 3 classic mints. TAP's genesis in BTI is block 801,993. ## How BTI attributes its bytes The tap [metaprotocol adapter](https://blockspace.wiki/glossary/metaprotocol-adapter/) claims for the ticker, the same shape as BRC-20, where the tick and not the sat is the token. One adapter covers DMT too, because both share one namespace and one claim key. The rankings documentation notes that for TAP, as for BRC-20, "the content of a token is the sum of many small files". The adapter's first source was tap-reader, with derived trust at two hops: tap-reader derives from TRAC. The indexer table calls it "a mirror, not an indexer of the chain": it never reads bitcoind, and it replicates a feed that Trac's writers publish over a Hypercore swarm. The BTI handoff of 2026-08-16 calls those two hops "the weakest" trust in the roster, and describes the move to ord-tap, which indexes TAP locally from bitcoind and serves the same nine routes. By the protocol review of 2026-08-29, the claims pass was probing ord-tap as TAP's source. Either way, bytes never come from the indexer: every byte quantity comes from the raw chain through BTI's own region grammar. ## Quirks on record The handoff records three facts about this source. - **One read per record.** A list fetch costs one store read per record on the reader, so the adapter pages far below the reader's default of 500. - **The fail-closed stall.** On 2026-08-15 tap-reader timed out and the whole claims stage stopped, losing 25 hours. The source gate fails closed by design: an unreachable source is a refusal, never a zero, and there is no switch to skip one unit. - **The write pathology.** tap-reader's block downloader kept re-replicating a 755,919,070-entry feed, at 806 MB/s of writes. It was disabled on 2026-08-16; the REST routes kept serving. ## Findings of the August review The protocol review of 2026-08-29 rated one TAP finding critical. The adapter mapped the whole DMT event feed to mints and never read `prv`, the previous-owner field that separates a DMT mint from a DMT transfer. So 454.9 MB of TAP's then 1,023.5 MB of Book A (44.4 %) were dedicated mint claims on transactions with no inscription envelope at all, where the inscriptions adapter rules the same move a [sighting](https://blockspace.wiki/glossary/sighting/). The review also found TAP's Book C at 251.5 MB where the adapter header says zero, traced to a 2026-08-16 schema ruling that span-covering claims own content atoms, which had not entered the ruleset text. As of 2026-10-20, the records do not say whether these have since been fixed. ## An early measurement From claim regions over blocks 801,993 to 817,999, TAP's first 16,007 blocks, the handoff measured 95.5 MB for TAP, in 1,378,527 regions of 73 bytes each. It extrapolated about 1 GB over TAP's full life and called that a floor. ## Live figures TAP holds 1.08 GB in Book A, 0.14 % of the chain's bytes and 0.81 % of all Book A, with 0.25 GB in Book C. The books count 85,747 tokens across 3,543,422 operations, from block 801993 to 972299 (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - Blockspace Holdings records - block.space docs: rankings · https://block.space/docs/rankings - block.space protocols API · https://block.space/api/protocols Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Coverage How much of Book A the holders appendix can place on addresses, protocol by protocol: what the gap is made of, which protocols are not measured, and the checks behind the figure. URL: https://blockspace.wiki/methodology/coverage/ [BTI](https://blockspace.wiki/glossary/bti/) attributes bytes to tokens, never to addresses. To rank addresses, [the holders appendix](https://blockspace.wiki/glossary/the-appendix/) has to know who holds each token. [Coverage](https://blockspace.wiki/glossary/coverage/) is the share of [Book A](https://blockspace.wiki/glossary/book-a/) it can place on an address. The page that reports it is block.space/leaderboard/coverage; its API is https://block.space/api/leaderboard/coverage. How the appendix works is on [holders and share of backing](/concepts/holders/). ## The headline figure The coverage page, read on 2026-10-20 (appendix pass finished 09:20 UTC, bytes and holders both to block 972,199), said: > The table covers 94.6% of Book A bytes: 126 GB of 134 GB sits on 4,491,923 scripts (1034 of them non-standard, shown by script hash). The API's exact figures were 126,421,876,377 bytes placed of 133,660,401,043 in Book A, a fraction of 0.9458. The leaderboard's population on the latest reading was 4,491,923 addresses (as of block 972,199, 2026-10-20 09:22:01 UTC). ## What the gap is made of The page names three parts of the remaining bytes: - **tokens whose holders no source records**: the protocols that are not measured; - **tokens with bytes and no holder**: for example a token whose every unit sits in a spent or unresolvable output; - **holder references that match no token in the books**: their units are "in no figure on this site". ## Protocol by protocol From the same read, the largest families and the three not measured: | protocol | Book A | on addresses | covered | |---|---|---|---| | Ordinal Sats | 56.1 GB | 56.1 GB | 99.9 % | | Runes | 33.0 GB | 33.0 GB | 99.9 % | | BRC-20 | 17.5 GB | 17.3 GB | 99.1 % | | Alkanes | 11.9 GB | 11.8 GB | 99.1 % | | Omni | 6.66 GB | not measured | not measured | | ARC-20 | 4.94 GB | 4.94 GB | 100.0 % | | Counterparty | 1.21 GB | 1.17 GB | 96.4 % | | TAP | 1.08 GB | 1.06 GB | 98.7 % | | brc100 | 142 MB | not measured | not measured | | op20 | 1.72 MB | not measured | not measured | The page gives the reason for each gap in words. Omni: no Omni ledger is run. brc100 and op20: "an OP_RETURN script ledger the appendix cannot read". The lowest covered measured family was Pipe, at 86.8 %. Omni is the largest gap: its 6.66 GB is most of the difference between the books and the bytes placed. Some rows carry notes. For Ordinal Sats, 710 tokens were "pending resolution", their bytes in the gap until the block-by-block replay places them. For Alkanes, 19,257 tokens had "no current holder (every unit sits in a spent or unresolvable output)". Unmatched holder references were listed by source: 131 for SRC-101 names, 20 for Counterparty and 14 for Alkanes. ## How coverage has moved Alkanes were not measured when the appendix was designed on 2026-10-18. The first full seed, landed at 00:08 on 2026-10-19, placed 85.7 % of Book A on addresses. Alkane holders were then added, read from the alkanes indexer's own database, and coverage stood at 94.6 % on 2026-10-20. ## Why the figure can be trusted Coverage is a by-product of checks that must pass before a pass commits: - each token's shares sum to 1; - per protocol, the bytes on addresses plus the bytes in the gap equal the books; - C ≤ B ≤ A for every address. A pass that fails any of these does not commit, and the last good state keeps serving. A pass is one database transaction, so a reader never sees a half-written table. The page also shows how often this happens: on the 2026-10-20 read, 237 passes in the last 24 hours, with a median of 143 seconds each. ## Heights Each holder source has its own height, and the page lists them all. On that read they ran from block 971,999 (the sat export) to block 972,298, and every source was reconciled to block 972,199, the appendix's single height. See [the frontier and "as of"](/methodology/the-frontier-and-as-of/). ## How to read it A protocol that is not measured is written "not measured", never 0, and its row stays in the table with its Book A total. Its tokens add nothing to any address, so a leaderboard figure is a figure for the covered part of the books. See [null is never zero](/methodology/null-is-never-zero/). Sources: - block.space leaderboard coverage API (holders measured per protocol) · https://block.space/api/leaderboard/coverage - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space - block.space docs: rankings · https://block.space/docs/rankings - Blockspace Holdings records - block.space leaderboard API · https://block.space/api/leaderboard Live figures: holders as of block 972,199, 2026-10-20 09:22:01 UTC Updated: 2026-10-20 --- # Measured findings The findings of the July 2026 measurement run, each dated, and what the live meter reads now. Ratios are the durable results; shares of the chain move. URL: https://blockspace.wiki/methodology/measured-findings/ block.space's measurements document collects "numbers that would make a chart", under the heading "Measured, not assumed". Its figures are from the **July 2026 measurement run**, and it says that "the Meter's live pages supersede them where they differ". This page gives the run's five findings with that date, then the live readings. The document's own advice on reading them: ratios (B/A, C/B, bytes:vbytes) "are the durable findings — they hold as measurement advances. Shares of chain totals will move." ## The July 2026 run ### 1. The chain became a data medium, then partly stopped Data payload as a share of all block bytes, at five heights: | height | share | the document's note | |---|---|---| | 450,000 | 0.0 % | pre-ordinals: the chain is payments | | 600,000 | 9.2 % | Omni, Counterparty, early OP_RETURN | | 788,000 | 13.4 % | BRC-20 mania | | 833,000 | 45.4 % | peak: nearly half of Bitcoin is payload | | 850,000 | 31.9 % | recession after runes moved to OP_RETURN | The document reads the fall as runes replacing inscription bodies with 20-byte runestones: "a protocol getting more efficient reduces the chain's data share while increasing the number of tokens." ### 2. The witness subsidy, per protocol Bytes divided by vbytes: 3.374 for inscriptions, 1.008 for stamps, 1.0000 for runestones and 1.0142 for Omni. "A 3.37× gap between two protocols using the same chain in the same year." What this means is on [the witness discount](/concepts/witness-discount/). ### 3. The free-ride index B/A, the share of a token's inclusive book that is its own measured structure. Open Assets: 0.72. CoinSpark: three regimes, 1.00, then 0.91, then 0.09, with a per-claim floor of 0.026, "the most extreme free-ride measurement recorded". See [carriage and the free-ride index](/concepts/carriage-and-the-free-ride-index/). ### 4. EPOBC, a token with zero carrier bytes EPOBC encoded its colour entirely in the input-0 nSequence field, which every transaction already has. Its free-carrier fraction was 1.0: the marginal bytes attributable to the colouring are none. Under Book B it claims essentially nothing; under Book A it claims whole transactions. "The two books give opposite answers, and both are correct." ### 5. OLGA, a protocol upgrade Stamps' switch from bare multisig to chunked P2WSH made encoding 1.84× cheaper per content byte and 2.96× cheaper per file byte. Mean file size rose from 366 B to 3,421 B, 9.3× larger, and adoption reached 98.3 % within 2,500 blocks. The document's reading: "users spent the savings on more content rather than banking them." ## The live meter now The books held (as of block 972,299, 2026-10-20 09:30:48 UTC): | measure | value | |---|---| | Book A | 133.75 GB | | Book B | 126.98 GB | | Book C | 36.38 GB | | chain bytes in the range | 777.04 GB | | Book A as a share of the range | 17.21 % | | tokens | 126,874,922 | | operations | 623,681,326 | | protocols | 21 | The census, nearer the tip, had counted 777.04 GB over 972,303 blocks (as of block 972,302, 2026-10-20 10:16:21 UTC). The largest families by Book A, with their share of the chain's bytes (as of block 972,299, 2026-10-20 09:30:48 UTC): | family | Book A | share of chain bytes | |---|---|---| | Ordinal Sats | 56.13 GB | 7.22 % | | Runes | 33.05 GB | 4.25 % | | BRC-20 | 17.49 GB | 2.25 % | | Alkanes | 11.95 GB | 1.54 % | | Omni | 6.66 GB | 0.86 % | These are Book A shares, the bytes of transactions bought for tokens. The run's first finding measured data payload, a narrower thing, so the two series are not the same measure and should not be read as one. ## What has not been measured Blockspace Value Theory proposes a test of its own thesis: across many assets, with inscription number, collection, format and mint era controlled for, price per kilobyte should converge. In its words, "It has not been measured." *BVT is a living document and an untested thesis.* Sources: - block.space docs: measurements · https://block.space/docs/measurements - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - block.space meter and summary APIs · https://block.space/api/summary - block.space protocols API · https://block.space/api/protocols - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space 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; protocols as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Null is never zero Why block.space and this wiki write "not measured" instead of 0: what a measured zero is, where nulls come from, and how the rule shows on the pages and in the APIs. URL: https://blockspace.wiki/methodology/null-is-never-zero/ A figure that was not measured is not zero. block.space states it as the fourth of the rules every board follows: "'Not measured' is never 0." This wiki's writing rules repeat it: "Something not measured is 'not measured'." This page explains the difference, where it comes from, and where it shows. ## Two different statements - **A measured zero** says: the instrument looked and found nothing. The measurements document gives the example of a protocol that carries no artifact body. It "honestly measures zero in the content book. A measured zero is not a missing measurement." A pure-ledger transfer, such as an Omni or Counterparty send, has a [Book C](https://blockspace.wiki/glossary/book-c/) of 0 for this reason. - **A null** says: the instrument did not look, could not look, or has not finished. It is written in words, as [not measured](https://blockspace.wiki/glossary/not-measured/). The rankings documentation lists the cases a board meets: "A book the instrument has 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." ## Why the rule exists Blockspace Value Theory (§2.2a) records the failure the rule guards against. A census that finds protocols by their markers cannot see a protocol that hides its marker. Counterparty encrypts its payloads, and a byte scan of SRC-721 across blocks 820,600 to 823,200 "returned zero occurrences" on 2026-08-04, while Counterparty's own API showed SRC-721 mints live from block 795,762. In BVT's words, a marker-driven census "does not report a small number. It reports zero." From this BVT draws the conclusion that "unclaimed bytes" is an upper bound, not a residue, and that it should be stated as "not attributable by marker detection", "a claim about the instrument, not about the chain". [BTI](https://blockspace.wiki/glossary/bti/)'s design takes this up as requirement R3, instrument honesty: BTI must publish the measurement's own blind spots rather than present a residue as a fact about the chain. ## Where nulls come from in BTI - **An unreachable source.** The design's rule is to fail closed: "An unreachable source is a refusal, never a zero." The frontier cannot claim a protocol was searched if its source could not be asked. See [the frontier and "as of"](/methodology/the-frontier-and-as-of/). - **A book not yet measured.** block.space's summary API carries the rule in its units note: "null means not measured. It never means zero." The front page says it in one line: "A null in the regional book means not measured — never zero." On the latest read (2026-10-20), the summary listed all 21 protocols as measured in each of Books A, B and C. - **A holder no source records.** The holders appendix's rule is that "a protocol the appendix cannot see is 'not measured', never 0", and that a source whose delta is not yet written is "delta pending" by name. - **Below a cut-off.** A board that ranks the top 100,000 says so, with the smallest figure that made the list. The rankings rules add: "A figure below the cut-off is unranked, not zero." ## How it looks on the pages The leaderboard's coverage page is the clearest example. On 2026-10-20 (appendix pass finished 09:20 UTC, books at block 972,199) it listed three protocols with no holder source: Omni (no Omni ledger is run), brc100 and op20 ("an OP_RETURN script ledger the appendix cannot read"). Each row shows its [Book A](https://blockspace.wiki/glossary/book-a/) total, 6.66 GB for Omni, and then "not measured" in the columns for bytes on addresses, share and addresses. It does not show 0, and it does not drop the row. See [coverage](/methodology/coverage/). ## How this wiki keeps the rule The wiki's live figures are read hourly from block.space and Blockspace Holdings' own node and indexers, and its build refuses a figure it has no reading for: a missing value fails the build rather than printing a number. The refresh job keeps a source's last reading, with its own "as of", when the source fails. Where a document gives no figure, the page says the documents do not give it. Sources: - block.space docs: rankings · https://block.space/docs/rankings - block.space docs: measurements · https://block.space/docs/measurements - Blockspace Holdings records - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - block.space meter and summary APIs · https://block.space/api/summary - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space - block.space leaderboard coverage API (holders measured per protocol) · https://block.space/api/leaderboard/coverage - blockspace.wiki README · https://blockspace.wiki Updated: 2026-10-20 --- # The conservation identity claimed + carriage + burned + unclaimed = block size: the four categories every byte falls into, why the identity is the meter's trust anchor, and how block.space shows the check. URL: https://blockspace.wiki/methodology/the-conservation-identity/ Every byte of every block lands in exactly one of four categories, and the four add up to the block's exact size: ``` claimed + carriage + burned + unclaimed = block size ``` block.space's BTI documentation calls this partition "the Meter's trust anchor: the categories are complete, they are exclusive, and anyone can add the numbers themselves." This page explains the four terms, why the identity matters, and what the site prints when it does or does not close. The glossary entry is [conservation](https://blockspace.wiki/glossary/conservation/). ## The four categories The definitions, from the BTI documentation and the renderer's own labels: | category | meaning | |---|---| | [claimed](https://blockspace.wiki/glossary/claimed-bytes/) | bytes at least one token bought; they back a living token | | [carriage](https://blockspace.wiki/glossary/carriage/) | whole transactions tokens moved through without buying them | | [burned](https://blockspace.wiki/glossary/burned-bytes/) | bytes whose every claiming token was provably destroyed | | [unclaimed](https://blockspace.wiki/glossary/unclaimed-bytes/) | bytes no token claimed: "the majority of every block" | Claimed bytes are what [the three books](/concepts/the-three-books/) divide among tokens. Carriage is measured in full and never counted as backing; see [carriage and the free-ride index](/concepts/carriage-and-the-free-ride-index/). The Shared Claim Axiom draws one line sharply: "Unclaimed is not burned. Burned blockspace exited the market; unclaimed blockspace never entered it." Ordinary payments, consolidations and exchange sweeps make up most unclaimed bytes. They were consumed as permanently as any inscription, but no token is attributed to them. ## Why it is an identity, not an estimate [BTI](https://blockspace.wiki/glossary/bti/)'s design asks for a measurement "that does not depend on knowing any protocol: every byte of every block lands in exactly one category, and the categories sum to the block." It explains why: "This is the only way 'account for every byte' is checkable — 'find every carrier' never is." The layers make it checkable: - The census (T1) counts every transaction's size and reconciles it against the block's exact serialized size. Its totals are "the ground truth everything above must conserve against". - The books (T3) are pure arithmetic over the claims, and can be deleted and recomputed. - The design lists invariants checked on every increment: census buckets sum to block bytes; computed sizes equal those bitcoind reports; the sum of shares equals the sum of claimed bytes in each co-claim group; conservation holds across burns and successions. So a byte cannot quietly go missing or be counted twice. If it did, a sum would fail. ## Unclaimed is an upper bound Blockspace Value Theory (§2.2a) adds a caution. A protocol that hides its marker cannot be found by a census of markers, so its bytes look like bytes that belong to nothing. "Unclaimed bytes" is therefore "an upper bound, not a residue", better stated as "not attributable by marker detection". The identity still holds; what moves, as recognition improves, is the line between claimed and unclaimed. See [null is never zero](/methodology/null-is-never-zero/). ## How block.space shows it The front page draws a bar for the latest block in the books and another for the whole written range, with the four figures and their sum printed beneath, so the reader can add them. The renderer compares the four figures with the size. If they differ by a byte or more, it prints a chip after the line: "the four figures sum to …". A read of the front page at 2026-10-20 09:44 UTC showed both cases worth knowing: - **The latest block, 972,299:** claimed 845,128.73, carriage 29,795.27, burned 0, unclaimed 798,540, against a block size of 1,661,109 bytes. The check chip was showing: "the four figures sum to 1,673,464". - **The whole written range, books to block 972,299:** claimed 133,742,038,926.52, carriage 12,095,314,148.34, burned 9,449,113.19 and unclaimed 637,459,791,991, printed as summing to 783,306,594,179.05 bytes. The same line said the census had counted 777 GB so far. On that read the block-level identity did not close, and the site said so in its own words. The documents do not explain the gap, and this page does not guess at it. The point of the identity is that a gap like this is visible to anyone who adds the numbers. Fractional bytes are expected. Where several tokens share bytes, the axiom divides them, so a token's claimed share need not be a whole number. Sources: - block.space docs: BTI · https://block.space/docs/bti - block.space docs: the axiom · https://block.space/docs/axiom - The Shared Claim Axiom · https://block.space/docs/axiom - Blockspace Holdings records - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space - block.space meter and summary APIs · https://block.space/api/summary Updated: 2026-10-20 --- # The frontier and "as of" How to read the heights on block.space and this wiki: which block a figure is true to, why one page can carry several heights, and how a dated document figure differs from a live one. URL: https://blockspace.wiki/methodology/the-frontier-and-as-of/ Every number block.space publishes is true up to some block, and says which. The rankings documentation puts it first among the rules every board follows: "Every figure is bounded by a height. … A number without its height is not shown." This page is about reading those heights. What the cursors are, and why they are ordered books ≤ claims ≤ census, is on [the frontier](/concepts/the-frontier/). ## The heights in one picture [BTI](https://blockspace.wiki/glossary/bti/) runs three stages, each with its own [cursor](https://blockspace.wiki/glossary/cursor/), and the chain tip runs ahead of them all. On the latest reading (as of block 972,301, 2026-10-20 09:35:17 UTC): | height | what it bounds | |---|---| | tip, block 972,304 | the newest block Blockspace Holdings' own node knows | | census, block 972,302 | bytes counted (T1) | | claims, block 972,301 | protocols searched (T2) | | books, block 972,299 | attribution written (T3) | block.space prints the same strip at the top of its pages: T1 byte census, T2 claims, T3 books, chain tip. The design keeps the three cursors equal at every commit when the engine follows the chain, so a gap between them means a stage is catching up. ## "As of block H" on the boards The boards add one more height: the block the holders appendix is synchronised to. Since 2026-10-19 it is one rule for every board: the heading says "as of block H", where H is the appendix's single sync block, and "the detail line names the books height and, where it differs, the ranking's own height. Never two unexplained heights in one heading." The API envelope carries all three. On a read of `/api/rankings` on 2026-10-20 it gave `as_of: {appendix: 972199, books: 972199, ranking: 972199}`, and the /rankings page read "as of block 972,199 · bytes to the same block". The wording for holder figures is "bytes to block H · holders to H₁–H₂ by source". Each holder source has its own height, and H is the lowest of them, the books included. The coverage page, read the same morning, said "bytes to block 972,199 · holders as of block 972,199 (by source 971,999–972,298)", and lists every source's height in a table. See [coverage](/methodology/coverage/). ## Why one page can show several heights The stages move at different speeds, and that is honest, not an error. On the same read: - the front page's conservation bar said "books written to block 972,299"; - its token table said "up to block 972,199"; - the summary API's cursor list showed `aggs:folded` at 972,199, the height the per-token sums were folded to. Each figure carries its own bound. A reader comparing two figures should compare their heights first. ## Fail closed A height is only claimed when it is earned. The design's rules: only completed windows move a cursor; no increment may pass the indexed height of any source it depends on (`hi = min(hi, sources, caps)`); and "an unreachable source is a refusal, never a zero". So a lagging source holds the frontier back rather than letting a figure claim more than was searched. See [null is never zero](/methodology/null-is-never-zero/). ## "As of" on this wiki This wiki follows the same rule with two kinds of figure. - **Live figures** are read from block.space and Blockspace Holdings' own node and indexers, refreshed hourly. Each group of figures has its own "as of", a block height and a time. A census figure and a books figure read in the same hour can be bounded by different blocks, and each page prints the "as of" of every group it uses. A source that fails keeps its last reading and its own "as of". - **Document figures** are given with the document's date: "in the July 2026 measurement run", "as of 2026-10-18". The measurements document says of its own figures that "the Meter's live pages supersede them where they differ". Figures read by hand from a live page, such as the coverage numbers above, are given with the time they were read. The holders data stood at block 972,199 (as of block 972,199, 2026-10-20 09:22:01 UTC); the books totals at block 972,299 (as of block 972,299, 2026-10-20 09:30:48 UTC). Sources: - block.space docs: rankings · https://block.space/docs/rankings - Blockspace Holdings records - block.space docs: measurements · https://block.space/docs/measurements - block.space meter and summary APIs · https://block.space/api/summary - block.space frontier API (the three tier cursors and the chain tip) · https://block.space/api/frontier - block.space rankings API (the four boards' top rows and their heights) · https://block.space/api/rankings - block.space leaderboard coverage API (holders measured per protocol) · https://block.space/api/leaderboard/coverage - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space - blockspace.wiki README · https://blockspace.wiki Live figures: books as of block 972,299, 2026-10-20 09:30:48 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 Updated: 2026-10-20 --- # What each board ranks The four block.space rankings, the leaderboard, largest inscriptions, heaviest tokens and collections: what one row is, which book each reads by default, how deep it goes, and the rules they share. URL: https://blockspace.wiki/methodology/what-each-board-ranks/ block.space's [rankings](https://blockspace.wiki/glossary/rankings/) page, block.space/rankings, gathers four boards under one heading: "one measure: the blockspace bought". Each ranks by bytes, never by count, and each reads the same books under a different question. The book names are explained on [the three books](/concepts/the-three-books/). ## At a glance | board | one row is | default measure | depth | |---|---|---|---| | [leaderboard](https://blockspace.wiki/glossary/the-leaderboard/) | one address | Book A, divided among holders | every address the appendix can place | | [largest inscriptions](https://blockspace.wiki/glossary/largest-inscriptions-board/) | one inscription | Book C, the file's own bytes | top 100,000 per family | | [heaviest tokens](https://blockspace.wiki/glossary/heaviest-tokens-board/) | one token, any protocol | Book A, everything it bought | top 100,000 per family and overall | | collections | one NFT collection | Book A, its members' books summed | top 10,000 per book, unit and family | Every board has the same toggles: Book A, B or C, and bytes or vbytes. ## The leaderboard An address's figure is "the blockspace behind the tokens it holds: for each token, the token's bytes under the chosen book, divided among its holders by their share of the supply". Holding half of a token's units means half its bytes. The share is by units held, not by value, and a non-fungible unit such as an inscribed sat has one unit, so its holder carries all of that token's bytes. The share is taken of the holder total the source reports, not of the protocol's stated supply. A token whose holders no source can see adds nothing to any address. The board's coverage line says how much of the books that leaves out; see [coverage](/methodology/coverage/). On the latest reading the leaderboard ranked 4,491,923 addresses (as of block 972,199, 2026-10-20 09:22:01 UTC). Holders are keyed by script, and the address is a rendering of it; non-standard scripts are shown by hash. ## The largest inscriptions An inscription's size is [Book C](https://blockspace.wiki/glossary/book-c/), "the bytes of the file itself, with every byte of framing removed". The board ranks bytes bought, not bytes shown: a delegate inscription that displays another inscription's image "bought a few hundred bytes and is that size". One row is one inscription. A "by sat" view ranks the sats instead, so a sat inscribed many times carries all its inscriptions. Tabs rank other content families by the same book: Counterparty assets (which carry Stamps and Counters), SRC-20, BRC-20 and TAP. For BRC-20 and TAP, a token's content is the sum of many small files, and the board says so. On a read of the rankings API on 2026-10-20, the top row was inscription #79,351,656, a text/html file of 3,969,429 bytes at block 873,893. ## The heaviest tokens A token's weight is [Book A](https://blockspace.wiki/glossary/book-a/): "every byte of every transaction its operations bought, shared where shared". Under the Shared Claim Axiom a byte two tokens bought is divided between them, never counted twice. A sat, a rune, a BRC-20 tick and a Counterparty asset stand in one ranking "because the measure is bytes, not kind". Each row carries the fees its transactions paid, divided by the same shares. On the same read, the top three were UNCOMMON•GOODS (Runes, 23.9 GB), DIESEL (Alkanes, 11.0 GB) and Tether (Omni, 6.50 GB). ## Collections A collection is a set of NFTs with a named source of membership, and each row shows its provenance: - **chain**: an inscription's children, and SRC-101 roots; - **index**: Counterparty subasset families and Atomicals containers; - **asserted**: a published list, named with its source, never merged with a chain group. Fungible tokens are left out even where they are grouped. A collection's bytes are the sum of its members' books. On the 2026-10-20 read the largest by members was the children of inscription #66,166,842, with 210,007 members, and the page said its rows were "ranked by members while the bytes resolve". ## The rules they share From block.space's rankings documentation: 1. Every figure is bounded by a height: "as of block H", the block the holders appendix is synchronised to. See [the frontier and "as of"](/methodology/the-frontier-and-as-of/). 2. Nothing is sorted at request time; each board reads a ranking written in advance. 3. The population is stated, with the cut-off. A figure below it is "unranked, not zero". 4. "Not measured" is never 0. See [null is never zero](/methodology/null-is-never-zero/). 5. Labels come from the ordinal record; numbers come from the books. Where they disagree, both are shown. 6. Colour names the family, never the rank, and the key is the same on every page. 7. The API carries the exact, unrounded values under one envelope: the heights, the mode, the population, the total and the rows. Sources: - block.space docs: rankings · https://block.space/docs/rankings - Blockspace Holdings records - block.space rankings API (the four boards' top rows and their heights) · https://block.space/api/rankings - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space - block.space leaderboard API · https://block.space/api/leaderboard Live figures: holders as of block 972,199, 2026-10-20 09:22:01 UTC Updated: 2026-10-20 --- # The block.space board APIs The ranking APIs behind block.space/rankings, the leaderboard, the largest inscriptions, the heaviest tokens and the collections, and the address and inscription detail endpoints, all in the one envelope. URL: https://blockspace.wiki/data/block-space-api-boards/ block.space ranks by bytes, never by count. The [rankings](https://blockspace.wiki/glossary/rankings/) boards read [the holders appendix](https://blockspace.wiki/glossary/the-appendix/), which keeps per-token and per-address rankings up to date block by block. Their APIs share one response shape, [the one envelope](https://blockspace.wiki/glossary/the-one-envelope/). The general conventions (the `book` and `denom` mode, `null` as [not measured](https://blockspace.wiki/glossary/not-measured/), caching, errors) are on [the block.space API page](/data/block-space-api/). Every example is a real read-only GET made on 2026-10-20 between 09:42 and 09:47 UTC, trimmed. The public form is `https://block.space/api/...`. ## The one envelope Every board answers in the same envelope: | key | meaning | |---|---| | `as_of` | `{appendix, books, ranking}`: the appendix's sync block (the H every board heading states, "[as of block H](https://blockspace.wiki/glossary/as-of-block-h/)"), the books height the bytes are folded to, and the ranking's own height. The largest inscriptions board adds `census` and `labels`. | | `book`, `denom` | the mode | | `family`, `sub` | the family (protocol) and sub-item filters, or `null` | | `population` | how many things the ranking could rank | | `total` | how deep the ranking goes | | `limit`, `offset` | the page | | `source` | which ranking table answered: `appendix`, or `settle` on a fallback | | `rows` | the page of rows | | `extra` | keys particular to one board | The keys from before the envelope stay one release, deprecated on 2026-10-19: on the leaderboard `protocol`, `mode`, `books_height`, `holder_heights` and `coverage`; on the heaviest tokens board `appendix_height`, `mode`, `labelled`, `cutoff`, `all_attributed`, `family_*`, `families` and `subitems`; on the largest inscriptions board `phase`, `by`, `mode` and `cutoff`. Read them from `as_of` and `extra`. ## Endpoints | endpoint | parameters | rows are | |---|---|---| | `/api/rankings` | none | the index: `as_of` and the top three rows of each board, with its page and API paths | | `/api/leaderboard` | `book`, `denom`, `protocol`, `limit` (1 to 500, default 100), `offset` | addresses, ranked by the bytes behind what they hold | | `/api/leaderboard/coverage` | `book`, `denom` | per protocol: total, placed, fraction, addresses, tokens with and without holders, source heights, `measured`, `pending`, `why` | | `/api/address/` | `book`, `denom`, `limit` (default 500, up to 50,000), `offset` | one script's aggregate, per-protocol split, ranks and a page of holdings | | `/api/largest-inscriptions` | `by` (`inscription` or `sat`), `tag`, `book`, `denom`, `limit`, `offset` | inscriptions (or sats) by content bytes | | `/api/largest-inscriptions/` | `book`, `denom`, `limit`, `offset` | one content family's tokens: `xcp_asset`, `src20`, `brc20` or `tap` | | `/api/inscription/` | none | one inscription, every field of its page | | `/api/heaviest-tokens`, `/api/heaviest-tokens/`, `/api/heaviest-tokens//` | `book`, `denom`, `limit`, `offset` | tokens by the blockspace they bought | | `/api/collections`, `/api/collections/` | `book`, `denom`, `limit`, `offset` | NFT collections by the bytes of their members | | `/api/collections/` | none | one collection: members, totals, holders | `tag` on the largest inscriptions board takes `ordinal`, `counter`, `large` or `reinscription`. Each board reads 100,000 rows deep (the collections 10,000). The collections families are `sat`, `xcp_asset`, `atomicals-nft` and `src101_name`. ## /api/rankings `https://block.space/api/rankings`, read 2026-10-20 09:42 UTC. `boards` holds `leaderboard`, `largest`, `heaviest` and `collections`, each `{href, api, rows}`; the first leaderboard row, trimmed: ```json { "as_of": {"appendix": 972199, "books": 972199, "ranking": 972199}, "boards": { "leaderboard": {"href": "/leaderboard", "api": "/api/leaderboard", "rows": [{"rank": 1, "attributed": 5740264617.587256, "address": "bc1phqvgwn7wn5e4s8g0999rtgafd07jpuuy59rkdrk4s5thw9jafkasg8umr8", "tokens": 7, "protocols": ["alkane"]}]}, "collections": {"href": "/collections", "api": "/api/collections", "rows": []} } } ``` At that moment the collections ranking was still being read, so its rows were empty; see the collections section below. ## /api/leaderboard `https://block.space/api/leaderboard?limit=1`, read 2026-10-20 09:42 UTC, trimmed: ```json { "as_of": {"appendix": 972199, "books": 972199, "ranking": 972199}, "book": "a", "denom": "bytes", "family": null, "sub": null, "population": 4491923, "total": 100000, "limit": 1, "offset": 0, "source": "appendix", "rows": [{ "rank": 1, "attributed": 5740264617.587256, "address": "bc1phqvgwn7wn5e4s8g0999rtgafd07jpuuy59rkdrk4s5thw9jafkasg8umr8", "script": "5120b818874f…", "tokens": 7, "protocols": ["alkane"], "content_bytes": 52.232415105030675, "structure_bytes": 5740020513.489695, "overhead_bytes": 244051.86514668466, "a_bytes": 5740264617.587256, "b_bytes": 5740020565.72211, "c_bytes": 52.232415105030675, "composition": [{"family": "alkane", "bytes": 5740264448.57131, "share": 0.9999999705560706}], "share_of_counted": 0.04294663619711373, "share_of_chain": 0.007388930238615785 }], "extra": { "coverage": {"total": 133660401043.77339, "placed": 126421876377.35614, "fraction": 0.945843910313821, "measured": ["sat"], "not_measured": ["omni_property"], "pending": []}, "holder_heights": {"rune": {"adapter_state:runes": 972291}, "…": "…"}, "mode": {"book": "a", "label": "Book A · inclusive · raw bytes (B)"} } } ``` Field notes: - `address` is null for a non-standard script, which carries `script` and `script_hash` instead. - `attributed` is the held figure for the mode. The six partitions are content, structure and overhead, each in bytes and vbytes. - `composition` is the address's backing by family in the colour key's slot order, as shares of its own total. `protocol_order` lists its protocols largest share first. - `share_of_counted` is the held figure over every byte the books attribute under the mode; `share_of_chain` is over the chain's size to block H. - `extra.coverage.fraction` is the part of the books placed with a holder. `extra.holder_heights` names, per protocol, the height of each source the holders were read from. ## /api/address/<addr> `https://block.space/api/address/bc1phqvgwn7wn5e4s8g0999rtgafd07jpuuy59rkdrk4s5thw9jafkasg8umr8?limit=1`, read 2026-10-20 09:47 UTC, trimmed: ```json { "book": "a", "denom": "bytes", "books_height": 972199, "address": "bc1phqvgwn7wn5e4s8g0999rtgafd07jpuuy59rkdrk4s5thw9jafkasg8umr8", "agg": { "tokens": 7, "protocols": ["alkane", "arc20"], "protocol_ranks": {"": 1, "arc20": 98224, "alkane": 1}, "top_tokens": [{"ref": "2:0", "bytes": 5749192076.866, "share": 0.522988676064, "units": 26064398814169, "protocol": "alkane", "token_id": 280565761}] }, "protocols": [{"protocol": "alkane", "structure_bytes": 5740020345.028466, "tokens": 6}], "ranks": [{"book": "a", "denom": "bytes", "protocol": "", "rank": 1}], "holdings_total": 7, "limit": 1, "offset": 0, "holdings": ["…"], "holdings_pending": false } ``` A rank under the protocol `""` is the overall rank. Holdings carry `units` as text, because balances exceed 2^53, plus `units_total`, `holders`, `share` and the six held figures. A `null` held figure means the token was minted after the books height and has no bytes yet. While the list is still resolving, `holdings_pending` is true and `holdings` is null. A cold address can take 2 to 30 seconds to resolve. An address with no holdings in the appendix is a 404. ## /api/largest-inscriptions `https://block.space/api/largest-inscriptions?limit=1`, read 2026-10-20 09:42 UTC, trimmed. The default book here is [Book C](https://blockspace.wiki/glossary/book-c/), the content book: ```json { "as_of": {"appendix": 972199, "books": 972199, "ranking": 972298, "census": 972298, "labels": 972103}, "book": "c", "denom": "bytes", "family": null, "sub": null, "population": 100000, "total": 100000, "limit": 1, "offset": 0, "source": "appendix", "rows": [{ "rank": 1, "height": 873893, "inscription_id": "269730d6cd8c0795317bb8fd043fc7cecb147bb98ae0fed1a1ca9cc646a0c6a2i0", "number": 79351656, "sat": 257704999999999, "content_type": "text/html;charset=utf-8", "body_bytes": 3969429, "kind": "ord", "cursed": false, "size_class": "whole-block", "a_bytes": 3992635.0, "b_bytes": 3992635.0, "c_bytes": 3969429.0, "fee_sats": 49979388, "tx_bytes": 3992785, "tx_vbytes": 998330, "tags": ["ordinal"], "thumb": "/thumb/269730d6…i0.webp", "page": "/inscription/269730d6…i0" }], "extra": {"phase": 1, "by": "inscription", "cutoff": null, "tag": null, "tag_counts": {"ordinal": 99988, "counter": 37, "large": 207, "reinscription": 1824}} } ``` Rows are per [inscription](https://blockspace.wiki/glossary/inscription/): census bytes, the sat's books beside them, and `sat_label`. With `by=sat` they are per sat, with `label` from the appendix (`null` until resolved). A family path such as `https://block.space/api/largest-inscriptions/brc20?limit=1` ranks that family's tokens instead; its first row on the same morning was the brc20 token `sats`, with `c_bytes` 605,311,064 and `extra.by` = `token`. ## /api/inscription/<id> One inscription in the envelope. `rows[0]` carries every field of its page; `extra` carries `rank`, `prev` and `next`. From `https://block.space/api/inscription/269730d6cd8c0795317bb8fd043fc7cecb147bb98ae0fed1a1ca9cc646a0c6a2i0`, read 2026-10-20 09:45 UTC, the nested blocks of the row: ```json { "tx": {"height": 873893, "tx_index": 1, "size": 3992785, "vsize": 998330, "weight": 3993319, "fee_sats": 49979388}, "token": {"token_id": 267470383, "canonical_ref": "257704999999999", "a_bytes": 3992635.0, "b_bytes": 3992635.0, "c_bytes": 3969429.0, "last_height": 873893}, "label": {"number": 79351656, "content_type": "text/html;charset=utf-8", "content_length": 3969429, "as_of": 972103}, "holder": {"address": "bc1pxj0y2yddwd2vccy9tf29czjun97ssmnyxt4n7w0y7ch9w93w5w8sanhtax", "as_of": 971999, "spent": false}, "counter": null } ``` The row also carries an `ord` block read from blockspace.to's ord (number, value, satpoint, timestamp, parents); see [the ord API](/data/ord-api/). ## /api/heaviest-tokens `https://block.space/api/heaviest-tokens?limit=1`, read 2026-10-20 09:42 UTC, trimmed: ```json { "as_of": {"appendix": 972199, "books": 972199, "ranking": 972199}, "book": "a", "denom": "bytes", "family": null, "sub": null, "population": 100000, "total": 100000, "limit": 1, "offset": 0, "source": "appendix", "rows": [{ "rank": 1, "global_rank": 1, "attributed": 23874344903.7015, "token_id": 249191573, "protocol": "rune", "ref": "1:0", "name": "UNCOMMON•GOODS", "label": "Runes", "created_height": 840000, "a_bytes": 23874344903.7015, "b_bytes": 23862302521.241653, "c_bytes": 0, "op_count": 165758746, "op_mint": 165314008, "op_transfer": 443965, "op_burn": 773 }], "extra": { "labelled": true, "cutoff": 63808.0, "all_attributed": 133660401043.77339, "family_attributed": null, "family_share": null, "family_tokens": null, "families": [{"protocol": "sat", "label": "Ordinal Sats", "family": "sat", "attributed": 56124745876.31794, "share": 0.4199055624405709, "tokens": 125512065, "in_slice": 16, "depth": 100000}], "subitems": [] } } ``` On a family tab (`/api/heaviest-tokens/rune`) `extra.family_attributed`, `family_share` and `family_tokens` are filled; for runes on the same morning they were 32,976,967,605.25 bytes, a share of 0.2467, and 216,277 tokens. `extra.labelled` is false for a sub-item whose source has no claim-source bit yet. An unknown family answers 404 with the list of the 21 known ones; an unknown sub-item of `sat` answered 404 with `["inscriptions", "brc20-carrier", "bitmap", "sns", "cat21"]`. ## /api/collections `https://block.space/api/collections?limit=1`. The ranking is read behind the answer. While it is cold, the API returns the envelope with `rows: []`, `"resolving": true` and `"retry_after": 3`, never a bare 503. That is what the first reads at 09:42 UTC got; a retry at 09:46 UTC answered, trimmed: ```json { "as_of": {"appendix": 972199, "books": 972199, "ranking": 972199}, "book": "a", "denom": "bytes", "population": 10000, "total": 10000, "source": "appendix", "rows": [{ "rank": 1, "group_id": -1, "name": "Degents (degent.club)", "protocol": "sat", "family": "Ordinals", "kind": "list", "provenance": "asserted", "members": 4112, "attributed": 1518920128.5, "share": 0.2772655936566113, "bytes_status": "measured", "page": "/collections/-1" }], "resolving": false, "extra": {"unit": "MB", "ranked_by": "attributed", "nft_total": 5478213536.949545} } ``` `provenance` says where a collection's membership comes from: from the chain, from an index, or asserted by a published list, as here. `share` is the collection's bytes over `extra.nft_total`. Sources: - Blockspace Holdings records - block.space JSON API, read-only GETs (every /api/* endpoint) · https://block.space/api/summary - block.space leaderboard API · https://block.space/api/leaderboard - block.space leaderboard coverage API (holders measured per protocol) · https://block.space/api/leaderboard/coverage - block.space docs: rankings · https://block.space/docs/rankings Updated: 2026-10-20 --- # The block.space API Every public JSON endpoint under https://block.space/api/: what each one returns, its parameters, the shared conventions, and real responses with their as of. URL: https://blockspace.wiki/data/block-space-api/ block.space is one server. It renders the pages and serves the same numbers as JSON under `/api/*`. The numbers come from [BTI](https://blockspace.wiki/glossary/bti/) and its [holders appendix](https://blockspace.wiki/glossary/the-appendix/). This page covers the chain, book and token endpoints. The ranking boards (leaderboard, largest inscriptions, heaviest tokens, collections, rankings) and the address and inscription detail endpoints are on [the boards page](/data/block-space-api-boards/). Every example below is a real read-only GET made on 2026-10-20 between 09:42 and 09:47 UTC, trimmed to a few fields. The public form of each address is `https://block.space/api/...`. ## Conventions The API follows these rules, and the live responses bear them out: - Every endpoint returns `application/json`, allows cross-origin reads (`Access-Control-Allow-Origin: *`) and is cached for a few seconds to a minute (`Cache-Control: public, max-age=5` on `/api/meter`, 60 on the leaderboard). - Values are exact and unrounded. Formatting is the client's job. - `null` means [not measured](https://blockspace.wiki/glossary/not-measured/). It never means zero. - An unknown endpoint is a 404 whose body lists every endpoint. An unknown family or sub-item on a board is a 404 that lists the known ones. - A database failure is a 503 with `{"error": "database unavailable", "detail": ...}`; a fault in the site itself is a 500 with `{"error": "internal error", ...}`. ### The mode: book and denom Most endpoints take two toggles, the mode: | parameter | values | default | |---|---|---| | `book` | `a`, `b`, `c` ([Book A](https://blockspace.wiki/glossary/book-a/), [Book B](https://blockspace.wiki/glossary/book-b/), [Book C](https://blockspace.wiki/glossary/book-c/)) | `a` (`c` on the largest inscriptions board) | | `denom` | `bytes` (raw bytes), `vbytes` | `bytes` | An invalid value falls back to the default rather than failing. Responses that take a mode carry a `mode` block that names it: ```json "mode": { "book": "a", "book_name": "Book A · inclusive", "book_answers": "how much blockspace was consumed by transactions that touched a token", "denom": "bytes", "denom_name": "raw bytes", "base_unit": "B", "label": "Book A · inclusive · raw bytes (B)" } ``` `limit` and `offset` are clamped to each endpoint's range, not refused. ### The one envelope The ranking APIs answer in [the one envelope](https://blockspace.wiki/glossary/the-one-envelope/): `as_of` {`appendix`, `books`, `ranking`}, `book`, `denom`, `family`, `sub`, `population`, `total`, `limit`, `offset`, `source`, `rows`, and board-specific keys under `extra`. It is set out with examples on [the boards page](/data/block-space-api-boards/). Keys from before the envelope stay one release, marked deprecated since 2026-10-19; read the new names. ## Endpoint list | endpoint | parameters | returns | |---|---|---| | `/api/summary` | none | chain bytes walked, attributed totals per book, token and operation counts, coverage classes, the frontier and a units note | | `/api/frontier` | none | every BTI cursor row, the indexed window, the active sources and the chain tip | | `/api/meter` | none | the heights each stage has reached, with times and the chain tip | | `/api/tiers`, `/api/t2`, `/api/t3` | none | the three tiers' heights, T2's per-adapter cursors, T3's books and per-protocol roll-up | | `/api/coverage` | none | per-protocol book coverage, claim rows by coverage class, envelope-extractor findings, carrier and unexplained bytes | | `/api/envelopes` | none | the envelope-extractor findings alone | | `/api/protocols` | `book`, `denom` | per-protocol roll-up for the mode, with `book_measured` per row and the per-source split | | `/api/tokens` | `book`, `denom`, `sort`, `protocol`, `q`, `limit` (1 to 500, default 50), `offset` | ranked tokens; `attributed` is the figure for the mode, and every book is returned per row | | `/api/token//` | none | one token: all three books, fees, supply, claim and attempt counts, protocol coverage | | `/api/block/` | `tx` (offset), `limit` (1 to 500) | one block: its ledger row, attributed bytes, per-protocol bytes, top tokens, byte kinds and a page of transactions | | `/api/tx//` | none | one transaction with its book entries | | `/api/growth` | `bucket` (500 to 5,000, default 1,000) | per-bucket and cumulative chain bytes, vbytes, Book A and Book C, plus the landmarks | | `/api/landmarks` | none | named heights with descriptions and whether the walker has reached them | | `/api/t1`, `/api/t1/series`, `/api/t1/blocks`, `/api/t1/block/`, `/api/t1/tx//`, `/api/t1/residue`, `/api/t1/lookup?q=` | `bucket`; `from`, `limit`; `tx`, `limit`; `limit`, `offset`; `q` | the [byte census](https://blockspace.wiki/glossary/the-census/) (T1): coverage, bucket totals, block and transaction views, the residue, and a lookup of a height, block hash or txid | | `/api/projects` | none | the project list shown at block.space/projects, in the one envelope | | `/api/cache` | none | the age in seconds of each cached aggregate | | `/healthz` | none | liveness, the derive and walker heights, and the chain tip | `sort` takes `attributed` (the default), `ops`, `created`, `supply`, `content`, `fees` or `name`. The board endpoints are listed on [the boards page](/data/block-space-api-boards/). `/api/largest` answers with a permanent redirect to `/api/largest-inscriptions`. ## Examples ### /api/meter How far each stage has got. `counted` is the census, `catalogued` the claims, `books_written` the books. Read 2026-10-20 09:42 UTC (`https://block.space/api/meter`): ```json { "counted": 972301, "catalogued": 972301, "books_raw": 972299, "books_written": 972299, "counted_at": "2026-10-20T09:22:42Z", "catalogued_at": "2026-10-20T09:35:17Z", "books_at": "2026-10-20T09:30:48Z", "tokens_through": 972199, "books_hash": {"win_lo": 972200, "win_hi": 972299, "rows": 473449, "hash": "319bcb87…"}, "chain_tip": {"height": 972303, "source": "bitcoind"} } ``` ### /api/summary Read 2026-10-20 09:42 UTC (`https://block.space/api/summary`), trimmed: ```json { "ledger": {"blocks_walked": 972302, "max_height": 972301, "chain_bytes": 777036635205, "chain_vbytes": 567699528020, "chain_fees": 30078456613267, "chain_txs": 1464145200}, "books": { "a": {"bytes": 133751488039.71294, "protocols": 21, "measured_protocols": 21, "complete": true}, "b": {"bytes": 126977437621.66104, "protocols": 21, "measured_protocols": 21, "complete": true}, "c": {"bytes": 36378763001.0, "protocols": 21, "measured_protocols": 21, "complete": true} }, "tokens": 126866878, "ops": 623207877, "coverage_classes": [{"coverage": "ABC", "tokens": 126866878}], "frontier": {"cursors": [{"name": "census", "height": 972301, "updated_at": "2026-10-20T09:22:42Z"}, "…"]} } ``` The wiki's own figures read from the same API; on its latest reading (as of block 972,299, 2026-10-20 09:30:48 UTC) Book A held 133.75 GB at block 972299. ### /api/frontier The same cursor list as `summary.frontier`: one row per cursor (`census`, `claims`, `attributions`, `aggs:folded`, and one `claims:` row per T2 unit), each with `height` and `updated_at`. See [the frontier](/concepts/the-frontier/) for what the cursors mean. ### /api/protocols Read 2026-10-20 09:45 UTC (`https://block.space/api/protocols`), the first row and one entry of `sources`: ```json { "book": "a", "denom": "bytes", "rows": [ {"protocol": "sat", "books": "ABC", "note": null, "book_measured": true, "tokens": 125512065, "attributed": 56124745876.31794, "attributed_vb": 21498797593.27078, "a_bytes": 56124745876.31794, "c_bytes": 33433631755.9125, "fees": 604022087850.3802, "ops": 129007141, "first_height": 767430, "last_height": 972199} ], "sources": { "alkane": { "alkanes": {"protocol": "alkane", "source": "alkanes", "attributed": 11943112257.933353, "tokens": 103972, "entries": 107312782, "fees": 6119789975.588749} } } } ``` `sources` splits a protocol's bytes by the T2 source that claimed them; `family` and `source_names` ride along for the client's table. ### /api/tokens and /api/token/<protocol>/<ref> `https://block.space/api/tokens?limit=1`, read 2026-10-20 09:45 UTC: ```json { "book": "a", "denom": "bytes", "sort": "attributed", "protocol": null, "q": null, "limit": 1, "offset": 0, "total": 126866878, "rows": [ {"rn": 1, "token_id": 249191573, "protocol": "rune", "ref": "1:0", "name": "UNCOMMON•GOODS", "created_height": 840000, "burned_height": null, "attributed": 23874344903.7015, "a_bytes": 23874344903.7015, "b_bytes": 23862302521.241653, "c_bytes": 0, "op_count": 165758746, "last_height": 972199, "current_supply": 165289796, "coverage": "ABC", "op_mint": 165314008, "op_transfer": 443965, "op_inscribe": 0, "op_burn": 773, "op_other": 0} ] } ``` The same token by reference, `https://block.space/api/token/rune/1:0`, adds `protocol_books`, `protocol_note`, `claims` (165,758,746) and `attempts` (0). ### /api/block/<height> `https://block.space/api/block/972000?limit=1`, read 2026-10-20 09:43 UTC, trimmed: ```json { "height": 972000, "ledger": {"n_tx": 4533, "total_bytes": 1852602, "total_vbytes": 1000727, "total_weight": 3992658, "total_fees": 997259, "block_hash": "00000000000000000001f09a…"}, "attributed": {"claimed_bytes": 1195767.875, "carriage_bytes": 66148.5, "burned_bytes": 0, "unclaimed_bytes": 598941.0, "content_bytes": 400142.0}, "protocols": [{"protocol": "sat", "a_bytes": 424517.6041666667, "c_bytes": 397253.5}, "…"], "kinds": {"base_bytes": 713352, "wit_bytes": 1139250, "signatures": 488524, "data_payload": 474729, "unexplained": 399}, "written_to": 972299, "counted_to": 972301, "transactions": {"total": 4533, "rows": ["…"]} } ``` A block the census has not reached is a 404 with `{"error": "not counted yet", "counted_to": ...}`. ### /api/growth `https://block.space/api/growth?bucket=5000`, read 2026-10-20 09:43 UTC, the first bucket: ```json { "bucket": 5000, "frontier_height": 972299, "clipped_to": 972299, "last_bucket_partial": true, "series": [{"h": 0, "chain_bytes": 715886, "chain_vbytes": 715886, "a_bytes": 0, "c_bytes": 0, "txs": 5063, "blocks": 5000, "t0": 1231006505, "t1": 1235134923, "cum_chain_bytes": 715886, "cum_a_bytes": 0}], "landmarks": [{"name": "genesis", "height": 0, "descr": "Bitcoin genesis block"}] } ``` ### Endpoints that did not answer in the example window On 2026-10-20 at 09:43 UTC `/api/coverage` returned the 503 `database unavailable` body (a statement timeout), and `/api/envelopes` returned `{"error": "aggregation unavailable"}`. Both are heavy aggregates and are documented as normal endpoints. ## The Minute API, under block.space/minute `https://block.space/minute/api/` forwards to the Minute API, a separate package with its own OpenAPI spec (`/minute/api/openapi.json`) and `llms.txt` (`/minute/api/llms.txt`). It is a mint flow (`POST /v1/mint/plan`, `/v1/mint/commit-psbt`, `/v1/mint/finalize`, `/v1/mint/broadcast`), not a data API. Its documentation says mainnet is off until roadmap gate G1 passes unless the operator explicitly allows it; the live `/v1/fees` answer below reports `mainnet`. Its one plain read is `GET /v1/fees`, read 2026-10-20 09:46 UTC: ```json {"network": "mainnet", "chain": "main", "source": "estimatesmartfee", "as_of": 1792489580, "sat_vb": {"fast": 1.01, "medium": 1.01, "slow": 1.01}, "mempool_min_sat_vb": 0.0} ``` Sources: - Blockspace Holdings records - block.space JSON API, read-only GETs (every /api/* endpoint) · https://block.space/api/summary - block.space meter and summary APIs · https://block.space/api/summary - block.space frontier API (the three tier cursors and the chain tip) · https://block.space/api/frontier - block.space protocols API · https://block.space/api/protocols Live figures: books as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # The explore.block.space API explore.block.space runs the open-source Mempool explorer, and with it the Mempool REST API: what is enabled, where it is documented, and real responses. URL: https://blockspace.wiki/data/explorer-api/ [explore.block.space](https://blockspace.wiki/glossary/explore-block-space/) is block.space's sibling block explorer, the transaction view of the same chain. Its code is the public repository [BLOCKdotSPACE/blockspace-explorer](https://github.com/BLOCKdotSPACE/blockspace-explorer), a copy of the Mempool Open Source Project, which its README describes as "the fully-featured mempool visualizer, explorer, and API service". It reads [Blockspace Holdings' node and indexers](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/), and follows the repository's `master` branch: a push is deployed within about a minute, and a failed check puts the previous build back. ## Where the API is documented The explorer serves its own REST API reference at https://explore.block.space/docs/api/rest. The reference is generated from the repository's API documentation file, so it lists every endpoint the Mempool code offers. This page does not copy it. It records what the deployment adds or leaves out, and shows a few real answers. ## Paths The repository's web server configuration routes: - `/api/v1/...` to the Mempool backend's own API (fees, mining, difficulty, blocks with extras); - `/api/...` to the same backend under `/api/v1/`, so the Esplora-style paths (`/api/blocks/tip/height`, `/api/tx//status`, `/api/block-height/`) answer too; - `/api/v1/ws` and `/ws` to the backend's WebSocket. ## What is switched on The deployment's configuration names the network `mainnet` and the backend `electrum`. Statistics and fiat prices are enabled. Lightning is disabled, and so is the Stratum feature: `GET https://explore.block.space/api/v1/lightning/statistics/latest` answered `Cannot GET` on 2026-10-20. ## Examples All read 2026-10-20 at 09:44 UTC; the public form is shown. `https://explore.block.space/api/blocks/tip/height`: ```text 972303 ``` `https://explore.block.space/api/v1/fees/recommended` (sat/vB): ```json {"fastestFee": 3, "halfHourFee": 1, "hourFee": 1, "economyFee": 1, "minimumFee": 1} ``` `https://explore.block.space/api/mempool`: ```json {"count": 48622, "vsize": 25142046, "total_fee": 5822318, "fee_histogram": []} ``` `https://explore.block.space/api/v1/blocks/972000`, the first block of the list, trimmed: ```json {"id": "00000000000000000001f09a6919251b4c3dd5261ee68c8a17ec718667d35f20", "height": 972000, "timestamp": 1792330109, "tx_count": 4533, "size": 1852685, "weight": 3992990, "extras": {"totalFees": 997259, "medianFee": 0}} ``` `https://explore.block.space/api/v1/difficulty-adjustment`, trimmed: ```json {"progressPercent": 29.315476190476193, "difficultyChange": 5.965006488566682, "remainingBlocks": 1425, "nextRetargetHeight": 973728} ``` `https://explore.block.space/api/tx/79103146f41684b035467d25951562db830f88e97a1ffa3a56036048da0fa491/status`: ```json {"confirmed": true, "block_height": 972000, "block_hash": "00000000000000000001f09a6919251b4c3dd5261ee68c8a17ec718667d35f20", "block_time": 1792330109} ``` ## How it differs from the block.space API The explorer reports the chain as Bitcoin Core and Mempool see it: sizes, weights, fees, the [mempool](https://blockspace.wiki/glossary/mempool/). It knows nothing of [BTI](https://blockspace.wiki/glossary/bti/)'s books. The same block 972000 on [the block.space API](/data/block-space-api/) adds the attributed, claimed and content bytes. The two report different sizes for it: the explorer's `size` is 1,852,685 bytes and block.space's ledger `total_bytes` is 1,852,602, 83 bytes fewer. Compare like with like before mixing the two. Sources: - BLOCKdotSPACE/blockspace-explorer README · https://github.com/BLOCKdotSPACE/blockspace-explorer - blockspace-explorer nginx-mempool.conf: the /api, /api/v1 and /ws routes · https://github.com/BLOCKdotSPACE/blockspace-explorer - blockspace-explorer REST API documentation (frontend/src/app/docs/api-docs/api-docs-data.ts), served at /docs/api/rest · https://explore.block.space/docs/api/rest - explore.block.space REST API, read-only GETs · https://explore.block.space/api/blocks/tip/height - Blockspace Holdings records Updated: 2026-10-20 --- # Machine surfaces The files blockspace.wiki publishes for agents and crawlers: sitemap, robots, llms.txt and llms-full.txt, Markdown per page, the Atom feed, the search index, blockspace.json, the live figures and the JSON-LD types. Plus what is planned for the other sites. URL: https://blockspace.wiki/data/machine-surfaces/ blockspace.wiki is written for people and for programs. Every page is built from one set of Markdown files, and the same build writes the [machine surfaces](https://blockspace.wiki/glossary/machine-surfaces/), the files an agent or crawler reads instead of the HTML. Nothing on them is written by hand. A build fails, and writes nothing, on a page without sources, a dead internal link, an undefined glossary term or a live figure that does not exist; so the surfaces never point at a page that is not there. The addresses below are the wiki's own, under `https://blockspace.wiki`. ## The surfaces | address | what it is | |---|---| | `/robots.txt` | allows every crawler and agent (`User-agent: *`, `Allow: /`) and names the sitemap | | `/sitemap.xml` | every page, with `lastmod` from the page's `updated` date | | `/llms.txt` | a short Markdown index: a one-paragraph description, then each section with a link to every page's Markdown and its one-line summary | | `/llms-full.txt` | the whole wiki in one Markdown file, every page in order, with the build time and page count at the top | | `//index.md` | each page as Markdown, with live figures filled in and glossary terms as absolute links. Every HTML page links its own as "This page as Markdown". | | `/feed.xml` | an Atom feed of the 60 most recently updated pages | | `/search-index.json` | the index the search page uses (below) | | `/blockspace.json` and `/.well-known/blockspace.json` | the same file: what the site is, its surfaces and the as of of its live figures (below) | | `/state/live.json` | the live figures the pages show, each group with its `as_of` | ## search-index.json One JSON array, one object per page, with short keys: | key | holds | |---|---| | `t` | title | | `u` | the page's path | | `s` | summary | | `k` | the section's name | | `a` | aliases (glossary terms) | | `h` | the page's `##` and `###` headings, joined by " · " | | `x` | the first 80 words of the body, as plain text | ## blockspace.json The site's self-description. As built at 2026-10-20 09:43 UTC, trimmed: ```json { "name": "blockspace.wiki", "description": "Everything about Bitcoin blockspace, written down.", "publisher": {"name": "Blockspace Holdings", "url": "https://blockspace.holdings"}, "url": "https://blockspace.wiki/", "built": "2026-10-20T09:43:41Z", "pages": 193, "sections": {"concepts": 21, "projects": 18, "glossary": 139}, "surfaces": { "sitemap": "https://blockspace.wiki/sitemap.xml", "robots": "https://blockspace.wiki/robots.txt", "llms": "https://blockspace.wiki/llms.txt", "llms_full": "https://blockspace.wiki/llms-full.txt", "feed": "https://blockspace.wiki/feed.xml", "search_index": "https://blockspace.wiki/search-index.json", "page_markdown": "https://blockspace.wiki//index.md", "glossary": "https://blockspace.wiki/glossary/", "live_figures": "https://blockspace.wiki/state/live.json" }, "live_as_of": {"books": "2026-10-19T20:17:25Z", "ord": "2026-10-20T09:22:01Z", "…": "…"}, "rules": ["Every page cites its sources.", "Theory is labelled as theory.", "Null is never zero.", "Live figures carry their as of."] } ``` The page and section counts grow as pages are added; read the file for the current ones. ## state/live.json The figures behind every `as of` on the wiki. They are refreshed hourly, at 17 minutes past the hour UTC, from block.space's API, blockspace.to's ord `/status`, the node's relay policy and the Degent collection list. A source that fails keeps its last reading and its own `as_of`, so a stale figure says how old it is. The groups and their keys: | group | keys | |---|---| | `books` | `a_bytes`, `b_bytes`, `c_bytes` and their shares, `height`, `ops`, `tokens`, `protocols`, `blocks_touched`, `range_bytes` | | `census` | `height`, `blocks`, `chain_bytes`, `chain_vbytes`, `chain_txs`, `chain_fees` | | `frontier` | `census`, `claims`, `books`, `height`, `tip` | | `holders` | `height`, `population` | | `ord` | `height`, `inscriptions`, `blessed`, `cursed`, `runes`, `lost_sats` | | `relay` | `subversion`, `fullrbf`, `minrelaytxfee_sat_vb`, `incrementalrelayfee_sat_vb`, `maxmempool_mb`, `height` | | `degent` | `inscribed`, `supply` | | `protocols` | one object per protocol family: `a_bytes`, `c_bytes`, `fees`, `ops`, `tokens`, `share`, `of_books`, `first_height`, `last_height` | Every group has `as_of`. For example, on the latest reading (as of block 972,301, 2026-10-20 09:35:17 UTC) the books were written to block 972,299 and the chain tip was block 972,304. ## JSON-LD Each HTML page carries schema.org JSON-LD: | on | types | |---|---| | every page | `BreadcrumbList` | | the home page | `Organization` (Blockspace Holdings, with `sameAs` block.space, blockspacelabs.com and the BLOCKdotSPACE GitHub organisation) and `WebSite` with a `SearchAction` (`/search/?q={query}`) | | concept, protocol, basics, methodology, data, research and project pages | `Article`, published and authored by Blockspace Holdings, with `dateModified` | | a glossary term | `DefinedTerm`, in the set `/glossary/` | | the glossary index | `DefinedTermSet` with every term | | the FAQ page, each answer page, and project pages with questions | `FAQPage` | ## On the other sites: planned For every other Blockspace Holdings property, the same surfaces are planned but not yet built as of 2026-10-20: `robots.txt`, `sitemap.xml`, `llms.txt` and `llms-full.txt`; JSON-LD (Organization, WebSite, FAQPage, DefinedTermSet, Article and Dataset); an Atom feed; `/.well-known/blockspace.json`; and, for the data sites, the API in [the one envelope](/glossary/the-one-envelope/) with an OpenAPI spec. Also planned are `aao.json` and `group.json` on every property, in the FlashyOS mesh format, so that an agent can crawl from any one site to all of them (the [spiderweb](https://blockspace.wiki/glossary/spiderweb/)), and a daily check from outside that every declared surface answers 200. What exists elsewhere today, as of 2026-10-20: - block.space serves `/robots.txt` (`User-agent: *`, `Allow: /`) and its JSON API ([the block.space API](/data/block-space-api/)), with the ranking boards already in the one envelope. - The Minute API under block.space publishes an OpenAPI spec at `https://block.space/minute/api/openapi.json` and an `llms.txt` at `https://block.space/minute/api/llms.txt`. - blockspace.news publishes an Atom feed and daily JSON snapshots, and blockspacelabs.com a facts.json; see [the other sites' data](/data/other-sites-data/). Sources: - Blockspace Holdings records - blockspace.wiki README · https://blockspace.wiki - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Live figures: frontier as of block 972,301, 2026-10-20 09:35:17 UTC Updated: 2026-10-20 --- # The blockspace.to ord API blockspace.to is an ord server with its JSON API switched on: how to ask for JSON, the endpoints its guide lists, the recursive /r/ endpoints, the brotli rule for /content, and real responses. URL: https://blockspace.wiki/data/ord-api/ blockspace.to is the explorer built into [ord](https://blockspace.wiki/glossary/ord/), the ordinals indexer, run by Blockspace Holdings as one process with its indexer. It is a fork of ord 0.27.1 that also indexes spent sat ranges ([spent sats](https://blockspace.wiki/glossary/spent-sats/)). It indexes sats, inscriptions, runes, addresses and transactions; its own `/status` says so (below). block.space's inscription pages and [BTI](https://blockspace.wiki/glossary/bti/) both read it. ## Asking for JSON The ord API guide: the server returns JSON instead of HTML when the request carries the header `Accept: application/json`, and the objects follow what the HTML pages show. For example: ```bash curl -s -H "Accept: application/json" https://blockspace.to/status ``` Responses allow cross-origin reads (`access-control-allow-origin: *`). ## Endpoints The guide lists these JSON endpoints (all `GET` unless marked): | path | returns | |---|---| | `/status` | the server and its index: height, counts, which indexes are on | | `/address/
` | every asset of an address (needs the address index) | | `/block/`, `/block/` | one block: hash, height, its inscriptions | | `/blockcount`, `/blockhash`, `/blockhash/`, `/blockheight`, `/blocktime` | the latest block's height, hash and time | | `/blocks` | the latest height, the last 100 block hashes and featured inscriptions | | `/decode/` | a decoded transaction | | `/galleries`, `/galleries/`, `/gallery/`, `/gallery//` | gallery inscriptions | | `/inscription/`, `/inscription//` | one [inscription](https://blockspace.wiki/glossary/inscription/) | | `/inscriptions`, `/inscriptions/`, `/inscriptions/block/` | the latest 100, a page of 100, or one block's inscriptions | | `POST /inscriptions` | details for a list of inscription ids | | `/output/`, `/outputs/
`, `POST /outputs` | outputs: value, sat ranges, inscriptions, runes, `spent` | | `/rune/`, `/runes`, `/runes/` | [runes](https://blockspace.wiki/glossary/rune/) | | `/sat/` | one sat (needs the sat index) | | `/tx/` | one transaction | The guide also lists `POST /offer` and `GET /offers` (PSBT offers) and `/install.sh`; they are not data endpoints. The fork's guide documents no endpoint of its own for spent sat ranges. ### Recursive endpoints The `/r/` endpoints are the ones an inscription can call from inside its own content ([recursion](https://blockspace.wiki/glossary/recursive-inscription/)). They answer JSON without the `Accept` header: `/r/blockhash`, `/r/blockhash/`, `/r/blockheight`, `/r/blockinfo/`, `/r/blocktime`, `/r/children/` (and paged, and `/inscriptions`), `/r/parents/` (likewise), `/r/inscription/`, `/r/metadata/`, `/r/undelegated-content/`, `/r/sat/`, `/r/sat//`, `/r/sat//at/` and its `/content`, `/r/tx/` and `/r/utxo/`. ### /content and brotli `/content/` returns an inscription's raw content. An inscription stored with `content-encoding: br` gets a 406 unless the request accepts brotli, so send `Accept-Encoding: br` and decode the answer; block.space's thumbnailer does exactly that; it had met 38 such inscriptions by 2026-10-19. With the header, the response carries `content-encoding: br`. Content responses are served `cache-control: public, max-age=1209600, immutable`. ## Examples All read 2026-10-20 at 09:44 UTC with `Accept: application/json`; the public form is shown. `https://blockspace.to/status`: ```json {"address_index": true, "blessed_inscriptions": 127697344, "chain": "mainnet", "cursed_inscriptions": 472043, "height": 972303, "inscription_index": true, "inscriptions": 128169387, "json_api": true, "lost_sats": 2895844904, "minimum_rune_for_next_block": "LLGKX", "rune_index": true, "runes": 216409, "sat_index": true, "started": "2026-10-18T13:35:35.217254841Z", "transaction_index": true, "unrecoverably_reorged": false} ``` The wiki reads the same endpoint every hour: on its latest reading (as of block 972,304, 2026-10-20 10:17:29 UTC) ord was at block 972304 with 128,169,401 inscriptions, 472,043 of them [cursed](https://blockspace.wiki/glossary/cursed-inscription/), and 2,895,844,904 [lost sats](https://blockspace.wiki/glossary/lost-sats/). `https://blockspace.to/r/blockheight`: ```text 972303 ``` `https://blockspace.to/inscription/269730d6cd8c0795317bb8fd043fc7cecb147bb98ae0fed1a1ca9cc646a0c6a2i0`, trimmed (the largest inscription on block.space's board): ```json {"id": "269730d6cd8c0795317bb8fd043fc7cecb147bb98ae0fed1a1ca9cc646a0c6a2i0", "address": "bc1pxj0y2yddwd2vccy9tf29czjun97ssmnyxt4n7w0y7ch9w93w5w8sanhtax", "charms": ["vindicated"], "child_count": 6, "content_length": 3969429, "content_type": "text/html;charset=utf-8", "fee": 49979388, "height": 873893, "metaprotocol": null} ``` `https://blockspace.to/r/inscription/269730d6cd8c0795317bb8fd043fc7cecb147bb98ae0fed1a1ca9cc646a0c6a2i0`, trimmed: ```json {"number": 79351656, "output": "14580fd5072a0e96d8e0e6b1526319fde391d788b80a17eee23bf91ee1f961b2:6", "sat": 257704999999999, "satpoint": "14580fd5…f961b2:6:0", "timestamp": 1733723872, "value": 10000} ``` `https://blockspace.to/sat/257704999999999`, trimmed: ```json {"number": 257704999999999, "name": "mahbufyxugw", "block": 51540, "rarity": "common", "decimal": "51540.4999999999", "percentile": "12.271666680165458%", "inscriptions": ["269730d6cd8c0795317bb8fd043fc7cecb147bb98ae0fed1a1ca9cc646a0c6a2i0"]} ``` `https://blockspace.to/rune/UNCOMMON•GOODS`, trimmed: ```json {"id": "1:0", "mintable": true, "entry": {"spaced_rune": "UNCOMMON•GOODS", "symbol": "⧉", "number": 0, "block": 1, "mints": 165723114, "burned": 24212, "divisibility": 0, "premine": 0, "turbo": true}} ``` `https://blockspace.to/output/14580fd5072a0e96d8e0e6b1526319fde391d788b80a17eee23bf91ee1f961b2:6`, trimmed: ```json {"value": 10000, "spent": false, "indexed": true, "confirmations": 98199, "inscriptions": ["269730d6cd8c0795317bb8fd043fc7cecb147bb98ae0fed1a1ca9cc646a0c6a2i0"], "runes": {}} ``` The output's `sat_ranges` field lists its sats as `[start, end)` pairs. ## A known defect As of 2026-10-20 the server's operating notes record one defect: ord 0.27.1 cannot decode Bitcoin Core 28's "anchor" (P2A) script type, so a page for a transaction with such an output fails with "error serving request". Sources: - Blockspace Holdings records - ord /status (the blockspace.to ord server) · https://blockspace.to/status - blockspace.to ord JSON API, read-only GETs with Accept: application/json · https://blockspace.to/status Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # Data the other sites publish The data files and feeds of blockspacelabs.com, blockspace.news, blockspace.markets and the block.space buy board, counters.gallery and scribb.it: what each holds, where it comes from, and a real reading. URL: https://blockspace.wiki/data/other-sites-data/ Besides [the block.space API](/data/block-space-api/), several Blockspace Holdings sites publish their figures as files. They are static sites. Each one rebuilds its pages and data from [Blockspace Holdings' node and indexers](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/) and from block.space's public API, and each figure carries its own "as of". A site's build scripts and hidden paths are never served. The examples were read on 2026-10-20 between 09:45 and 09:50 UTC; the public address is shown. ## blockspacelabs.com: facts.json `https://blockspacelabs.com/data/facts.json` holds every live figure on the [Blockspace Labs](https://blockspace.wiki/glossary/blockspace-labs/) page. It is rebuilt hourly from the node's mempool and network policy, ord's `/status`, block.space's API and the buy board. A source that fails keeps its last reading with its own `as_of`. Top-level keys: `blockspace`, `buy`, `ord`, `relay`, `built_at`. Trimmed, as built at 09:07 UTC: ```json { "built_at": "2026-10-20T09:07:11Z", "blockspace": { "as_of": "2026-10-20T09:07:11Z", "books": {"a_bytes": 133660401043.77339, "height": 972199, "ops": 623207877, "protocols": 21, "tokens": 126866878}, "census": {"chain_bytes": 777027681663, "chain_txs": 1464112513, "height": 972296}, "holders": {"height": 972199, "population": 4491876} }, "buy": {"as_of": "2026-10-20T09:07:11Z", "asks": 167662}, "ord": {"as_of": "2026-10-20T09:07:08Z", "inscriptions": 128169266, "cursed": 472043, "runes": 216402, "height": 972298}, "relay": {"as_of": "2026-10-20T09:07:08Z", "subversion": "/Satoshi:28.2.0/", "fullrbf": true, "minrelaytxfee": 0.0, "incrementalrelayfee": 1e-05, "maxmempool": 300000000, "txs": 38991, "txs_below": 38265, "bytes": 23742337, "vbytes_below": 23550503} } ``` ## blockspace.news: daily snapshots and the feed blockspace.news saves one snapshot of block.space's public API a day at 00:15 UTC and renders each [edition](https://blockspace.wiki/glossary/edition/) as the difference from the day before. A rewound or rewritten set of books is reported as "no comparison", never as a negative. - `https://blockspace.news/data/.json`: the day's snapshot, with `taken_at`, `meter`, `ledger`, `tokens`, `ops`, `protocols` (for `protocols_book` `a`), and the top 100 of the largest inscriptions and heaviest tokens boards, each with its own `as_of` block. Snapshots exist for 2026-10-19 and 2026-10-20. - `https://blockspace.news/feed.xml`: an Atom feed, one entry per edition. - `https://blockspace.news//` and `/archive/`: the editions as pages. From `https://blockspace.news/data/2026-10-20.json`, trimmed: ```json { "taken_at": "2026-10-20T00:15:12Z", "meter": {"counted": 972230, "catalogued": 972230, "books_written": 972199, "chain_tip": {"height": 972232, "source": "bitcoind"}}, "protocols_book": "a", "protocols": [{"protocol": "sat", "attributed": 56124745876.31794, "tokens": 125512065, "ops": 129007141, "last_height": 972199}], "largest": {"as_of": {"appendix": 972199, "books": 972199, "census": 972232, "labels": 972103, "ranking": 972232}, "rows": ["…"]} } ``` The feed's newest entry is "Edition of Tuesday 20 October 2026", summarised "67 blocks, 115 MB of blockspace; rune added the most attributed blockspace". ## blockspace.markets and the buy board blockspace.markets is a static page rebuilt every 10 minutes from [the buy board](https://blockspace.wiki/glossary/buy-board/). It publishes no data file of its own. Its data is the board's API, served by block.space under `/buy/`: - `https://block.space/buy/api/board`: listings ranked by price per kilobyte, `{rows, total, denom}`; - `https://block.space/buy/api/status`: the venue syncs, one row per venue run. The first row of the board, read at 09:46 UTC, trimmed: ```json { "total": 167648, "denom": "sats_per_kb", "rows": [{"category": "inscription", "venue": "gamma", "price_sats": 1000, "quantity": "1", "grade": "ask", "bytes": 26108, "vbytes": 6577, "book": "A", "denominator_source": "bti-book:964799", "sats_per_kb": 38.30243603493182, "sats_per_kvb": 152.0450053215752, "settlement_kind": "psbt"}] } ``` `bytes` is the asset's blockspace in the named book, read at the height in `denominator_source`; `sats_per_kb` is the price over those bytes ([sats per kB](https://blockspace.wiki/glossary/sats-per-kb/)). The board also takes `POST` requests for its wallet buy flow; those are not data endpoints. ## counters.gallery: /status and the counter API The Counters server is "the web explorer + read-only JSON API". Its `/status` names the index height and the build. `https://counters.gallery/status`, read at 09:47 UTC: ```json {"indexed": 972303, "count": 554, "genesis": 0, "version": "11.5.0", "commit": "dev", "updated": null, "preview_origin": null} ``` `version` mirrors the Counterparty Core release the build targets (11.5 here). `count` is the number of [counters](https://blockspace.wiki/glossary/counter/) indexed. The server's code also answers `/counters` (a list, with paging and filters), `/counter/`, `/facets`, `/search` and `/block/` with JSON. From `https://counters.gallery/counter/0`, trimmed: ```json {"number": 0, "id": "efeb4f6ad804a6716334de029788a1002933325f86c1e99132b32347ac6d7503i0", "asset": "XDUALS", "kind": "issuance", "content_type": "text/plain", "size": 8, "envelope": "counterparty/ord", "original": true, "block": 902005} ``` The README documents `/status` only; the other routes are read from the code and may change without notice. ## scribb.it: facts.json (coming soon) The [Scribbit](https://blockspace.wiki/glossary/scribbit/) site is coming soon as of 2026-10-20. Once its domain is public it will serve `https://scribb.it/facts.json`: every figure on the site with its source, plus its glossary. The current file has the keys `built_at`, `fees` (from explore.block.space's fee API, in sat/vB), `ord` (from ord's `/status`), `example` (one PDF inscription with its fee, size and Book A, B and C bytes), `largest` (the largest inscription), `policy` (Bitcoin Core 28.2.0's standard transaction weight, 400,000, and script element size, 520), `glossary` and `note`. Each block names its own `source`. As built at 09:36 UTC its fee block read, without the source line: ```json {"as_of": "2026-10-20T09:36:44Z", "unit": "sat/vB", "economy": 1, "hour": 1, "fastest": 2, "next_block_median": 1.03} ``` Sources: - Blockspace Holdings records - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - The blockspace.news site: README, tools/build.py and the editions · https://blockspace.news - The blockspace.markets site: README, tools/build.py and the page · https://blockspace.markets - block.space buy board API (/buy/api/board, /buy/api/status) · https://block.space/buy/api/board - Bitcoin Counters v3, indexer and wallet: README (BitcoinCounters/counters) · https://github.com/BitcoinCounters/counters - The counters server /status (the index behind counters.gallery) · https://counters.gallery/status - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # alkane URL: https://blockspace.wiki/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # anti-battery URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # appropriated field URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes Updated: 2026-10-20 --- # ARC-20 URL: https://blockspace.wiki/glossary/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". Sources: - Blockspace Holdings records - block.space docs: Atomicals · https://block.space/docs/atomicals Updated: 2026-10-20 --- # Architecture Decision Record URL: https://blockspace.wiki/glossary/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. Sources: - DegentClub/degent GOVERNANCE · https://github.com/DegentClub/degent Updated: 2026-10-20 --- # archival node URL: https://blockspace.wiki/glossary/archival-node/ A Bitcoin full node that keeps every block, as opposed to a pruned node, which discards old block data. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # as of block H URL: https://blockspace.wiki/glossary/as-of-block-h/ The caption rule every block.space ranking follows. H is the one block the [holders appendix](https://blockspace.wiki/glossary/the-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. Sources: - block.space docs: rankings · https://block.space/docs/rankings - Blockspace Holdings records Updated: 2026-10-20 --- # Atelier URL: https://blockspace.wiki/glossary/atelier/ A section of the degent.club website and a service in the Degent code. Its code renders the Degent [frame and placard](https://blockspace.wiki/glossary/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. Sources: - DegentClub/degent ART-AND-TRADEMARKS · https://github.com/DegentClub/degent - Blockspace Holdings records Updated: 2026-10-20 --- # Atomicals container URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # Atomicals realm URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # attempt URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - block.space docs: BTI · https://block.space/docs/bti Updated: 2026-10-20 --- # attribution URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/the-appendix/)'s work. Sources: - block.space docs: BTI · https://block.space/docs/bti - Blockspace Holdings records Updated: 2026-10-20 --- # backing ratio URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: BYTES · https://block.space/docs/bytes - block.space docs: BTP · https://block.space/docs/btp - Blockspace Holdings records Updated: 2026-10-20 --- # backing succession URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: BTP · https://block.space/docs/btp - block.space docs: the axiom · https://block.space/docs/axiom Updated: 2026-10-20 --- # backing URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/carriage/), measured in full and never backing. A failed operation whose failure the protocol's own ledger records still bought its blockspace, and those bytes count as backing. Failed demand that left no record in any protocol's ledger is measured separately and is never backing. Sources: - block.space docs: BTI · https://block.space/docs/bti Updated: 2026-10-20 --- # bare multisig URL: https://blockspace.wiki/glossary/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. The output shape alone cannot tell fake keys from real ones; the reference confirms a carrier by decrypting it (ARC4) and testing for the `stamp:` or `CNTRPRTY` prefix, then attributes the full output serialization. Sources: - block.space docs: data types · https://block.space/docs/datatypes Updated: 2026-10-20 --- # batch URL: https://blockspace.wiki/glossary/batch/ Several inscriptions written by one [commit transaction](https://blockspace.wiki/glossary/reveal-transaction/) and one [reveal transaction](https://blockspace.wiki/glossary/reveal-transaction/), sharing their fixed cost. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # Bitbar URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - The blockspace.holdings page (site/index.html) · https://blockspace.holdings Updated: 2026-10-20 --- # Bitcoin L1 URL: https://blockspace.wiki/glossary/bitcoin-l1/ Bitcoin's base layer: the blockchain itself, not a sidechain or second-layer network. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # Bitcoin Stamp URL: https://blockspace.wiki/glossary/bitcoin-stamp/ A [Counterparty](https://blockspace.wiki/glossary/counterparty/) asset whose description carries a file, written into output-side carriers: [bare multisig](https://blockspace.wiki/glossary/bare-multisig/) at first, [OLGA](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md Updated: 2026-10-20 --- # Bitmap URL: https://blockspace.wiki/glossary/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." BTI's token catalogue has its own entry, "bitmap sats": an inscription that is a district claim, where the token is the inscribed sat and the district number is a label on it, under [Ordinal Sats](https://blockspace.wiki/glossary/ordinal-sats/). Sources: - bitmap.holdings, its own home page, read 2026-10-20 · https://bitmap.holdings - Blockspace Holdings records Updated: 2026-10-20 --- # block subsidy URL: https://blockspace.wiki/glossary/block-subsidy/ The part of a miner's revenue for a [block](https://blockspace.wiki/glossary/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. Sources: - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # block URL: https://blockspace.wiki/glossary/block/ A batch of [transactions](https://blockspace.wiki/glossary/transaction/) 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](https://blockspace.wiki/glossary/weight-unit/). The chain is every block from the genesis block forward. Sources: - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: BTI · https://block.space/docs/bti - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # blockspace asset URL: https://blockspace.wiki/glossary/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. Sources: - The blockspace.holdings page (site/index.html) · https://blockspace.holdings - Blockspace Holdings records Updated: 2026-10-20 --- # Blockspace Floor Price URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - Blockspace Holdings records Updated: 2026-10-20 --- # Blockspace Holdings' node and indexers URL: https://blockspace.wiki/glossary/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. Sources: - block.space meter and summary APIs · https://block.space/api/summary - ord /status (the blockspace.to ord server) · https://blockspace.to/status - block.space docs: BTI · https://block.space/docs/bti Updated: 2026-10-20 --- # Blockspace Holdings URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - The project list at block.space/projects · https://block.space/projects - The blockspace.holdings page (site/index.html) · https://blockspace.holdings Updated: 2026-10-20 --- # Blockspace Labs URL: https://blockspace.wiki/glossary/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. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records - The project list at block.space/projects · https://block.space/projects Updated: 2026-10-20 --- # blockspace token URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: the axiom · https://block.space/docs/axiom Updated: 2026-10-20 --- # blockspace URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: BTI · https://block.space/docs/bti Updated: 2026-10-20 --- # Book A URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/shared-claim-axiom/). In the [partition](https://blockspace.wiki/glossary/the-partition/) it is content + structure + overhead, "bytes bought for you at all", and it is the backing measure. Fees follow Book A. On every entry C ≤ B ≤ A, so Book A is the widest of the three books. Sources: - Blockspace Holdings records - block.space docs: BTI · https://block.space/docs/bti Updated: 2026-10-20 --- # Book B URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/the-partition/) it is content + structure, "bytes bought exclusively for you". A null in the regional book means not measured, never zero. Sources: - Blockspace Holdings records - block.space docs: BTI · https://block.space/docs/bti - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # Book C URL: https://blockspace.wiki/glossary/book-c/ The content book: the artifact bytes alone, the body of the file or message with all framing removed. In the [partition](https://blockspace.wiki/glossary/the-partition/) it is content only, "the artifact itself". A protocol that carries no artifact body measures zero in the content book, and that measured zero is not a missing measurement. Sources: - Blockspace Holdings records - block.space docs: BTI · https://block.space/docs/bti - block.space docs: measurements · https://block.space/docs/measurements Updated: 2026-10-20 --- # book entry URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # bounty URL: https://blockspace.wiki/glossary/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". Sources: - Devcash site copy, from the reference clone (locales/en.json) · https://devcash.dev Updated: 2026-10-20 --- # BRC-20 tick URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # BTI URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: BTI · https://block.space/docs/bti Updated: 2026-10-20 --- # BTP URL: https://blockspace.wiki/glossary/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](/concepts/btp/). Sources: - block.space docs: BTP · https://block.space/docs/btp - BTP, the Blockspace Token Protocol, draft 0.1 · https://block.space/docs/btp Updated: 2026-10-20 --- # burned bytes URL: https://blockspace.wiki/glossary/burned-bytes/ One of the four categories every block's bytes divide into: bytes that backed tokens that were provably destroyed. Sources: - block.space docs: BTI · https://block.space/docs/bti - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # the buy board URL: https://blockspace.wiki/glossary/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. Sources: - The blockspace.markets site: README, tools/build.py and the page · https://blockspace.markets - Blockspace Holdings records Updated: 2026-10-20 --- # BVT URL: https://blockspace.wiki/glossary/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](/concepts/blockspace-value-theory/). Sources: - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # BYTES URL: https://blockspace.wiki/glossary/bytes-token/ 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](/concepts/bytes/). Sources: - block.space docs: BYTES · https://block.space/docs/bytes - BYTES, a fungible blockspace token, draft 0.2 · https://block.space/docs/bytes Updated: 2026-10-20 --- # carriage URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/conservation/) partition. Sources: - block.space docs: BTI · https://block.space/docs/bti - Blockspace Holdings records Updated: 2026-10-20 --- # CAT-21 URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes Updated: 2026-10-20 --- # cenotaph URL: https://blockspace.wiki/glossary/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`. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # citation URL: https://blockspace.wiki/glossary/citation/ What a writer keeps after writing an [inscription](https://blockspace.wiki/glossary/inscription/): its [inscription id](https://blockspace.wiki/glossary/inscription-id/), block, [content type](https://blockspace.wiki/glossary/content-type/), length and [SHA-256](https://blockspace.wiki/glossary/sha-256/) hash. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # claimed bytes URL: https://blockspace.wiki/glossary/claimed-bytes/ One of the four categories every block's bytes divide into: bytes that back a living token. With [carriage](https://blockspace.wiki/glossary/carriage/), [burned bytes](https://blockspace.wiki/glossary/burned-bytes/) and [unclaimed bytes](https://blockspace.wiki/glossary/unclaimed-bytes/) they sum to the block's exact size. Sources: - block.space docs: BTI · https://block.space/docs/bti - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # claims URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/the-books/). Sources: - Blockspace Holdings records - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # clean-mint rule URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: BYTES · https://block.space/docs/bytes Updated: 2026-10-20 --- # coinbase transaction URL: https://blockspace.wiki/glossary/coinbase-transaction/ The first transaction of every [block](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/lost-sats/). Sources: - block.space docs: data types · https://block.space/docs/datatypes - The blockspacelabs.com page (index.html) · https://blockspacelabs.com Updated: 2026-10-20 --- # concealed co-claim URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: BTP · https://block.space/docs/btp - block.space docs: BYTES · https://block.space/docs/bytes Updated: 2026-10-20 --- # confirmation URL: https://blockspace.wiki/glossary/confirmation/ A block containing the transaction. Each later block adds one more. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # consensus hash URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # consequence principle URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: the axiom · https://block.space/docs/axiom - Blockspace Holdings records Updated: 2026-10-20 --- # conservation URL: https://blockspace.wiki/glossary/conservation/ "Every byte counted exactly once." Each block partitions into four categories, [claimed](https://blockspace.wiki/glossary/claimed-bytes/), [carriage](https://blockspace.wiki/glossary/carriage/), [burned](https://blockspace.wiki/glossary/burned-bytes/) and [unclaimed](https://blockspace.wiki/glossary/unclaimed-bytes/), 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. Sources: - block.space docs: BTI · https://block.space/docs/bti - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # content type URL: https://blockspace.wiki/glossary/content-type/ The label stored with a [payload](https://blockspace.wiki/glossary/payload/) (such as application/pdf) that tells readers how to open it. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # counter URL: https://blockspace.wiki/glossary/counter/ A Bitcoin Counter is "a numbered file event": a file committed to Bitcoin as the description of a [Counterparty](https://blockspace.wiki/glossary/counterparty/) asset, carried in a [Counterparty taproot envelope](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/fairminter/) deploy, and they reached the chain inside [witness data](https://blockspace.wiki/glossary/witness/). Either test alone is nothing. Counter #0 is XDUALS, at block 902,005, five blocks after Counterparty's taproot activation at block 902,000. The protocol adds nothing on chain: it is a numbering lens over events Counterparty already parses. Sources: - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md - Bitcoin Counters v3, indexer and wallet: README (BitcoinCounters/counters) · https://github.com/BitcoinCounters/counters Updated: 2026-10-20 --- # Counterparty DEX URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/liquidity-pool/). Sources: - Bitcoin Counters v3, indexer and wallet: README (BitcoinCounters/counters) · https://github.com/BitcoinCounters/counters - counters.fun README (BitcoinCounters/counters.fun) · https://github.com/BitcoinCounters/counters.fun Updated: 2026-10-20 --- # counterparty + ord URL: https://blockspace.wiki/glossary/counterparty-plus-ord/ The style of [Counterparty taproot envelope](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/inscription/) on its own output. The stored value is `counterparty/ord`. The first five [counters](https://blockspace.wiki/glossary/counter/) are all this style. Sources: - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md Updated: 2026-10-20 --- # Counterparty URL: https://blockspace.wiki/glossary/counterparty/ The protocol whose assets carry [counters](https://blockspace.wiki/glossary/counter/). For counters it supplies identity, ownership, naming, transfer and, since its v11 [taproot envelope](https://blockspace.wiki/glossary/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.) Sources: - Bitcoin Counters v3, indexer and wallet: README (BitcoinCounters/counters) · https://github.com/BitcoinCounters/counters - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md - Blockspace Holdings records Updated: 2026-10-20 --- # coverage URL: https://blockspace.wiki/glossary/coverage/ The share of [Book A](https://blockspace.wiki/glossary/book-a/) bytes the [leaderboard](https://blockspace.wiki/glossary/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. Sources: - block.space docs: rankings · https://block.space/docs/rankings - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # cursed inscription URL: https://blockspace.wiki/glossary/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. Sources: - ord /status (the blockspace.to ord server) · https://blockspace.to/status - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records Updated: 2026-10-20 --- # cursor URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # decay-by-amnesia URL: https://blockspace.wiki/glossary/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". Sources: - block.space docs: Atomicals · https://block.space/docs/atomicals - block.space docs: the axiom · https://block.space/docs/axiom Updated: 2026-10-20 --- # decentralization constraint URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # Decentralized Gentlemen Club URL: https://blockspace.wiki/glossary/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). Its README calls it a collection of inscriptions plus "the 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" (the [Degent mint](https://blockspace.wiki/glossary/degent-mint/)). The name is one of the marks in the project's trademark policy and is not licensed. Sources: - The project list at block.space/projects · https://block.space/projects - DegentClub/degent README · https://github.com/DegentClub/degent - DegentClub/degent TRADEMARKS · https://github.com/DegentClub/degent - Blockspace Holdings records Live figures: degent as of 2026-09-25 23:24:51 UTC Updated: 2026-10-20 --- # dedicated URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: BTI · https://block.space/docs/bti - Blockspace Holdings records Updated: 2026-10-20 --- # Degent mint URL: https://blockspace.wiki/glossary/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". Sources: - DegentClub/degent README · https://github.com/DegentClub/degent - Blockspace Holdings records Updated: 2026-10-20 --- # Degent URL: https://blockspace.wiki/glossary/degent/ A Degent is an [inscription](https://blockspace.wiki/glossary/inscription/) in the [Decentralized Gentlemen Club](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/frame-and-placard/)). The collection is 10,000 when fully minted: 4,112 inscribed (as of 2026-09-25 23:24:51 UTC). The name "Degent" and the Degent artwork are not licensed; all rights are reserved. Sources: - Blockspace Holdings records - DegentClub/degent README · https://github.com/DegentClub/degent - DegentClub/degent ART-AND-TRADEMARKS · https://github.com/DegentClub/degent Live figures: degent as of 2026-09-25 23:24:51 UTC Updated: 2026-10-20 --- # delegate inscription URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: rankings · https://block.space/docs/rankings - Blockspace Holdings records Updated: 2026-10-20 --- # Devcash URL: https://blockspace.wiki/glossary/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. Sources: - Devcash site copy, from the reference clone (locales/en.json) · https://devcash.dev - The project list at block.space/projects · https://block.space/projects Updated: 2026-10-20 --- # dispenser URL: https://blockspace.wiki/glossary/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. Sources: - Bitcoin Counters v3, indexer and wallet: README (BitcoinCounters/counters) · https://github.com/BitcoinCounters/counters - counters.fun README (BitcoinCounters/counters.fun) · https://github.com/BitcoinCounters/counters.fun Updated: 2026-10-20 --- # dust claim URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: the axiom · https://block.space/docs/axiom Updated: 2026-10-20 --- # edict URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # edition URL: https://blockspace.wiki/glossary/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. Sources: - The blockspace.news site: README, tools/build.py and the editions · https://blockspace.news - Blockspace Holdings records Updated: 2026-10-20 --- # enabler URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # envelope URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: data types · https://block.space/docs/datatypes - Blockspace Holdings records Updated: 2026-10-20 --- # etching URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # explore.block.space URL: https://blockspace.wiki/glossary/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). Sources: - Blockspace Holdings records - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # fairminter URL: https://blockspace.wiki/glossary/fairminter/ A Counterparty message that deploys a fair-minted asset. A fairminter deploy whose description is a file is itself a [counter](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/liquidity-pool/) at soft cap with every satoshi it raised, minting the [LP tokens](https://blockspace.wiki/glossary/lp-token/) to the unspendable address. Sources: - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md - counters.fun README (BitcoinCounters/counters.fun) · https://github.com/BitcoinCounters/counters.fun Updated: 2026-10-20 --- # fee floor URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/) runs with minrelaytxfee=0. Sources: - Blockspace Holdings records - The blockspacelabs.com page (index.html) · https://blockspacelabs.com Updated: 2026-10-20 --- # fee rate URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: data types · https://block.space/docs/datatypes - Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # five-colour family key URL: https://blockspace.wiki/glossary/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. Since 2026-10-20 each leaderboard bar runs largest family first, and the key row above the table lists families by their share of the page. Sources: - Blockspace Holdings records - block.space docs: rankings · https://block.space/docs/rankings - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # frame and placard URL: https://blockspace.wiki/glossary/frame-and-placard/ The ornamental gold picture frame and the placard reading `DEGEN`, `DEGENT` or `REGEN` that every [Degent](https://blockspace.wiki/glossary/degent/) carries. The club's minting rules require it ("Must be framed and include a placard"), and the [Degent mint](https://blockspace.wiki/glossary/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. Sources: - DegentClub/degent ART-AND-TRADEMARKS · https://github.com/DegentClub/degent - Blockspace Holdings records Updated: 2026-10-20 --- # free-ride index URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: measurements · https://block.space/docs/measurements - Blockspace Holdings records Updated: 2026-10-20 --- # full-RBF URL: https://blockspace.wiki/glossary/full-rbf/ A relay policy setting of a Bitcoin node (fullrbf), about replacing unconfirmed transactions. [Blockspace Holdings' own Bitcoin node](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/) runs with it on; the Labs study "Full-RBF in practice" proposes to count the replacements its mempool sees. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # heaviest tokens board URL: https://blockspace.wiki/glossary/heaviest-tokens-board/ block.space/heaviest-tokens: the 100,000 heaviest tokens by [Book A](https://blockspace.wiki/glossary/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. Sources: - block.space docs: rankings · https://block.space/docs/rankings - Blockspace Holdings records - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # Hodl URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - The blockspace.holdings page (site/index.html) · https://blockspace.holdings Updated: 2026-10-20 --- # holder URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - block.space docs: rankings · https://block.space/docs/rankings Updated: 2026-10-20 --- # indexer URL: https://blockspace.wiki/glossary/indexer/ Software that reads every block and builds a searchable view of it. [ord](https://blockspace.wiki/glossary/ord/) is the indexer for inscriptions. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # initial bounty offering URL: https://blockspace.wiki/glossary/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. Sources: - Devcash site copy, from the reference clone (locales/en.json) · https://devcash.dev Updated: 2026-10-20 --- # inscription id URL: https://blockspace.wiki/glossary/inscription-id/ The reveal's transaction id, then the letter i, then the inscription's position in that transaction. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # inscription URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - block.space docs: rankings · https://block.space/docs/rankings Updated: 2026-10-20 --- # label URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # largest inscriptions board URL: https://blockspace.wiki/glossary/largest-inscriptions-board/ block.space/largest-inscriptions: the 100,000 largest inscriptions by content bytes ([Book C](https://blockspace.wiki/glossary/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. Sources: - block.space docs: rankings · https://block.space/docs/rankings - Blockspace Holdings records - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # lazy consensus URL: https://blockspace.wiki/glossary/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. Sources: - DegentClub/degent GOVERNANCE · https://github.com/DegentClub/degent Updated: 2026-10-20 --- # liquidity pool URL: https://blockspace.wiki/glossary/liquidity-pool/ A constant-product reserve pair on [Counterparty](https://blockspace.wiki/glossary/counterparty/), with its own [LP token](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counter/) that have pools against XCP. Sources: - counters.fun README (BitcoinCounters/counters.fun) · https://github.com/BitcoinCounters/counters.fun - Bitcoin Counters v3, indexer and wallet: README (BitcoinCounters/counters) · https://github.com/BitcoinCounters/counters Updated: 2026-10-20 --- # Litebars URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - The blockspacelabs.com page (index.html) · https://blockspacelabs.com Updated: 2026-10-20 --- # Litepedia URL: https://blockspace.wiki/glossary/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. Sources: - The project list at block.space/projects · https://block.space/projects - Blockspace Holdings records Updated: 2026-10-20 --- # lost sats URL: https://blockspace.wiki/glossary/lost-sats/ Sats that coinbase transactions never claimed, so they exist in no output. ord's /status counts them. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - ord /status (the blockspace.to ord server) · https://blockspace.to/status Updated: 2026-10-20 --- # LP token URL: https://blockspace.wiki/glossary/lp-token/ The token a Counterparty [liquidity pool](https://blockspace.wiki/glossary/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. Sources: - Bitcoin Counters v3, indexer and wallet: README (BitcoinCounters/counters) · https://github.com/BitcoinCounters/counters - counters.fun README (BitcoinCounters/counters.fun) · https://github.com/BitcoinCounters/counters.fun Updated: 2026-10-20 --- # machine surfaces URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - blockspace.wiki README · https://blockspace.wiki Updated: 2026-10-20 --- # mempool URL: https://blockspace.wiki/glossary/mempool/ The waiting room of unconfirmed transactions that miners choose from. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # metaprotocol adapter URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # metaprotocol indexer URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # metashrew URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # native protocol URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # non-custodial URL: https://blockspace.wiki/glossary/non-custodial/ Never holding the user's funds or keys: the user's own wallet funds and signs. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # not measured URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: rankings · https://block.space/docs/rankings - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # OLGA URL: https://blockspace.wiki/glossary/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. In the July 2026 measurement run, OLGA made Stamps' cost per content byte 1.84 times cheaper than [bare multisig](https://blockspace.wiki/glossary/bare-multisig/), and the mean file grew from 366 B to 3,421 B. Sources: - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: measurements · https://block.space/docs/measurements Updated: 2026-10-20 --- # Omni property URL: https://blockspace.wiki/glossary/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". Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # OP_RETURN URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: data types · https://block.space/docs/datatypes Updated: 2026-10-20 --- # OPI URL: https://blockspace.wiki/glossary/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". Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # ord URL: https://blockspace.wiki/glossary/ord/ The ordinals indexer and explorer. Its fork, run by [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/), serves blockspace.to and is the definitional source for BTI's inscription-to-sat binding, sat numbers and inscription numbers. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # ordinal number URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # Ordinal Sats URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # payload URL: https://blockspace.wiki/glossary/payload/ The file being written into an [inscription](https://blockspace.wiki/glossary/inscription/). Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # pointer counter URL: https://blockspace.wiki/glossary/pointer-counter/ A [counter](https://blockspace.wiki/glossary/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. Sources: - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md - Counters server: rendering rules · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/rules.md - counters.fun README (BitcoinCounters/counters.fun) · https://github.com/BitcoinCounters/counters.fun Updated: 2026-10-20 --- # price per KB URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. Sources: - counters.fun README (BitcoinCounters/counters.fun) · https://github.com/BitcoinCounters/counters.fun Updated: 2026-10-20 --- # protostone URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes Updated: 2026-10-20 --- # rankings URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/book-c/)), tokens by what they bought ([Book A](https://blockspace.wiki/glossary/book-a/)), and addresses by the blockspace behind what they hold. On 2026-10-20 the live index lists four boards: the [leaderboard](https://blockspace.wiki/glossary/the-leaderboard/), the [largest inscriptions](https://blockspace.wiki/glossary/largest-inscriptions-board/), the [heaviest tokens](https://blockspace.wiki/glossary/heaviest-tokens-board/) and the largest collections, which showed nothing ranked yet. Sources: - block.space docs: rankings · https://block.space/docs/rankings - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space - Blockspace Holdings records Updated: 2026-10-20 --- # raw bytes URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: data types · https://block.space/docs/datatypes - Blockspace Holdings records Updated: 2026-10-20 --- # Readings A, B and C URL: https://blockspace.wiki/glossary/readings-a-b-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. Sources: - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # recursive inscription URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Value Theory · https://block.space/docs/bvt - The blockspacelabs.com page (index.html) · https://blockspacelabs.com Updated: 2026-10-20 --- # reinscription URL: https://blockspace.wiki/glossary/reinscription/ New content attached to a [Counterparty](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. Sources: - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md - counters.fun README (BitcoinCounters/counters.fun) · https://github.com/BitcoinCounters/counters.fun Updated: 2026-10-20 --- # reorg URL: https://blockspace.wiki/glossary/reorg/ When a competing chain replaces recent blocks, undoing their confirmations. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # replacement ceiling URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # residue URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # reveal transaction URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counter/) is keyed to. An unrevealed commit is nothing. Sources: - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md Updated: 2026-10-20 --- # rolling hash URL: https://blockspace.wiki/glossary/rolling-hash/ How independent counters indexers check that they agree. Each [counter](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/consensus-hash/). Sources: - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md Updated: 2026-10-20 --- # ruleset URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # rune URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: measurements · https://block.space/docs/measurements - ord /status (the blockspace.to ord server) · https://blockspace.to/status Updated: 2026-10-20 --- # sat name URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # sat URL: https://blockspace.wiki/glossary/sat/ One hundred-millionth of a bitcoin, the unit fees are paid in. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # sats per kB URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/book-a/)), per kilobyte (1 kB = 1,000 B). A listing is an offer, not a sale. Sources: - The blockspace.markets site: README, tools/build.py and the page · https://blockspace.markets - Blockspace Holdings records Updated: 2026-10-20 --- # Scribbit URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - The project list at block.space/projects · https://block.space/projects Updated: 2026-10-20 --- # second-source adapter URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # SHA-256 URL: https://blockspace.wiki/glossary/sha-256/ A cryptographic hash. The same file always gives the same 64-character hash, and any change gives a different one. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # share of backing URL: https://blockspace.wiki/glossary/share-of-backing/ What an address holds on the [leaderboard](https://blockspace.wiki/glossary/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. Sources: - block.space docs: rankings · https://block.space/docs/rankings - Blockspace Holdings records - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # Shared Claim Axiom URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: the axiom · https://block.space/docs/axiom - block.space docs: BTI · https://block.space/docs/bti Updated: 2026-10-20 --- # sighting URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # Space Blocks URL: https://blockspace.wiki/glossary/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. Sources: - The spaceblocks.art site: README, index.html, whole-blocks/ and tools/build.py · https://spaceblocks.art - Blockspace Holdings records Updated: 2026-10-20 --- # spent sats URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - The blockspacelabs.com page (index.html) · https://blockspacelabs.com Updated: 2026-10-20 --- # spiderweb URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # standard transaction URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: data types · https://block.space/docs/datatypes - Blockspace Holdings records Updated: 2026-10-20 --- # sub-1 sat/vB relay URL: https://blockspace.wiki/glossary/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. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records Updated: 2026-10-20 --- # Counterparty taproot envelope URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/reveal-transaction/) pair. The message, an asset's description included, travels as data pushes in the reveal's input-0 [witness](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/counterparty-plus-ord/) envelope, and both carry [counters](https://blockspace.wiki/glossary/counter/) equally. Before it, Counterparty messages stayed output-side and small (OP_RETURN, bare multisig, P2SH), so an asset description could not hold a file. That is why counters begin at block 902,000. Sources: - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md - Counters notes · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/notes.md Updated: 2026-10-20 --- # Taproot URL: https://blockspace.wiki/glossary/taproot/ The 2021 Bitcoin upgrade whose script-path spends carry inscription envelopes. Sources: - Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json) · https://scribb.it/facts.json Updated: 2026-10-20 --- # the appendix URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - block.space docs: rankings · https://block.space/docs/rankings Updated: 2026-10-20 --- # the books URL: https://blockspace.wiki/glossary/the-books/ T3, BTI's accounting layer, and what it writes: [Book A](https://blockspace.wiki/glossary/book-a/), [Book B](https://blockspace.wiki/glossary/book-b/) and [Book C](https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - block.space docs: BTI · https://block.space/docs/bti - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # the census URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # the frontier URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - block.space frontier API (the three tier cursors and the chain tip) · https://block.space/api/frontier Updated: 2026-10-20 --- # the leaderboard URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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. Sources: - block.space docs: rankings · https://block.space/docs/rankings - Blockspace Holdings records - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # the Meter URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/bti/) and is bounded by the height the books are written to. The site's footer says every figure is read live from the books, and nothing is modelled, extrapolated or filled in. Where a measurement does not exist yet, the site says so instead of showing a zero. Sources: - The project list at block.space/projects · https://block.space/projects - block.space docs: BTI · https://block.space/docs/bti - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # the one envelope URL: https://blockspace.wiki/glossary/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. It is not the inscription [envelope](https://blockspace.wiki/glossary/envelope/), the data carrier inside a taproot witness. Sources: - Blockspace Holdings records - block.space JSON API, read-only GETs (every /api/* endpoint) · https://block.space/api/summary Updated: 2026-10-20 --- # the partition URL: https://blockspace.wiki/glossary/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. Because the books are built by addition, C ≤ B ≤ A holds by construction. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # the three books URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records - block.space docs: BTI · https://block.space/docs/bti Updated: 2026-10-20 --- # tokenized blockspace URL: https://blockspace.wiki/glossary/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. Sources: - The Shared Claim Axiom · https://block.space/docs/axiom - Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # transaction URL: https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/witness/) stack per input. The txid hashes the transaction without its witness; the wtxid hashes all of it. Sources: - block.space docs: data types · https://block.space/docs/datatypes Updated: 2026-10-20 --- # trust triad URL: https://blockspace.wiki/glossary/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). Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # two-step transfer URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Holdings records Updated: 2026-10-20 --- # unclaimed bytes URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: BTI · https://block.space/docs/bti - block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync) · https://block.space Updated: 2026-10-20 --- # vbytes URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: BTI · https://block.space/docs/bti Updated: 2026-10-20 --- # weight unit URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: data types · https://block.space/docs/datatypes - Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # whole-block URL: https://blockspace.wiki/glossary/whole-block/ block.space's size class for an [inscription](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/space-blocks/) itself, at 1,047,584 bytes, fills a 1 MB block and is below this class. Sources: - Blockspace Holdings records - The spaceblocks.art site: README, index.html, whole-blocks/ and tools/build.py · https://spaceblocks.art Updated: 2026-10-20 --- # witness discount URL: https://blockspace.wiki/glossary/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. Sources: - Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: measurements · https://block.space/docs/measurements Updated: 2026-10-20 --- # witness URL: https://blockspace.wiki/glossary/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. Sources: - block.space docs: data types · https://block.space/docs/datatypes Updated: 2026-10-20 --- # XCP asset URL: https://blockspace.wiki/glossary/xcp-asset/ An asset in the [Counterparty](https://blockspace.wiki/glossary/counterparty/) ledger. BTI's token catalogue calls XCP assets "the first blockspace tokens (2014)", counts XCP itself as one, and lists [counters](https://blockspace.wiki/glossary/counter/) as a subset. An asset's description can hold a file; when it reaches the chain in a [Counterparty taproot envelope](https://blockspace.wiki/glossary/taproot-envelope/), that description is a counter. On counters.fun's mint page, a named asset burns 0.5 XCP. Sources: - Blockspace Holdings records - Bitcoin Counters build reference v3 · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md - counters.fun README (BitcoinCounters/counters.fun) · https://github.com/BitcoinCounters/counters.fun Updated: 2026-10-20 --- # How many Degents are there? 10,000 when fully minted, beside the live inscribed count. URL: https://blockspace.wiki/answers/how-many-degents-are-there/ The Degent Club collection is 10,000 when fully minted: 4,112 inscribed (as of 2026-09-25 23:24:51 UTC). Each [Degent](https://blockspace.wiki/glossary/degent/) is an [inscription](https://blockspace.wiki/glossary/inscription/) of a Pepe in a tuxedo. Older pages have shown other counts: the site's rebuild specification records 4,027 minted on the old site and 4,113 in an internal analysis, against the collection list's 4,112. Sources: - Blockspace Holdings records - DegentClub/degent README · https://github.com/DegentClub/degent - The project list at block.space/projects · https://block.space/projects Live figures: degent as of 2026-09-25 23:24:51 UTC Updated: 2026-10-20 --- # How much of Bitcoin's blockspace do tokens use? The live share of chain bytes the books attribute to tokens, with its height. URL: https://blockspace.wiki/answers/how-much-blockspace-do-tokens-use/ In [Book A](https://blockspace.wiki/glossary/book-a/), the widest of BTI's books, tokens are attributed 133.75 GB, which is 17.21 % of the 777.04 GB of chain bytes the books cover (as of block 972,299, 2026-10-20 09:30:48 UTC). The narrowest, [Book C](https://blockspace.wiki/glossary/book-c/), file and message bodies alone, holds 4.68 %. In the July 2026 measurement run, data payload peaked at 45.4% of block bytes, at height 833,000. Sources: - block.space meter and summary APIs · https://block.space/api/summary - block.space docs: BTI · https://block.space/docs/bti - block.space docs: measurements · https://block.space/docs/measurements Live figures: books as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # What are Book A, B and C? BTI's three answers to how many bytes back a token, from widest to narrowest. URL: https://blockspace.wiki/answers/what-are-book-a-b-and-c/ They are BTI's three answers to how many bytes back a token. [Book C](https://blockspace.wiki/glossary/book-c/), the content book, counts the artifact bytes alone. [Book B](https://blockspace.wiki/glossary/book-b/), the regional book, adds the structure the token's operations wrote, read or moved through. [Book A](https://blockspace.wiki/glossary/book-a/), the inclusive book, counts whole transactions bought for the token, shared where shared. On every entry, C ≤ B ≤ A. Sources: - Blockspace Holdings records - block.space docs: BTI · https://block.space/docs/bti Updated: 2026-10-20 --- # What are spent sats? The sat ranges of already-spent outputs, which blockspace.to's ord fork keeps. URL: https://blockspace.wiki/answers/what-are-spent-sats/ Here, [spent sats](https://blockspace.wiki/glossary/spent-sats/) means the sat ranges of outputs that have already been spent. blockspace.to, a Blockspace Labs product, runs a fork of ord with --index-spent-sats, so a spent output still answers with its sat ranges; an ord without that flag cannot. BTI's August 2026 handoff notes name CAT-21 as the only normal-operation consumer of those ranges. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records - The project list at block.space/projects · https://block.space/projects Updated: 2026-10-20 --- # What does "as of block H" mean? Every block.space figure names the block height it is synchronised to. URL: https://blockspace.wiki/answers/what-does-as-of-block-h-mean/ Every block.space figure is bounded by a block height. "[as of block H](https://blockspace.wiki/glossary/as-of-block-h/)" names the one block, H, that figures are synchronised to; where a ranking or the books sit at another height, pages name those too. A number without its height is not shown. The books stand at block 972,299 and the chain tip at 972,304 (as of block 972,301, 2026-10-20 09:35:17 UTC). Sources: - block.space docs: rankings · https://block.space/docs/rankings - block.space frontier API (the three tier cursors and the chain tip) · https://block.space/api/frontier Live figures: frontier as of block 972,301, 2026-10-20 09:35:17 UTC Updated: 2026-10-20 --- # What does "not measured" mean? No figure exists for that thing yet; block.space writes it in words, never as 0. URL: https://blockspace.wiki/answers/what-does-not-measured-mean/ The instrument has no figure for that thing: a book not measured for a protocol, a sat the record has not bound to an inscription, a holder the appendix cannot see. block.space writes these in words, never as 0. A zero is a measured zero, such as a protocol with no artifact body measuring zero in [Book C](https://blockspace.wiki/glossary/book-c/). Sources: - block.space docs: rankings · https://block.space/docs/rankings - block.space docs: measurements · https://block.space/docs/measurements Updated: 2026-10-20 --- # What is a rune? A fungible token whose operations ride an OP_RETURN runestone; BTI decodes runes itself. URL: https://blockspace.wiki/answers/what-is-a-rune/ A [rune](https://blockspace.wiki/glossary/rune/) is a fungible token whose operations are written in an OP_RETURN output called a runestone. Runes began at block 840,000, in April 2024. BTI decodes them natively, with ord only as an audit oracle, and identifies each rune by its etching's block and transaction. UNCOMMON•GOODS is rune #0. blockspace.to's ord counts 216,409 runes (as of block 972,304, 2026-10-20 10:17:29 UTC). Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - Blockspace Value Theory · https://block.space/docs/bvt - ord /status (the blockspace.to ord server) · https://blockspace.to/status Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # What is a sub-1 sat/vB transaction? A transaction paying below Bitcoin Core's default floor of 1 sat/vB, which Blockspace Labs' node relays. URL: https://blockspace.wiki/answers/what-is-a-sub-1-sat-vb-transaction/ It is a transaction paying less than 1 sat per vbyte, the default relay floor of Bitcoin Core. Blockspace Labs' node runs stock Bitcoin Core with a minrelaytxfee of 0 sat/vB (as of block 972,304, 2026-10-20 10:17:29 UTC), so it relays and keeps such transactions. This [sub-1 sat/vB relay](https://blockspace.wiki/glossary/sub-1-sat-vb-relay/) is a Live Labs project, and its mempool explorer is explore.block.space. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records Live figures: relay as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # What is an inscription? A file that ord binds to a sat; BTI treats it as content, and the sat as the token. URL: https://blockspace.wiki/answers/what-is-an-inscription/ An [inscription](https://blockspace.wiki/glossary/inscription/) is a file that ord binds to a sat, carried in a witness envelope. To BTI it is not a token: the inscription is content, and the sat it is bound to is the token that claims the bytes. Its size on block.space is its [Book C](https://blockspace.wiki/glossary/book-c/) figure, the file alone. blockspace.to's ord counts 128,169,401 (as of block 972,304, 2026-10-20 10:17:29 UTC). Sources: - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: rankings · https://block.space/docs/rankings - ord /status (the blockspace.to ord server) · https://blockspace.to/status Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # What is Blockspace Holdings? The holding company behind block.space and the projects on block.space/projects. URL: https://blockspace.wiki/answers/what-is-blockspace-holdings/ [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/) is the holding company behind block.space and the projects listed at block.space/projects. Its own site, blockspace.holdings, says: "We acquire & Hodl Blockspace Assets. We serve public Blockspace Infrastructure." As of 2026-10-20 it has 18 properties, from the meter and Blockspace Labs to Scribbit, degent.club and bitmap.holdings. Sources: - Blockspace Holdings records - The project list at block.space/projects · https://block.space/projects - The blockspace.holdings page (site/index.html) · https://blockspace.holdings Updated: 2026-10-20 --- # What is Blockspace Value Theory? BVT, a living document and an untested thesis about tokens built on consumed Bitcoin blockspace. URL: https://blockspace.wiki/answers/what-is-blockspace-value-theory/ > Theory, not fact. Blockspace Value Theory is a living document and an untested thesis. BTP and BYTES are drafts describing things that do not exist. [Blockspace Value Theory](https://blockspace.wiki/glossary/bvt/) (version 3.0, July 2026) is a living document and an untested thesis. It proposes that tokens linked to files committed on Bitcoin, such as runes, BRC-20s and inscribed sats, form one commodity market denominated in kilobytes, with a price floor proportional to the kilobytes consumed. Its central open question is whether markets price kilobytes or fees. Sources: - Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # What is blockspace? The capacity of Bitcoin's blocks, as the block.space documents define and BTI measures it. URL: https://blockspace.wiki/answers/what-is-blockspace/ In the block.space documents, [blockspace](https://blockspace.wiki/glossary/blockspace/) is the capacity of Bitcoin's blocks, consumed by transactions. [Blockspace Value Theory](https://blockspace.wiki/glossary/bvt/) calls it "a socially constructed commodity built on top of a protocol-enforced constraint" and argues it exists only while a block is being built. [BTI](https://blockspace.wiki/glossary/bti/) measures what was consumed: every byte of every transaction, counted exactly, from the genesis block forward. Sources: - Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: BTI · https://block.space/docs/bti Updated: 2026-10-20 --- # What is BTI? The Blockspace Token Indexer: the instrument behind every block.space number. URL: https://blockspace.wiki/answers/what-is-bti/ [BTI](https://blockspace.wiki/glossary/bti/), the Blockspace Token Indexer, is the instrument behind every block.space number. It walks every Bitcoin transaction from the genesis block and counts every byte exactly; nothing is sampled or estimated. It reads each token protocol's operations under that protocol's own rules, then writes [the three books](/concepts/the-three-books/), the judged attribution of blockspace to every token. Sources: - block.space docs: BTI · https://block.space/docs/bti - Blockspace Holdings records Updated: 2026-10-20 --- # What is BTP? A draft (0.1) of the Blockspace Token Protocol, whose subject is blockspace itself. It does not exist. URL: https://blockspace.wiki/answers/what-is-btp/ > Theory, not fact. Blockspace Value Theory is a living document and an untested thesis. BTP and BYTES are drafts describing things that do not exist. [BTP](https://blockspace.wiki/glossary/btp/), the Blockspace Token Protocol, is a draft, version 0.1 of 2026-07-29, describing a protocol that does not exist. The draft describes an attribution-layer protocol: where other metaprotocols answer who owns which token, BTP would answer which token owns which consumed bytes, and make that ownership transactable. Its first operation, MINT, would issue BYTES against a transaction's bytes. Sources: - block.space docs: BTP · https://block.space/docs/btp - BTP, the Blockspace Token Protocol, draft 0.1 · https://block.space/docs/btp Updated: 2026-10-20 --- # What is BYTES? A draft (0.2) describing a fungible token of one per byte of consumed blockspace. It does not exist. URL: https://blockspace.wiki/answers/what-is-bytes/ > Theory, not fact. Blockspace Value Theory is a living document and an untested thesis. BTP and BYTES are drafts describing things that do not exist. [BYTES](https://blockspace.wiki/glossary/bytes-token/) is a draft, version 0.2 of 2026-07-29, describing a token that does not exist. The draft describes a fungible token minted by attributing a transaction's consumed blockspace to it, one token per byte, so 1 BYTES equals 1 byte. Its stated aim is to make the price of a consumed kilobyte directly observable: the BYTES price times 1,000. Sources: - block.space docs: BYTES · https://block.space/docs/bytes - BYTES, a fungible blockspace token, draft 0.2 · https://block.space/docs/bytes Updated: 2026-10-20 --- # What is carriage? Bytes a token merely rode: measured in full, never counted as backing. URL: https://blockspace.wiki/answers/what-is-carriage/ [Carriage](https://blockspace.wiki/glossary/carriage/) is the bytes of a transaction a token merely rode: a payment or consolidation that would have happened anyway and carried the token along. BTI measures carriage in full but never counts it as backing. Carriage answers what moved through the blockspace; backing answers what it was bought for. Sources: - block.space docs: BTI · https://block.space/docs/bti - Blockspace Holdings records Updated: 2026-10-20 --- # What is Scribbit? A planned Blockspace Holdings product at scribb.it, coming soon. URL: https://blockspace.wiki/answers/what-is-scribbit/ [Scribbit](https://blockspace.wiki/glossary/scribbit/), at scribb.it, is a planned Blockspace Holdings product, listed as coming soon. Its line is "Write it once. Keep it forever." The owner's design brief, not yet confirmed, describes a non-custodial way to write up to about 400 KB onto Bitcoin, for contracts, records and attestations, paying only the network fee. No app exists yet. Sources: - Blockspace Holdings records - The project list at block.space/projects · https://block.space/projects Updated: 2026-10-20 --- # What is the Shared Claim Axiom? The proposed rule that tokens claiming the same consumed bytes share them equally. URL: https://blockspace.wiki/answers/what-is-the-shared-claim-axiom/ > Theory, not fact. Blockspace Value Theory is a living document and an untested thesis. BTP and BYTES are drafts describing things that do not exist. The [Shared Claim Axiom](https://blockspace.wiki/glossary/shared-claim-axiom/) is a proposed refinement of Blockspace Value Theory: when several tokens claim the same consumed bytes, the kilobytes are shared equally, bytes consumed divided by n, where n counts the distinct assets claiming them. The axiom's own text calls "shared equally" a rule of thumb, not a derived result. Sources: - block.space docs: the axiom · https://block.space/docs/axiom - The Shared Claim Axiom · https://block.space/docs/axiom Updated: 2026-10-20 --- # What is the witness discount? SegWit weighs witness bytes at a quarter of other bytes, so they cost a quarter as much. URL: https://blockspace.wiki/answers/what-is-the-witness-discount/ The [witness discount](https://blockspace.wiki/glossary/witness-discount/) is SegWit's rule: a non-witness byte weighs 4 weight units and a witness byte 1, so at f sat/vB a witness byte costs f/4 sats. In the July 2026 measurement run, inscriptions measured 3.374 bytes per vbyte and runestones 1.0000. [BVT](https://blockspace.wiki/glossary/bvt/) proposes the discount sells the same resource at a quarter of the price. Sources: - block.space docs: data types · https://block.space/docs/datatypes - block.space docs: measurements · https://block.space/docs/measurements - Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # Where can I get the data? From block.space's JSON API, and from this wiki's machine-readable files. URL: https://blockspace.wiki/answers/where-can-i-get-the-data/ block.space serves its figures as JSON under /api/, readable from any origin: /api/summary for the books' totals, /api/protocols per protocol, /api/frontier for the cursors, and each board's endpoint, such as /api/leaderboard. The boards return their heights and unrounded values. This wiki also publishes llms.txt, llms-full.txt and blockspace.json, with every page's sources. Sources: - Blockspace Holdings records - block.space meter and summary APIs · https://block.space/api/summary - block.space docs: rankings · https://block.space/docs/rankings - blockspace.wiki README · https://blockspace.wiki Updated: 2026-10-20 --- # Why does block.space count bytes and not vbytes? Raw bytes are the measure; vbytes are kept beside them because the ratio is the witness discount. URL: https://blockspace.wiki/answers/why-bytes-not-vbytes/ BTI's design rule R5 says [raw bytes](https://blockspace.wiki/glossary/raw-bytes/) are the measure and [vbytes](https://blockspace.wiki/glossary/vbytes/) an observable. Blockspace Value Theory argues that every byte, witness or not, is downloaded, validated, propagated and stored by nodes, so weight discounting confuses price with quantity. BTI still carries both everywhere, because the ratio of bytes to vbytes is the [witness discount](https://blockspace.wiki/glossary/witness-discount/) itself. Sources: - Blockspace Holdings records - Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: data types · https://block.space/docs/datatypes Updated: 2026-10-20 --- # FAQ Every question the wiki answers, on one page, with the project FAQs. URL: https://blockspace.wiki/faq/ The [answers](/answers/) first, then each project's own FAQ. ### How many Degents are there? The Degent Club collection is 10,000 when fully minted: 4,112 inscribed (as of 2026-09-25 23:24:51 UTC). Each [Degent](https://blockspace.wiki/glossary/degent/) is an [inscription](https://blockspace.wiki/glossary/inscription/) of a Pepe in a tuxedo. Older pages have shown other counts: the site's rebuild specification records 4,027 minted on the old site and 4,113 in an internal analysis, against the collection list's 4,112. ### How much of Bitcoin's blockspace do tokens use? In [Book A](https://blockspace.wiki/glossary/book-a/), the widest of BTI's books, tokens are attributed 133.75 GB, which is 17.21 % of the 777.04 GB of chain bytes the books cover (as of block 972,299, 2026-10-20 09:30:48 UTC). The narrowest, [Book C](https://blockspace.wiki/glossary/book-c/), file and message bodies alone, holds 4.68 %. In the July 2026 measurement run, data payload peaked at 45.4% of block bytes, at height 833,000. ### What are Book A, B and C? They are BTI's three answers to how many bytes back a token. [Book C](https://blockspace.wiki/glossary/book-c/), the content book, counts the artifact bytes alone. [Book B](https://blockspace.wiki/glossary/book-b/), the regional book, adds the structure the token's operations wrote, read or moved through. [Book A](https://blockspace.wiki/glossary/book-a/), the inclusive book, counts whole transactions bought for the token, shared where shared. On every entry, C ≤ B ≤ A. ### What are spent sats? Here, [spent sats](https://blockspace.wiki/glossary/spent-sats/) means the sat ranges of outputs that have already been spent. blockspace.to, a Blockspace Labs product, runs a fork of ord with --index-spent-sats, so a spent output still answers with its sat ranges; an ord without that flag cannot. BTI's August 2026 handoff notes name CAT-21 as the only normal-operation consumer of those ranges. ### What does "as of block H" mean? Every block.space figure is bounded by a block height. "[as of block H](https://blockspace.wiki/glossary/as-of-block-h/)" names the one block, H, that figures are synchronised to; where a ranking or the books sit at another height, pages name those too. A number without its height is not shown. The books stand at block 972,299 and the chain tip at 972,304 (as of block 972,301, 2026-10-20 09:35:17 UTC). ### What does "not measured" mean? The instrument has no figure for that thing: a book not measured for a protocol, a sat the record has not bound to an inscription, a holder the appendix cannot see. block.space writes these in words, never as 0. A zero is a measured zero, such as a protocol with no artifact body measuring zero in [Book C](https://blockspace.wiki/glossary/book-c/). ### What is a rune? A [rune](https://blockspace.wiki/glossary/rune/) is a fungible token whose operations are written in an OP_RETURN output called a runestone. Runes began at block 840,000, in April 2024. BTI decodes them natively, with ord only as an audit oracle, and identifies each rune by its etching's block and transaction. UNCOMMON•GOODS is rune #0. blockspace.to's ord counts 216,409 runes (as of block 972,304, 2026-10-20 10:17:29 UTC). ### What is a sub-1 sat/vB transaction? It is a transaction paying less than 1 sat per vbyte, the default relay floor of Bitcoin Core. Blockspace Labs' node runs stock Bitcoin Core with a minrelaytxfee of 0 sat/vB (as of block 972,304, 2026-10-20 10:17:29 UTC), so it relays and keeps such transactions. This [sub-1 sat/vB relay](https://blockspace.wiki/glossary/sub-1-sat-vb-relay/) is a Live Labs project, and its mempool explorer is explore.block.space. ### What is an inscription? An [inscription](https://blockspace.wiki/glossary/inscription/) is a file that ord binds to a sat, carried in a witness envelope. To BTI it is not a token: the inscription is content, and the sat it is bound to is the token that claims the bytes. Its size on block.space is its [Book C](https://blockspace.wiki/glossary/book-c/) figure, the file alone. blockspace.to's ord counts 128,169,401 (as of block 972,304, 2026-10-20 10:17:29 UTC). ### What is Blockspace Holdings? [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/) is the holding company behind block.space and the projects listed at block.space/projects. Its own site, blockspace.holdings, says: "We acquire & Hodl Blockspace Assets. We serve public Blockspace Infrastructure." As of 2026-10-20 it has 18 properties, from the meter and Blockspace Labs to Scribbit, degent.club and bitmap.holdings. ### What is Blockspace Value Theory? [Blockspace Value Theory](https://blockspace.wiki/glossary/bvt/) (version 3.0, July 2026) is a living document and an untested thesis. It proposes that tokens linked to files committed on Bitcoin, such as runes, BRC-20s and inscribed sats, form one commodity market denominated in kilobytes, with a price floor proportional to the kilobytes consumed. Its central open question is whether markets price kilobytes or fees. ### What is blockspace? In the block.space documents, [blockspace](https://blockspace.wiki/glossary/blockspace/) is the capacity of Bitcoin's blocks, consumed by transactions. [Blockspace Value Theory](https://blockspace.wiki/glossary/bvt/) calls it "a socially constructed commodity built on top of a protocol-enforced constraint" and argues it exists only while a block is being built. [BTI](https://blockspace.wiki/glossary/bti/) measures what was consumed: every byte of every transaction, counted exactly, from the genesis block forward. ### What is BTI? [BTI](https://blockspace.wiki/glossary/bti/), the Blockspace Token Indexer, is the instrument behind every block.space number. It walks every Bitcoin transaction from the genesis block and counts every byte exactly; nothing is sampled or estimated. It reads each token protocol's operations under that protocol's own rules, then writes [the three books](/concepts/the-three-books/), the judged attribution of blockspace to every token. ### What is BTP? [BTP](https://blockspace.wiki/glossary/btp/), the Blockspace Token Protocol, is a draft, version 0.1 of 2026-07-29, describing a protocol that does not exist. The draft describes an attribution-layer protocol: where other metaprotocols answer who owns which token, BTP would answer which token owns which consumed bytes, and make that ownership transactable. Its first operation, MINT, would issue BYTES against a transaction's bytes. ### What is BYTES? [BYTES](https://blockspace.wiki/glossary/bytes-token/) is a draft, version 0.2 of 2026-07-29, describing a token that does not exist. The draft describes a fungible token minted by attributing a transaction's consumed blockspace to it, one token per byte, so 1 BYTES equals 1 byte. Its stated aim is to make the price of a consumed kilobyte directly observable: the BYTES price times 1,000. ### What is carriage? [Carriage](https://blockspace.wiki/glossary/carriage/) is the bytes of a transaction a token merely rode: a payment or consolidation that would have happened anyway and carried the token along. BTI measures carriage in full but never counts it as backing. Carriage answers what moved through the blockspace; backing answers what it was bought for. ### What is Scribbit? [Scribbit](https://blockspace.wiki/glossary/scribbit/), at scribb.it, is a planned Blockspace Holdings product, listed as coming soon. Its line is "Write it once. Keep it forever." The owner's design brief, not yet confirmed, describes a non-custodial way to write up to about 400 KB onto Bitcoin, for contracts, records and attestations, paying only the network fee. No app exists yet. ### What is the Shared Claim Axiom? The [Shared Claim Axiom](https://blockspace.wiki/glossary/shared-claim-axiom/) is a proposed refinement of Blockspace Value Theory: when several tokens claim the same consumed bytes, the kilobytes are shared equally, bytes consumed divided by n, where n counts the distinct assets claiming them. The axiom's own text calls "shared equally" a rule of thumb, not a derived result. ### What is the witness discount? The [witness discount](https://blockspace.wiki/glossary/witness-discount/) is SegWit's rule: a non-witness byte weighs 4 weight units and a witness byte 1, so at f sat/vB a witness byte costs f/4 sats. In the July 2026 measurement run, inscriptions measured 3.374 bytes per vbyte and runestones 1.0000. [BVT](https://blockspace.wiki/glossary/bvt/) proposes the discount sells the same resource at a quarter of the price. ### Where can I get the data? block.space serves its figures as JSON under /api/, readable from any origin: /api/summary for the books' totals, /api/protocols per protocol, /api/frontier for the cursors, and each board's endpoint, such as /api/leaderboard. The boards return their heights and unrounded values. This wiki also publishes llms.txt, llms-full.txt and blockspace.json, with every page's sources. ### Why does block.space count bytes and not vbytes? BTI's design rule R5 says [raw bytes](https://blockspace.wiki/glossary/raw-bytes/) are the measure and [vbytes](https://blockspace.wiki/glossary/vbytes/) an observable. Blockspace Value Theory argues that every byte, witness or not, is downloaded, validated, propagated and stored by nodes, so weight discounting confuses price with quantity. BTI still carries both everywhere, because the ratio of bytes to vbytes is the [witness discount](https://blockspace.wiki/glossary/witness-discount/) itself. ### What does block.space measure? How much of Bitcoin's [blockspace](https://blockspace.wiki/glossary/blockspace/) is attributed to tokens, token by token, byte by byte. [BTI](https://blockspace.wiki/glossary/bti/) counts every byte, catalogues each protocol's operations, and writes three books per token: [Book A](https://blockspace.wiki/glossary/book-a/), [Book B](https://blockspace.wiki/glossary/book-b/) and [Book C](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/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](https://blockspace.wiki/glossary/not-measured/), never as 0. ### Is the code public? The code of the sibling explorer, [explore.block.space](https://blockspace.wiki/glossary/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). ### How many Degents are there? The collection is 10,000 when fully minted. Today there are 4,112 inscribed (as of 2026-09-25 23:24:51 UTC). The 10,000 is the size of the finished collection, not a count of Degents that exist. ### What does a Degent have to look like? The club's minting rules ask for a square JPEG of at least 200KB, a Pepe character in a tuxedo with a mandatory bowtie, and the [frame with a placard](https://blockspace.wiki/glossary/frame-and-placard/) saying "DEGEN", "DEGENT" or "REGEN". You may mint as many as you want. ### Why have older pages shown other counts? A review of the site found three conflicting counts: the old site's 4,027 minted and 1,470 MB, 4,112 in the collection list, and 4,113 and 1,508 MB in an earlier analysis. It also calls the old "10K = 3+ GB" a projection presented as fact. ### Can I use the Degent art or name in my own project? No. The code is Apache-2.0 and the docs CC BY 4.0, but the artwork, the comic, the collection's images, the names and the [frame and placard](https://blockspace.wiki/glossary/frame-and-placard/) are not licensed. A fork must use its own name and art. Using the names to refer to the project is fine. ### Who decides changes to the code? Each component's owning team reviews and merges by pull request, under [lazy consensus](https://blockspace.wiki/glossary/lazy-consensus/). Significant decisions need an [Architecture Decision Record](https://blockspace.wiki/glossary/architecture-decision-record/). Licensing, trademarks and the Code of Conduct are decided by Blockspace Holdings. ### Can I use Scribbit today? No. The app is coming soon (as of 2026-10-20) and no Scribbit code exists. The scribb.it site describes the planned product only: it connects no wallet, takes no payment and sends no transaction. ### Will Scribbit hold my money? As planned, Scribbit is [non-custodial](https://blockspace.wiki/glossary/non-custodial/): your own wallet funds and signs the transactions. This is not yet a confirmed commitment (as of 2026-10-20). ### What will it cost? As planned, the network fee only, with zero platform fee (not yet confirmed, as of 2026-10-20). For scale, a real 387,641-byte PDF paid 49,842 sats for its whole [reveal transaction](https://blockspace.wiki/glossary/reveal-transaction/) in block 965,177. ### Why about 400 KB? Bitcoin Core relays a transaction only up to 400,000 [weight units](https://blockspace.wiki/glossary/weight-unit/), and a [witness](https://blockspace.wiki/glossary/witness/) byte weighs one unit. So a standard reveal can carry a little under 400,000 bytes of [payload](https://blockspace.wiki/glossary/payload/). ### Can I delete or change what I write? No. Once a reveal is mined, nobody can edit or delete its bytes. To correct a record, the site suggests writing a new one that refers to the old one by its [inscription id](https://blockspace.wiki/glossary/inscription-id/). ### Why are some counters missing from counters.fun? Its one rule is that only counters whose file is on Bitcoin are displayed. A [pointer counter](https://blockspace.wiki/glossary/pointer-counter/) is a valid counter, but showing it would mean fetching bytes from someone else's server, so counters.fun does not render or trade it. ### Which wallets work with it? Both Counterparty browser wallets, XCP Wallet and Horizon Wallet, through one adapter. Every flow is signed as a PSBT, because Horizon cannot sign a raw transaction; when a wallet cannot broadcast, the app falls back to Esplora. ### What is price per KB? [Price per KB](https://blockspace.wiki/glossary/price-per-kb/) is the market cap spread over the bytes the asset carries on chain: price × circulating supply ÷ KB, in the price's own unit. It is shown on every pooled card, dispenser card and DEX row. ### Can I buy from a dispenser by sending it BTC? No. Since block 866,000 a bare BTC payment to a [dispenser](https://blockspace.wiki/glossary/dispenser/) buys nothing. counters.fun's buy composes a Counterparty dispense, shows the price plus the miner fee, and the wallet signs it. ### What can I mint there? Three things through one commit and reveal path: a new [counter](https://blockspace.wiki/glossary/counter/), a [reinscription](https://blockspace.wiki/glossary/reinscription/) on an asset you own, or a [fairminter](https://blockspace.wiki/glossary/fairminter/) deploy whose description is the file. The XCP-69 preset follows xcp.fun's template and opens a [liquidity pool](https://blockspace.wiki/glossary/liquidity-pool/) at soft cap. ### What is a counter? A [counter](https://blockspace.wiki/glossary/counter/) is a file committed to Bitcoin as the description of a [Counterparty](https://blockspace.wiki/glossary/counterparty/) asset, carried in [witness data](https://blockspace.wiki/glossary/witness/) by a [Counterparty taproot envelope](https://blockspace.wiki/glossary/taproot-envelope/), and numbered gap-free in order of creation from #0. ### Why do counters start at block 902,000? That is where Counterparty's taproot encoding activated. Before it, an asset description could not reach the chain in witness data, so no counter could exist. Counter #0, XDUALS, came five blocks later, at 902,005. ### Does the explorer show files hosted somewhere else? No. A counters server only shows on-chain files. A [pointer counter](https://blockspace.wiki/glossary/pointer-counter/) is shown as its pointer text and never fetched, and HTML and SVG run sandboxed. ### Can a counter's number change? Numbers are append-only, but numbers near the tip are provisional until confirmations pass, because a reorg rolls back and re-numbers identically. Amendment A1 (2026-09-24) removed one derived event, #163, and every later counter moved down by one. ### How can two explorers be sure they agree? Each counter extends a [rolling hash](https://blockspace.wiki/glossary/rolling-hash/). Two indexers agree on the whole history if and only if their latest rolling hash matches. ### What is Devcash? In its own words, "Devcash (DEV) is cash for the developer economy. It is the official currency of Blockchain Developers United." It offers a [bounty](https://blockspace.wiki/glossary/bounty/) platform and a decentralized exchange. See [Devcash](https://blockspace.wiki/glossary/devcash/). ### How does the bounty platform work? Users post a task and crowdsource developer talent, or hunt bounties: they perform developer tasks and earn DEV. A bounty can carry an ETH or a DEV reward. ### Where is it hosted? On its own server, separately from Blockspace Holdings' other projects (as of 2026-10-20). ### Is it on blockspace.holdings? No. Blockspace Holdings chose on 2026-10-20 to leave it off blockspace.holdings. It stays on block.space/projects. ### What is a bitbar? A [bitbar](https://blockspace.wiki/glossary/bitbar/) is a bar-shaped [inscription](https://blockspace.wiki/glossary/inscription/) whose size is its name. The 1kB bitbar is exactly 1,024 bytes. ### Can I mint a bitbar there today? The page answers, but on 2026-10-19 the server behind its Mint button's QR code did not answer, and only the page and image are served. No source says whether payments are being turned into mints. ### How was a mint meant to work? The page asks you to use an ordinals wallet (it recommends Unisat), send 0.00002 BTC to the address it shows, and wait: the bitbar is minted to the sending address, at a standard fee rate of 3 sats/vB. ### Where is its code? In the public repository antron3000/Bitbar-Minting-App: the page, a payment-watching server and a minter script. ### What is blockspace.holdings? The page of [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/), the company behind block.space and the other projects. It shows every project as a holding, with block.space, degent.club and scribb.it featured. ### Why does it say "Hodl"? The spelling is deliberate, and it stays. See [Hodl](https://blockspace.wiki/glossary/hodl/). ### Where do the cards come from? From the same project list that block.space/projects shows. The cards are generated from that list, not kept by hand. Each line comes from the project's own site or its own source. ### Why is devcash.dev not on the page? Blockspace Holdings chose on 2026-10-20 to leave it off blockspace.holdings. It stays on block.space/projects. ### What is Space Blocks? [Space Blocks](https://blockspace.wiki/glossary/space-blocks/) is inscription #83,851,681: one JPEG, 1537 × 1537, of 1,047,584 bytes, inscribed in block 881,188. ### Does it really fill a block? It fills 1,047,584 of the 1,048,576 bytes of a 1 MB block, 99.9 %. ### What are the other works on the site? The page "Other works that fill a block" lists the inscriptions block.space classes as [whole-block](https://blockspace.wiki/glossary/whole-block/), content over 3,500,000 bytes: 110 of them as of block 972,262, largest first, each linking to its record on block.space. ### Who made it? No source names an artist or gives a story (as of 2026-10-20), so the site shows only the facts. ### What is blockspace.wiki? This site. In Blockspace Holdings' words, "a place to write all information and documentation about [blockspace](https://blockspace.wiki/glossary/blockspace/)": a page per project with its glossary and FAQ, the concepts, the protocols, and the data. ### Where do its facts come from? Only from Blockspace Holdings' own documents and the live data of [its own Bitcoin node and indexers](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/). Every page lists its sources, a claim with no source is not written, and every live figure carries its "as of". ### Is the theory presented as fact? No. Blockspace Value Theory is a living document and an untested thesis; BTP and BYTES are drafts describing things that do not exist. Theory pages say so. ### Can agents read it? Yes. It publishes [machine surfaces](https://blockspace.wiki/glossary/machine-surfaces/): a sitemap, robots.txt that welcomes crawlers, llms.txt and llms-full.txt (the whole wiki as Markdown), JSON-LD, an Atom feed and /.well-known/blockspace.json. ### What is Litepedia? [Litepedia](https://blockspace.wiki/glossary/litepedia/) is a Blockspace Holdings project to upload Wikipedia to Litecoin and let people pay LTC (Litecoin's coin) to make edits, with a robust editing system. ### Can I read or edit it yet? No. As of 2026-10-20 litepedia.space shows a Coming soon page. Nothing has been uploaded to Litecoin. ### What does it need before it can start? A Litecoin node and an inscription indexer for Litecoin, to put content on-chain. Blockspace Holdings runs no Litecoin node as of 2026-10-20. ### Does blockspace.loans offer loans? No. Nothing is built (as of 2026-10-20). The concept under consideration is an information page only, with no lending service and no offer of credit, and it is not confirmed. ### What does the domain show now? A generated "Coming soon" page, written from the domain's row in the project list. ### Can I buy on blockspace.markets? No. The page only shows listings. Buying happens at block.space/buy, the one place with the wallet flow, which the page links to. ### How is the price per kilobyte worked out? The venue's asking price, divided by the blockspace block.space's books attribute to the asset under [Book A](https://blockspace.wiki/glossary/book-a/), as the [buy board](https://blockspace.wiki/glossary/buy-board/) computes it. See [sats per kB](https://blockspace.wiki/glossary/sats-per-kb/). ### How fresh is it? The page is rebuilt every 10 minutes and every section says the time it is as of. If the board returns nothing, the last page stays, with its own as-of time. ### Where do the numbers come from? Every figure is read from block.space's public API and bounded by the height its books are written to. The site says nothing is estimated, and it makes no prose claims beyond the data. ### When does a new edition appear? Once a day. A snapshot is taken at 00:15 UTC, and the [edition](https://blockspace.wiki/glossary/edition/) is the difference between that day's snapshot and the one before. ### What happens if the books are rewound? A rewound or rewritten set of [books](https://blockspace.wiki/glossary/the-books/) is reported as "no comparison", never as a negative. ### Is there a feed? Yes. Each edition has its own page by date, the archive lists them all, and an Atom feed is at /feed.xml. ### What is Blockspace Labs? The research and development arm of [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/), at blockspacelabs.com. Its site lists research projects as cards, each marked Live or Research, with figures measured on [Blockspace Holdings' own Bitcoin node and indexers](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/). ### Does the Labs node really relay transactions below 1 sat/vB? Yes. It runs stock Bitcoin Core with a minimum relay fee of 0 sat/vB (as of block 972,304, 2026-10-20 10:17:29 UTC), so it relays and keeps them. See [sub-1 sat/vB relay](https://blockspace.wiki/glossary/sub-1-sat-vb-relay/). ### Does it relay 4 MB transactions? No. Stock Bitcoin Core treats a transaction over 400,000 weight units (100 kvB) as [non-standard](https://blockspace.wiki/glossary/standard-transaction/), so 4 MB relay needs a patched node. In Blockspace Holdings' words it is "just a research project". ### Are the research projects producing results? Not yet, as of 2026-10-20. In Blockspace Holdings' words, the Labs projects stay "descriptive research projects for now". The cards say what each study is and what data it uses; nothing is built behind them. ### How is blockspace.to related to Labs? blockspace.to is a Blockspace Labs product: an ord explorer and indexer that also tracks [spent sats](https://blockspace.wiki/glossary/spent-sats/). ### What does blockspace.to do? It is an [ord](https://blockspace.wiki/glossary/ord/) explorer and indexer that also tracks which sats have been spent. In its own line: "Tracks spent sats. A Blockspace Labs product." See [spent sats](https://blockspace.wiki/glossary/spent-sats/). ### How many inscriptions does it index? 128,169,401 [inscriptions](https://blockspace.wiki/glossary/inscription/), as of block 972,304, 2026-10-20 10:17:29 UTC: 127,697,358 blessed and 472,043 cursed. ### What are lost sats? Sats that coinbase transactions never claimed, so they exist in no output. ord counts 2,895,844,904 of them (as of block 972,304, 2026-10-20 10:17:29 UTC). See [lost sats](https://blockspace.wiki/glossary/lost-sats/). ### Who runs it? [Blockspace Labs](https://blockspace.wiki/glossary/blockspace-labs/), the research and development arm of [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/). It runs on [Blockspace Holdings' own Bitcoin node and indexers](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/), and block.space's inscription content depends on it. ### What will blockspace.space be? Not decided, as of 2026-10-20. The concept under consideration is a view of where the space in Bitcoin's blocks goes. It is not confirmed, and the domain keeps its landing page until then. ### What does the domain show now? A generated "Coming soon" page, written from the domain's row in the project list. ### What is a Bitmap? In bitmap.holdings' own words, "Bitmaps turn each Bitcoin block into a piece of digital land." Each block becomes a coordinate, each coordinate becomes ownable, and each ownership becomes programmable. See [Bitmap](https://blockspace.wiki/glossary/bitmap/). ### Is bitmap.holdings part of Blockspace Holdings? Yes. It is one of Blockspace Holdings' properties, hosted separately from the other projects. Blockspace Holdings counts it among its holdings (as of 2026-10-20). ### Is it the bitmap that BTI catalogues? No source links the two. BTI's token catalogue has a "bitmap sats" entry, read by its opi-bitmap adapter, where the inscription is a district claim and the district number is a label on the sat. This wiki makes no claim about what bitmap.holdings holds. ### How do I get in touch? Its site has a contact form and a "Tweet us" link. It asks to hear from people working on Ordinals or Bitmaps, on-chain identity, metaverse or game integrations, or Bitcoin infrastructure. Sources: - Blockspace Holdings records Live figures: books as of block 972,299, 2026-10-20 09:30:48 UTC; degent as of 2026-09-25 23:24:51 UTC; frontier as of block 972,301, 2026-10-20 09:35:17 UTC; ord as of block 972,304, 2026-10-20 10:17:29 UTC; relay as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # 4 MB transaction relay Research: relaying transactions up to 4 MB, the whole block weight. Stock Bitcoin Core stops at 100 kvB, so it needs a patched node; none relays them here today. URL: https://blockspace.wiki/research/4mb-transaction-relay/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research**, the first card in the Research group. ## What it is The Labs site describes it as "relaying transactions up to 4 MB, the whole block weight". A block may weigh up to 4,000,000 [weight units](https://blockspace.wiki/glossary/weight-unit/). Relay policy is stricter: "Stock Bitcoin Core treats a transaction over 400,000 weight units (100 kvB) as non-standard and does not relay it, so this needs a patched node." A transaction above that size is not a [standard transaction](https://blockspace.wiki/glossary/standard-transaction/), so ordinary nodes will not pass it on, even though a block may contain it. ## Where it stands It is a research project, not a running service. The Labs node runs stock Bitcoin Core (/Satoshi:28.2.0/, as of block 972,304, 2026-10-20 10:17:29 UTC), which keeps the 400,000 WU limit. The card says it plainly: "No node here relays 4 MB transactions today." It stays marked Research until such a node runs. ## Background block.space's data-types reference names the limit `MAX_STANDARD_TX_WEIGHT`. It says a larger transaction, such as the 3.94 MB Taproot Wizards inscription it cites, needs direct-to-miner submission. The [relay policy](/concepts/relay-policy/) page sets this limit beside the node's other policy settings, and [weight units and vbytes](/concepts/weight-units-and-vbytes/) explains how a transaction is weighed. ## Related research The standard transaction size is one of the relay levers in [blockspace expansion policy](/research/blockspace-expansion-policy/). The [policy observatory](/research/policy-observatory/) proposes to count mined transactions over 100 kvB, which reach miners off the standard relay path. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes Live figures: relay as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # Blockspace expansion policy Research: the relay and consensus levers that change how much blockspace is usable and who can reach it, each measured effect beside the arguments for and against. Descriptive; it takes no side. URL: https://blockspace.wiki/research/blockspace-expansion-policy/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it studies The Labs site describes "the levers that change how much blockspace is usable and who can reach it". It names two kinds: - **relay policy:** the [fee floor](https://blockspace.wiki/glossary/fee-floor/), the [standard transaction](https://blockspace.wiki/glossary/standard-transaction/) size, data-carrier limits ([OP_RETURN](https://blockspace.wiki/glossary/op-return/)) and [full-RBF](https://blockspace.wiki/glossary/full-rbf/); - **consensus:** the block weight limit and the [witness discount](/concepts/witness-discount/). For each lever the study sets "the measured effect beside the arguments for and against". It is written as research, not advocacy, and states no position. The card ends: "Descriptive research; it takes no side." ## The figures on the card The card shows each lever's current setting on the Labs node, in the reading of 2026-10-20 09:07:08 UTC: | lever | setting | |---|---| | fee floor here | 0.00000000 BTC/kvB | | max standard tx | 400,000 WU | | OP_RETURN limit | 83 bytes | | full-RBF here | on | | max block weight | 4,000,000 WU | | weight per byte | witness 1 WU, base 4 WU | The card notes that the size and OP_RETURN figures are Bitcoin Core 28 defaults and that the weight limits are consensus. The wiki's own reading of the node, as of block 972,304, 2026-10-20 10:17:29 UTC: fee floor 0 sat/vB, full-RBF on. ## The data it will use The node's settings, and for the measured effects two other studies: the [policy observatory](/research/policy-observatory/) and [the byte census](/research/byte-census/). Like every Research card it is descriptive: it says what it studies and from which data, and claims no results. The [relay policy](/concepts/relay-policy/) page describes each relay lever on the node. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - Blockspace Holdings records Live figures: relay as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # The blockspace price Live: asking prices per kilobyte of blockspace across marketplaces, from every listing that can be read. It powers blockspace.markets. URL: https://blockspace.wiki/research/blockspace-price/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Live**, the sixth card in the Live group. ## What it is The Labs site describes it as "asking prices per kilobyte of blockspace across marketplaces, from every listing we can read. It powers blockspace.markets." Tokens on Bitcoin are listed for sale on many marketplaces. Each token is backed by a number of bytes, so each asking price can be turned into a [price per KB](https://blockspace.wiki/glossary/price-per-kb/) of blockspace. The project gathers those asks onto one board, [the buy board](https://blockspace.wiki/glossary/buy-board/), and sorts them by that price. [blockspace.markets](/projects/blockspace.markets/) is the public page built from it: in its own words, "Blockspace for sale, priced per kilobyte." ## What the card shows The card shows how many asks are on the board. In the reading of 2026-10-20 09:07:11 UTC there were 167,662. The wiki keeps no live reading of the board of its own; that figure is the Labs site's, with its date. ## Links The card links to https://blockspace.markets and to the buy board at https://block.space/buy. The Research card [testing the BVT](/research/testing-the-bvt/) proposes to use these prices to test Blockspace Value Theory: does the price per kilobyte track attributed bytes? Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - Blockspace Holdings records - The blockspace.markets site: README, tools/build.py and the page · https://blockspace.markets Updated: 2026-10-20 --- # blockspace.to: spent sats Live, a product: an ord explorer and indexer that also tracks which sats have been spent, running a fork of ord with --index-spent-sats. URL: https://blockspace.wiki/research/blockspace-to-spent-sats/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Live, a product.** Its card is the second in the Live group. ## What it is [blockspace.to](/projects/blockspace.to/) is, in the Labs site's words, "an ord explorer and indexer that also tracks which sats have been spent". It is "a Blockspace Labs product, running a fork of ord with `--index-spent-sats`". Its line on block.space/projects reads: "Tracks spent sats. A Blockspace Labs product." [ord](https://blockspace.wiki/glossary/ord/) is the indexer and explorer for ordinal inscriptions. The fork adds [spent sats](https://blockspace.wiki/glossary/spent-sats/): it keeps the sat ranges of outputs that have been spent, not only of the outputs that exist now. The [spent sats](/concepts/spent-sats/) page explains what that adds. It indexes mainnet, and has been live at https://blockspace.to since 2026-10-20 08:32 UTC. ## What the card shows The card shows the chain, the block the index has reached and its count of inscriptions. In the reading of 2026-10-20 09:07:08 UTC it was on mainnet, indexed to block 972,298, with 128,169,266 inscriptions. The wiki's own reading of the same server, as of block 972,304, 2026-10-20 10:17:29 UTC: indexed to block 972,304, with 128,169,401 inscriptions (127,697,358 blessed and 472,043 [cursed](https://blockspace.wiki/glossary/cursed-inscription/)) and 216,409 runes. ## Related research The Research card [inscription permanence](/research/inscription-permanence/) uses blockspace.to's spent sats to follow how often inscribed sats are spent or move. The [lost sats](/research/lost-sats/) and [cursed inscriptions](/research/cursed-inscriptions/) cards read the same ord index. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - Blockspace Holdings records - The project list at block.space/projects · https://block.space/projects - ord /status (the blockspace.to ord server) · https://blockspace.to/status Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # Blockspace Token Indexer (BTI) Live: every byte of every block attributed to the tokens that bought it, in three books. It powers block.space. URL: https://blockspace.wiki/research/blockspace-token-indexer/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Live**, the third card in the Live group. ## What it is The Labs site describes the [Blockspace Token Indexer](https://blockspace.wiki/glossary/bti/) in two sentences: "Every byte of every block attributed to the tokens that bought it, in three books: A inclusive, B regional, C content. It powers block.space." The three books are three answers to how many bytes back a token: [Book A](https://blockspace.wiki/glossary/book-a/) (inclusive), [Book B](https://blockspace.wiki/glossary/book-b/) (regional) and [Book C](https://blockspace.wiki/glossary/book-c/) (content). The [three books](/concepts/the-three-books/) page explains how they differ. BTI works in three layers: [the byte census](/concepts/byte-census-t1/) (T1), [the claims](/concepts/claims-t2/) (T2) and [the books](/concepts/books-t3/) (T3). The full account is on the [BTI](/concepts/bti/) page. ## What the card shows The card shows the block the books are written to, and the counts of protocols, tokens, operations and Book A bytes. In the reading of 2026-10-20 09:07:11 UTC the books were written to block 972,199, with 21 protocols, 126,866,878 tokens, 623,207,877 operations and 133.7 GB attributed in Book A. The wiki's own reading, as of block 972,299, 2026-10-20 09:30:48 UTC: books written to block 972,299; 21 protocols, 126,874,922 tokens and 623,681,326 operations; Book A attributed 133.75 GB, which is 17.21 % of the chain's bytes in that range. ## Links The card links to https://block.space, where BTI's books are shown, and to https://block.space/docs/bti, "How it works". The [block.space](/projects/block.space/) project page describes the site that BTI powers. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - Blockspace Holdings records - block.space meter and summary APIs · https://block.space/api/summary Live figures: books as of block 972,299, 2026-10-20 09:30:48 UTC Updated: 2026-10-20 --- # Blockspace Value Theory (Labs card) Research: the thesis behind the meter, in its own words a living document and an untested thesis. URL: https://blockspace.wiki/research/blockspace-value-theory/ > Theory, not fact. Blockspace Value Theory is a living document and an untested thesis. BTP and BYTES are drafts describing things that do not exist. **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it is The Labs card is short: "The thesis behind the meter, in its own words a living document and an untested thesis." [Blockspace Value Theory](https://blockspace.wiki/glossary/bvt/) is the document behind block.space's meter, which shows how much of Bitcoin's blockspace is attributed to tokens. Labs lists it as Research, not Live, because it is a thesis and has not been tested. ## What the wiki says about it The theory has its own page, [Blockspace Value Theory](/concepts/blockspace-value-theory/), which describes what BVT proposes and labels it as theory throughout. Two related pages are also theory: [attribution and the axiom](/concepts/attribution-and-the-axiom/), and [the Atomicals natural experiment](/concepts/atomicals-natural-experiment/), which the documents propose as a case to test the thesis against. ## How Labs would test it A separate Research card, [testing the BVT](/research/testing-the-bvt/), describes an empirical test: does the [price per KB](https://blockspace.wiki/glossary/price-per-kb/) of blockspace track the bytes attributed to each token? It would compare the Live projects [the blockspace price](/research/blockspace-price/) and the [Blockspace Token Indexer](/research/blockspace-token-indexer/). No result is claimed. ## Read it The card links to https://block.space/docs/bvt, "Read the BVT", where the living document is published. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records - Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # The byte census Live: every block's bytes, counted by region: base, witness and envelopes. URL: https://blockspace.wiki/research/byte-census/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Live**, the fourth card in the Live group. ## What it is The Labs site describes [the byte census](https://blockspace.wiki/glossary/the-census/) in one sentence: "Every block's bytes, counted by region: base, witness and envelopes." It is T1, the first of BTI's three layers. Before any token is named, it counts where each block's bytes sit: in the base transaction data, in the [witness](https://blockspace.wiki/glossary/witness/), and inside [envelopes](https://blockspace.wiki/glossary/envelope/), the structures protocols use to carry data. The [byte census](/concepts/byte-census-t1/) page explains the layer in full. The split between base and witness bytes matters because Bitcoin weighs them differently; the [witness discount](/concepts/witness-discount/) and [weight units and vbytes](/concepts/weight-units-and-vbytes/) pages explain how. ## What the card shows The card shows the block the census has counted to, the chain's bytes and its transactions. In the reading of 2026-10-20 09:07:11 UTC it had counted to block 972,296: 777.0 GB of chain bytes in 1,464,112,513 transactions. The wiki's own reading, as of block 972,302, 2026-10-20 10:16:21 UTC: counted to block 972,302, 972,303 blocks, 777.04 GB of chain bytes and 1,464,151,063 transactions. ## Links The card links to https://block.space/t1, "The census". Three Research cards draw on the census: the [policy observatory](/research/policy-observatory/), [blockspace expansion policy](/research/blockspace-expansion-policy/) and [permanent bytes](/research/permanent-bytes/). Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - Blockspace Holdings records - block.space meter and summary APIs · https://block.space/api/summary Live figures: census as of block 972,302, 2026-10-20 10:16:21 UTC Updated: 2026-10-20 --- # Cursed inscriptions Research: which rules cursed each inscription, by height, and how the books bind them to sats. URL: https://blockspace.wiki/research/cursed-inscriptions/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it studies The Labs site asks "which rules cursed each inscription, by height, and how the books bind them to sats." A [cursed inscription](https://blockspace.wiki/glossary/cursed-inscription/) is one that [ord](https://blockspace.wiki/glossary/ord/) numbers apart from the "blessed" inscriptions, with a negative number. ord's status page counts the two separately. The study has two parts. The first sorts the cursed inscriptions by the rule that cursed them and the block they appeared in. The second checks how the [BTI](https://blockspace.wiki/glossary/bti/) books bind them to the sats they sit on. The second part has a known gap behind it. A check of 2026-10-19 found that 582 of the top 100,000 inscriptions by size had no sat binding in BTI below the export ceiling, and that they were cursed numbers. ## The data it will use "ord inscription index and BTI": the ord index behind [blockspace.to](/projects/blockspace.to/), and BTI's sat bindings. ## The figures on the card It is one of the Research cards that shows a current figure, because one already exists with an "as of". At 2026-10-20 09:07:08 UTC the card read **472,043 cursed** and **127,697,223 blessed** inscriptions. The wiki's own reading, as of block 972,304, 2026-10-20 10:17:29 UTC: 472,043 cursed and 127,697,358 blessed. No result of the study is claimed. [Inscriptions](/concepts/inscriptions/) explains how inscriptions are made and numbered. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - Blockspace Holdings records - ord /status (the blockspace.to ord server) · https://blockspace.to/status Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # The envelope taxonomy Research: every way data is carried on Bitcoin (ord envelopes, Counterparty, OP_RETURN protocols, stamps), by bytes over time. URL: https://blockspace.wiki/research/envelope-taxonomy/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it studies The Labs site describes it as: "Every way data is carried on Bitcoin (ord envelopes, Counterparty, OP_RETURN protocols, stamps), by bytes over time." Data reaches Bitcoin in several shapes. An [envelope](https://blockspace.wiki/glossary/envelope/) is the structure a protocol wraps its data in. The card names four families of carrier: - **ord envelopes:** the witness envelopes that carry ordinal [inscriptions](https://blockspace.wiki/glossary/inscription/); - **[Counterparty](https://blockspace.wiki/glossary/counterparty/):** its own message encodings; - **[OP_RETURN](https://blockspace.wiki/glossary/op-return/) protocols:** data in a provably unspendable output; - **[stamps](https://blockspace.wiki/glossary/bitcoin-stamp/):** data written where it cannot be pruned. The study counts the bytes each carrier has used, block by block, so the history of how data is put on Bitcoin can be read as one series. block.space's data-types reference describes the formats themselves, field by field. ## The data it will use "BTI envelopes": [the byte census](/concepts/byte-census-t1/) already finds the envelopes in every block and counts their bytes by region. It is a descriptive card; no results are claimed. ## Related pages [Inscriptions](/concepts/inscriptions/) explains the ord envelope. Part one of [permanent bytes](/research/permanent-bytes/) asks a narrower question of the same data: every inscribed byte by kind, over time. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records - block.space docs: data types · https://block.space/docs/datatypes Updated: 2026-10-20 --- # Fork and reorg watch Research: detect indexers that follow a stale tip or a fork, from the experience of an atomicals indexer stuck on an orphan at block 966,500. URL: https://blockspace.wiki/research/fork-and-reorg-watch/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it studies The Labs site describes it as a study that "detects indexers that follow a stale tip or a fork, from our experience with an atomicals indexer stuck on an orphan at block 966,500." An [indexer](https://blockspace.wiki/glossary/indexer/) reads every block and builds its own view of a protocol. In a [reorg](https://blockspace.wiki/glossary/reorg/), a competing chain replaces recent blocks, and a replaced block becomes an orphan. An indexer that does not follow the reorg keeps building on the orphan: its height can look current while its view has left the chain the node follows. That happened to the atomicals indexer, which serves [ARC-20](https://blockspace.wiki/glossary/arc-20/): it stayed on an orphan at block 966,500. The study turns that lesson into a check. ## The data it will use "Indexer cursors against bitcoind": compare the height and block each indexer says it has reached with the chain the Bitcoin node follows. A cursor whose block is not on the node's chain marks an indexer on a fork. block.space already publishes the cursors of BTI's three tiers beside the chain tip; [the frontier](/concepts/the-frontier/) page explains them. ## Where it stands It is a descriptive card: it says what the check is and what it would compare. No watch is built yet and no results are claimed. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records - block.space frontier API (the three tier cursors and the chain tip) · https://block.space/api/frontier Updated: 2026-10-20 --- # Full-RBF in practice Research: count the replacements the Labs mempool sees with full-RBF on, and which of them reach blocks. URL: https://blockspace.wiki/research/full-rbf-in-practice/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it studies The Labs site describes it in one sentence: it "counts the replacements our mempool sees with full-RBF on, and which of them reach blocks." [Full-RBF](https://blockspace.wiki/glossary/full-rbf/) is a relay policy setting about replacing unconfirmed transactions in a node's [mempool](https://blockspace.wiki/glossary/mempool/). The Labs node runs with full-RBF on and an incremental relay fee of 1 sat/vB (as of block 972,304, 2026-10-20 10:17:29 UTC). The study counts the replacements that node sees, then checks which versions end up in blocks. ## The data it will use "bitcoind mempool events against blocks": the Labs node's own record of what entered and left its mempool, set against the blocks that follow. It is a descriptive card; nothing is counted yet and no results are claimed. ## Related research Full-RBF is one of the relay levers in [blockspace expansion policy](/research/blockspace-expansion-policy/). The [relay policy](/concepts/relay-policy/) page describes the node's full-RBF setting beside its other policy settings. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records Live figures: relay as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # Inscription permanence Research: how often inscribed sats are spent or move, and where they go. URL: https://blockspace.wiki/research/inscription-permanence/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it studies The Labs site asks: "How often inscribed sats are spent or move, and where they go." An [inscription](https://blockspace.wiki/glossary/inscription/) is bound to a single [sat](https://blockspace.wiki/glossary/sat/). The inscribed bytes stay on Bitcoin for good, but the sat that carries them moves whenever its output is spent. This study measures how often that happens and where the sats end up. The [sats and ordinals](/concepts/sats-and-ordinals/) page explains how a sat is tracked from output to output. ## The data it will use "blockspace.to spent sats and the holders appendix's sat moves": - [blockspace.to](/projects/blockspace.to/), the Labs ord explorer, keeps the sat ranges of spent outputs, its [spent sats](https://blockspace.wiki/glossary/spent-sats/) index (see [spent sats](/concepts/spent-sats/)); - [the holders appendix](https://blockspace.wiki/glossary/the-appendix/), which keeps holdings up to date block by block, records each move of an inscribed sat from one holder to another. The card links to https://blockspace.to. It is a descriptive card; no results are claimed. ## Related research [blockspace.to: spent sats](/research/blockspace-to-spent-sats/) is the Live project the study builds on, and [who holds blockspace](/research/who-holds-blockspace/) the Live project behind the appendix. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records - ord /status (the blockspace.to ord server) · https://blockspace.to/status Updated: 2026-10-20 --- # Litecoin and Dogecoin blockspace Research: Litecoin's and Dogecoin's blockspace measured the way block.space measures Bitcoin's. No Litecoin or Dogecoin node runs yet; the study starts when one does. URL: https://blockspace.wiki/research/litecoin-and-dogecoin-blockspace/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research**, the last card in the Research group. ## What it studies The Labs site describes it as "their blockspace measured the way block.space measures Bitcoin's": a byte census, and the share carried by Litecoin inscriptions (Litebars) and Dogecoin inscriptions (Doginals). So the study would bring two of block.space's measures to two other chains: - a byte census, like [Bitcoin's](/concepts/byte-census-t1/), counting every block's bytes by region; - the share of those bytes carried by inscriptions: on Litecoin, the share carried by [Litebars](https://blockspace.wiki/glossary/litebars/), a collection held by [Blockspace Holdings](https://blockspace.wiki/glossary/blockspace-holdings/); on Dogecoin, the share carried by Doginals, Dogecoin's inscriptions. ## Where it stands It cannot start yet. The card says: "No Litecoin or Dogecoin node runs on this server yet; the study starts when one does." Its data is "Litecoin and Dogecoin full nodes (not yet running)". It is a descriptive card, and no figures for either chain are claimed. ## Links The card links to Litebars on https://blockspace.holdings, which lists the company's holdings. [Inscriptions](/concepts/inscriptions/) explains inscriptions on Bitcoin, the model for both. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records Updated: 2026-10-20 --- # Lost sats Research: sats that coinbase transactions never claimed, so they exist in no output: where and when they were lost. URL: https://blockspace.wiki/research/lost-sats/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it studies The Labs site describes [lost sats](https://blockspace.wiki/glossary/lost-sats/) as "sats that coinbase transactions never claimed, so they exist in no output", and asks "where and when they were lost." [ord](https://blockspace.wiki/glossary/ord/), which numbers every sat, counts them on its status page. The count says how many; the study asks which blocks lost them, and when. ## The data it will use "ord sat index (/status lost_sats)": the count that the ord server behind [blockspace.to](/projects/blockspace.to/) reports on its public status page. ## The figure on the card It is one of the Research cards that shows a current figure, because one already exists with an "as of". The card read **2,895,844,904 lost sats** at 2026-10-20 09:07:08 UTC. The wiki's own reading is 2,895,844,904 (as of block 972,304, 2026-10-20 10:17:29 UTC), from https://blockspace.to/status. The count is the study's starting point. Where and when the sats were lost is the open question, and the card claims no answer yet. ## Related pages [Sats and ordinals](/concepts/sats-and-ordinals/) explains how ord numbers sats. [Cursed inscriptions](/research/cursed-inscriptions/) is another Research card read from the same ord index. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - Blockspace Holdings records - ord /status (the blockspace.to ord server) · https://blockspace.to/status Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # Low-fee propagation Research: which sub-1 sat/vB transactions the Labs mempool keeps actually get mined, by which pools, and how long they wait. URL: https://blockspace.wiki/research/low-fee-propagation/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it studies The Labs site asks: "Which sub-1 sat/vB transactions our mempool keeps actually get mined, by which pools, and how long they wait." The Labs node practises [sub-1 sat/vB relay](https://blockspace.wiki/glossary/sub-1-sat-vb-relay/): its [fee floor](https://blockspace.wiki/glossary/fee-floor/) is 0 sat/vB (as of block 972,304, 2026-10-20 10:17:29 UTC), so it keeps transactions that a node at Bitcoin Core's default floor of 1 sat/vB would refuse. Keeping a transaction in the [mempool](https://blockspace.wiki/glossary/mempool/) does not mean a miner will include it. This study follows those transactions from the mempool into blocks: which ones are mined, which pools mine them, and how long each waits first. ## The data it will use "bitcoind mempool against the blocks that follow": the Labs node, comparing what its mempool held with what the next blocks contained. It is a descriptive card; no results are claimed. ## Related research It extends the Live project [sub-1 sat/vB relay](/research/sub-1-sat-vb-relay/). [The sub-1 sat/vB share](/research/sub-1-sat-vb-share/) measures how much of the mempool pays below 1 sat/vB. The [policy observatory](/research/policy-observatory/) counts sub-1 sat/vB transactions among those that standard relay would refuse, and [fee rate](/concepts/fee-rate/) explains the unit. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records Live figures: relay as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # Permanent bytes: what to store on Bitcoin, and how Research: every byte on Bitcoin is permanent and costly. What deserves that, and how is each byte best spent? Seven questions, each tied to the data that could answer it. URL: https://blockspace.wiki/research/permanent-bytes/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it asks The card opens: "Every byte on Bitcoin is permanent and costly. What deserves that, and how is each byte best spent?" It splits the question into seven parts: 1. **What's been stored:** every inscribed byte by kind, over time, and what it paid. 2. **Format efficiency:** bytes per pixel by image format; how often brotli compression is used and what it saves. 3. **Duplication:** identical files inscribed more than once, and what the copies cost. 4. **Reuse, not repeat:** how many bytes [recursion](https://blockspace.wiki/glossary/recursive-inscription/) and [delegation](https://blockspace.wiki/glossary/delegate-inscription/) save. 5. **Cost per permanent byte:** fee per content byte, against the [witness discount](/concepts/witness-discount/). 6. **Link rot:** inscriptions that point off-chain, and how many of those links still answer. 7. **What lasts:** which formats stay readable, and what belongs on-chain whole, as a hash, or not at all, "since nothing can be deleted". ## The data it will use "The byte census, ord's inscriptions, the largest-inscriptions ranking, BTI books and fees." Each is already kept by [Blockspace Holdings' node and indexers](https://blockspace.wiki/glossary/blockspace-holdings-node-and-indexers/): [the byte census](/research/byte-census/), the ord index behind [blockspace.to](/projects/blockspace.to/), the ranking at https://block.space/largest-inscriptions, and [the three books](/concepts/the-three-books/). ## The figure on the card The card shows one current figure: 128,169,266 inscriptions in ord, as of 2026-10-20 09:07:08 UTC. The wiki's own reading is 128,169,401 (as of block 972,304, 2026-10-20 10:17:29 UTC). No result of the study is claimed. [Inscriptions](/concepts/inscriptions/) explains how files are inscribed. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - Blockspace Holdings records - ord /status (the blockspace.to ord server) · https://blockspace.to/status Live figures: ord as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # Policy observatory Research: count the transactions mined each block that standard relay would refuse, and how much blockspace reaches miners off the standard relay path. URL: https://blockspace.wiki/research/policy-observatory/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it studies The Labs site describes it in two sentences: it "counts the transactions mined each block that standard relay would refuse: over 100 kvB, large OP_RETURN, below 1 sat/vB. How much blockspace reaches miners off the standard relay path." Bitcoin's consensus rules decide what a block may contain. Relay policy decides what ordinary nodes pass on before a block is found. A transaction can be valid but not a [standard transaction](https://blockspace.wiki/glossary/standard-transaction/), and still be mined if it reaches a miner some other way. The study counts three kinds: - transactions over 100 kvB (400,000 weight units), the standard size limit; - large [OP_RETURN](https://blockspace.wiki/glossary/op-return/) outputs, above the data-carrier limit (83 bytes, the Bitcoin Core 28 default the Labs node runs); - transactions paying below 1 sat/vB, the default [fee floor](https://blockspace.wiki/glossary/fee-floor/). ## The data it will use "BTI byte census and bitcoind blocks": [the byte census](/research/byte-census/) for each block's bytes, and the Labs node for the blocks themselves. It is a descriptive card; no results are claimed. ## Related research Its measured effects feed [blockspace expansion policy](/research/blockspace-expansion-policy/). [4 MB transaction relay](/research/4mb-transaction-relay/) concerns the same 100 kvB limit, and [low-fee propagation](/research/low-fee-propagation/) the same sub-1 sat/vB transactions. The [relay policy](/concepts/relay-policy/) page describes each limit. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records Updated: 2026-10-20 --- # Sub-1 sat/vB relay Live: the Blockspace Labs node relays and keeps transactions paying less than 1 sat/vB, on stock Bitcoin Core with minrelaytxfee=0. URL: https://blockspace.wiki/research/sub-1-sat-vb-relay/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Live**, the first card in the Live group. ## What it is [Blockspace Labs](https://blockspace.wiki/glossary/blockspace-labs/) describes it in one line: "Our node relays and keeps transactions paying less than 1 sat/vB, the default floor of Bitcoin Core." This is [sub-1 sat/vB relay](https://blockspace.wiki/glossary/sub-1-sat-vb-relay/). The node runs stock Bitcoin Core, not a patched build, with its [fee floor](https://blockspace.wiki/glossary/fee-floor/) (`minrelaytxfee`) set to 0. So a transaction that pays a [fee rate](https://blockspace.wiki/glossary/fee-rate/) below 1 sat/vB still enters the node's [mempool](https://blockspace.wiki/glossary/mempool/) and is passed on to its peers. ## What the card shows The card shows the node's version, its fee floor, the mempool's size and the part of it paying below 1 sat/vB. A transaction counts as sub-1 when its base fee in sats is less than its vsize. In the reading of 2026-10-20 09:07:08 UTC, at block 972,298, the mempool held 38,991 transactions (23.7 vMB), and 38,265 of them (23.6 vMB) paid below 1 sat/vB. The wiki's own reading of the node's policy, as of block 972,304, 2026-10-20 10:17:29 UTC: - node: /Satoshi:28.2.0/; - fee floor: 0 sat/vB; - incremental relay fee: 1 sat/vB; - [full-RBF](https://blockspace.wiki/glossary/full-rbf/): on; maximum mempool: 300 MB. ## How the figures are read Every figure on blockspacelabs.com "is read from our own node and indexers", once an hour, and nothing is loaded from elsewhere. For this card the job asks the node for its mempool and network information. A source that fails keeps its last reading with its own "as of". The card links to the mempool explorer at https://explore.block.space. ## Related research Two Research cards build on this one: [the sub-1 sat/vB share](/research/sub-1-sat-vb-share/), a series of the share hour by hour, and [low-fee propagation](/research/low-fee-propagation/), which asks which of these transactions get mined. [Relay policy](/concepts/relay-policy/) puts the floor beside the node's other policy settings. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - Blockspace Holdings records Live figures: relay as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # The sub-1 sat/vB share Research: hour by hour, how much of a mempool with no fee floor pays below 1 sat/vB, and what it would have paid at the default floor. URL: https://blockspace.wiki/research/sub-1-sat-vb-share/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it studies The Labs site describes it as: "Hour by hour, how much of a mempool with no fee floor pays below 1 sat/vB, and what it would have paid at the default floor." The Labs node's [fee floor](https://blockspace.wiki/glossary/fee-floor/) is 0 sat/vB (as of block 972,304, 2026-10-20 10:17:29 UTC), so its [mempool](https://blockspace.wiki/glossary/mempool/) holds transactions that pay less than Bitcoin Core's default of 1 sat/vB. The study turns single readings into a series: the share of the mempool below 1 sat/vB each hour, and the fees those transactions would have paid at 1 sat/vB. ## The data it will use "bitcoind getrawmempool, read hourly by this site's refresh job." The site's hourly job already reads the mempool; the study keeps those readings as a series. A transaction counts as sub-1 when its base fee in sats is less than its vsize. ## The figure on the card It is one of the Research cards that shows a current figure, because one already exists with an "as of". At 2026-10-20 09:07:08 UTC, block 972,298, the share was **98.1 % of transactions**: 38,265 of 38,991. An earlier reading that day, at 08:32 UTC, found 43,585 of 44,646 (97.6 %). These are single readings, not the hourly series the study describes. ## Related research The Live project [sub-1 sat/vB relay](/research/sub-1-sat-vb-relay/) shows the current mempool. [Low-fee propagation](/research/low-fee-propagation/) asks which of these transactions are mined. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - Blockspace Holdings records Live figures: relay as of block 972,304, 2026-10-20 10:17:29 UTC Updated: 2026-10-20 --- # Testing the BVT Research: does the price per kilobyte track attributed bytes? A proposed empirical test of Blockspace Value Theory, an untested thesis. URL: https://blockspace.wiki/research/testing-the-bvt/ > Theory, not fact. Blockspace Value Theory is a living document and an untested thesis. BTP and BYTES are drafts describing things that do not exist. **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it asks The Labs site puts it in one question and one line: "Does the price per kilobyte track attributed bytes? An empirical test of the thesis." The thesis is [Blockspace Value Theory](https://blockspace.wiki/glossary/bvt/). In the site's own words it is "a living document and an untested thesis", and this wiki treats it the same way: BVT proposes that the bytes a token occupies on Bitcoin bear on its value. The [Blockspace Value Theory](/concepts/blockspace-value-theory/) page sets out what it proposes. This card describes a way to test it, not a result. ## How it would test it Two Live projects already produce the two sides of the comparison: - [the blockspace price](/research/blockspace-price/): asking prices across marketplaces, each turned into a [price per KB](https://blockspace.wiki/glossary/price-per-kb/) of blockspace on [the buy board](https://blockspace.wiki/glossary/buy-board/); - the [Blockspace Token Indexer](https://blockspace.wiki/glossary/bti/): the bytes attributed to each token in [the three books](/concepts/the-three-books/). The study asks whether the first tracks the second. The card names its data as "the buy board and the BTI books". ## Where it stands It is a descriptive card: it says what the test is and which data it would use. No test has run, and no result is claimed either way. The card links to https://block.space/docs/bvt, "Read the BVT". Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records - Blockspace Value Theory · https://block.space/docs/bvt - block.space docs: Blockspace Value Theory · https://block.space/docs/bvt Updated: 2026-10-20 --- # Who holds blockspace Live: the holders of every token's bytes, ranked by address. It powers the block.space leaderboard. URL: https://blockspace.wiki/research/who-holds-blockspace/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Live**, the fifth card in the Live group. ## What it is The Labs site describes it as "the holders of every token's bytes, ranked by address. It powers the block.space leaderboard." Each token is backed by the bytes BTI attributes to it. This project follows each token to the addresses that hold it, and adds up the bytes behind each address's tokens. The holdings are kept in [the holders appendix](https://blockspace.wiki/glossary/the-appendix/), which is updated block by block. The [holders](/concepts/holders/) page explains how holdings are measured and which protocols are covered. The result is [the leaderboard](https://blockspace.wiki/glossary/the-leaderboard/): every address ranked by the blockspace its tokens are backed by. ## What the card shows The card shows how many holders are ranked and the block their holdings are as of. In the reading of 2026-10-20 09:07:11 UTC, 4,491,876 holders were ranked, with holdings as of block 972,199. The wiki's own reading, as of block 972,199, 2026-10-20 09:22:01 UTC: 4,491,923 holders, with holdings as of block 972,199. ## Links The card links to https://block.space/leaderboard and https://block.space/rankings. The [block.space](/projects/block.space/) page lists the site's ranking pages, and the Research card [inscription permanence](/research/inscription-permanence/) proposes to use the appendix's record of sat moves. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Labs facts (data/facts.json) · https://blockspacelabs.com - Blockspace Holdings records - block.space leaderboard API · https://block.space/api/leaderboard Live figures: holders as of block 972,199, 2026-10-20 09:22:01 UTC Updated: 2026-10-20 --- # The witness discount, by protocol Research: each token family's split of base and witness bytes, and what the discount saved it in fees. URL: https://blockspace.wiki/research/witness-discount-by-protocol/ **Status on [blockspacelabs.com](https://blockspacelabs.com): Research.** ## What it studies The Labs site describes it in one sentence: "Each token family's split of base and witness bytes, and what the discount saved it in fees." Bitcoin weighs a byte in the [witness](https://blockspace.wiki/glossary/witness/) at 1 weight unit and a byte in the base transaction at 4. That is the [witness discount](/concepts/witness-discount/): witness data costs a quarter as much per byte in fees. Token protocols carry their data in different places. Some put it in the witness, as ordinal [inscriptions](https://blockspace.wiki/glossary/inscription/) do; others put it in base data, such as an [OP_RETURN](https://blockspace.wiki/glossary/op-return/) output. So the discount helps some families far more than others. The study measures, family by family, how many of their bytes sit in each region and what they would have paid without the discount. ## The data it will use "BTI base/witness split and fees": [the byte census](/concepts/byte-census-t1/) records every block's bytes by region, and [the three books](/concepts/the-three-books/) attribute them to tokens along with the fees paid. The card links to https://block.space/docs/bti, "The books". It is a descriptive card; no results are claimed. ## Related pages [Weight units and vbytes](/concepts/weight-units-and-vbytes/) explains how a transaction is weighed. The discount is also one of the consensus levers in [blockspace expansion policy](/research/blockspace-expansion-policy/), and part five of [permanent bytes](/research/permanent-bytes/) weighs fee per content byte against it. Sources: - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - Blockspace Holdings records - block.space protocols API · https://block.space/api/protocols Updated: 2026-10-20 --- # Timeline Dated, sourced events, the estate's launches and Bitcoin's own milestones. URL: https://blockspace.wiki/timeline/ Every entry has a date and a source. Bitcoin's own milestones are given at the height Blockspace Holdings' BTI records for them, dated by that block's header time (UTC) as https://explore.block.space reports it. - 2009-01-03: The genesis block, block 0, is mined. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs) - 2012-11-28: The first halving, at block 210,000: the block subsidy falls from 50 to 25 BTC. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs) - 2013-03-29: The first [OP_RETURN](https://blockspace.wiki/glossary/op-return/) output on Bitcoin appears at block 228,596, a year before Bitcoin Core 0.9 made it standard. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs) - 2013-07-31: Mastercoin, later Omni, opens its Exodus fundraiser at block 249,498. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs) - 2014-01-02: [Counterparty](https://blockspace.wiki/glossary/counterparty/)'s proof-of-burn begins at block 278,310. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs) - 2016-07-09: The second halving, at block 420,000. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs) - 2017-08-24: SegWit activates at block 481,824, and with it the [witness discount](/concepts/witness-discount/). (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs, Blockspace Value Theory) - 2020-05-11: The third halving, at block 630,000. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs) - 2021-11-14: [Taproot](https://blockspace.wiki/glossary/taproot/) activates at block 709,632, which makes the inscription envelope possible. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs) - 2022-12-14: Inscription #0 is made at block 767,430, the first ordinal [inscription](https://blockspace.wiki/glossary/inscription/). (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs, block.space protocols API) - 2023-01-31: The first [cursed inscription](https://blockspace.wiki/glossary/cursed-inscription/), inscription -1, appears at block 774,411. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs) - 2023-03-08: BRC-20 begins with the ordi deploy inscription at block 779,832. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs, block.space protocols API) - 2023-04-08: Inscription #1,000,000 is made, at block 784,528. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs) - 2023-05-03: KEVIN, the first SRC-20 token, is deployed at block 788,041. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs, block.space protocols API) - 2023-09-17: Atomicals and [ARC-20](https://blockspace.wiki/glossary/arc-20/) begin at block 808,080. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs) - 2024-01-06: ord's Jubilee at block 824,544, when cursed inscriptions are blessed. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs) - 2024-04-20: The fourth halving and the launch of Runes, at block 840,000. Rune #0 is UNCOMMON•GOODS. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs, Blockspace Value Theory, block.space protocols API) - 2024-11-27: The Bitbar minting app behind [mintbitbars.xyz](/projects/mintbitbars.xyz/) is first written. (source: Blockspace Holdings records, The mintbitbars.xyz checkout (antron3000/Bitbar-Minting-App): index.html, server/, minter/) - 2025-01-20: Alkanes activates at block 880,000; its first message runs four blocks later, at 880,004. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs, block.space protocols API) - 2025-06-20: Counterparty v11 taproot envelopes become mandatory at block 902,000. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs, Blockspace Value Theory) - 2025-06-20: Bitcoin Counters begins: counter #0 (XDUALS) at block 902,005. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs, Bitcoin Counters v3, indexer and wallet: README (BitcoinCounters/counters)) - 2025-07-14: Inscription #100,000,000 is made, at block 905,492. (source: Blockspace Holdings records, explore.block.space REST API, read-only GETs) - 2026-06-25: Work begins on the Bitcoin Counters indexer and wallet, the index behind [counters.gallery](/projects/counters.gallery/). (source: Blockspace Holdings records, Bitcoin Counters v3, indexer and wallet: README (BitcoinCounters/counters)) - 2026-08-02: The Meter becomes block.space's main page, with its own explorer of transactions and bytes beside it. (source: Blockspace Holdings records) - 2026-08-02: Blockspace Value Theory, the Shared Claim Axiom and the BTP and BYTES drafts get a version history. (source: Blockspace Holdings records, Blockspace Value Theory) - 2026-08-06: [BTI](https://blockspace.wiki/glossary/bti/) is designed from first principles (draft 0.2), with Ruleset v1 and the [three books](/concepts/the-three-books/), A, B and C. (source: Blockspace Holdings records) - 2026-08-10: BTI is rebuilt: the T1 and T2 engine, 22 adapters and the token table, with one adapter per metaprotocol indexer. (source: Blockspace Holdings records) - 2026-08-11: block.space runs on the rebuilt BTI. (source: Blockspace Holdings records) - 2026-09-07: Work begins on [counters.fun](/projects/counters.fun/), Counters with XCP liquidity pools. (source: Blockspace Holdings records, counters.fun README (BitcoinCounters/counters.fun)) - 2026-09-23: Work begins on the [degent.club](/projects/degent.club/) site and mint. (source: Blockspace Holdings records) - 2026-10-18: block.space publishes [the leaderboard](https://blockspace.wiki/glossary/the-leaderboard/): every address ranked by the blockspace its tokens are backed by. (source: Blockspace Holdings records, block.space leaderboard API) - 2026-10-18: block.space publishes /largest-inscriptions, the largest inscriptions in order. (source: Blockspace Holdings records) - 2026-10-18: block.space publishes /heaviest-tokens, the heaviest tokens in order, family by family. (source: Blockspace Holdings records) - 2026-10-19: [The appendix](https://blockspace.wiki/glossary/the-appendix/) of holders is filled: 125,438,419 sats and 4,460,161 addresses, with 85.7 % of Book A on addresses; from then on it is updated block by block. (source: Blockspace Holdings records) - 2026-10-19: /largest-inscriptions ranks each inscription, and /heaviest-tokens ranks tokens 100,000 deep per protocol. (source: Blockspace Holdings records) - 2026-10-19: The three rankings share one frame, and block.space publishes its rankings docs. (source: Blockspace Holdings records, block.space docs: rankings) - 2026-10-19: block.space adopts the [five-colour family key](https://blockspace.wiki/glossary/five-colour-family-key/): five families, then Other. (source: Blockspace Holdings records) - 2026-10-19: The sat family is named [Ordinal Sats](https://blockspace.wiki/glossary/ordinal-sats/). (source: Blockspace Holdings records) - 2026-10-19: /largest-inscriptions becomes a grid of squares, each showing the inscription's own content. (source: Blockspace Holdings records) - 2026-10-19: block.space/projects lists every project, one per domain. (source: Blockspace Holdings records, The project list at block.space/projects) - 2026-10-19: [blockspace.holdings](/projects/blockspace.holdings/) is live at its own address. (source: The project list at block.space/projects, Blockspace Holdings records) - 2026-10-19: [degent.club](/projects/degent.club/) is live again at its own address. (source: The project list at block.space/projects) - 2026-10-19: [spaceblocks.art](/projects/spaceblocks.art/) is live: one image that fills a 1 MB block. (source: The project list at block.space/projects, Blockspace Holdings records) - 2026-10-19: [blockspace.news](/projects/blockspace.news/) is live, with a daily edition in numbers from block.space. (source: The project list at block.space/projects, Blockspace Holdings records) - 2026-10-19: [blockspace.markets](/projects/blockspace.markets/) is live: blockspace for sale, priced per kilobyte. (source: The project list at block.space/projects, Blockspace Holdings records) - 2026-10-19: [mintbitbars.xyz](/projects/mintbitbars.xyz/) is live. (source: The project list at block.space/projects, Blockspace Holdings records) - 2026-10-20: [blockspacelabs.com](/projects/blockspacelabs.com/) goes live with its research cards. (source: The project list at block.space/projects, Blockspace Holdings records, The blockspacelabs.com page (index.html)) - 2026-10-20: [blockspace.to](/projects/blockspace.to/), the spent-sats ord explorer, goes live. (source: The project list at block.space/projects, The blockspacelabs.com page (index.html)) - 2026-10-20: [litepedia.space](/projects/litepedia.space/) answers at its own address, Coming soon. (source: The project list at block.space/projects, Blockspace Holdings records) - 2026-10-20: [Scribbit](/projects/scribb.it/) gets its descriptive site; scribb.it is Coming soon. (source: Blockspace Holdings records, The project list at block.space/projects) - 2026-10-20: block.space publishes /collections: NFT collections on Bitcoin, ranked by blockspace. (source: Blockspace Holdings records) - 2026-10-20: The leaderboard's bars and key run largest family first. (source: Blockspace Holdings records) - 2026-10-20: blockspace.wiki is built. (source: Blockspace Holdings records, blockspace.wiki README) Sources: - The project list at block.space/projects · https://block.space/projects - Blockspace Holdings records - explore.block.space REST API, read-only GETs · https://explore.block.space/api/blocks/tip/height - Blockspace Value Theory · https://block.space/docs/bvt - block.space protocols API · https://block.space/api/protocols - Bitcoin Counters v3, indexer and wallet: README (BitcoinCounters/counters) · https://github.com/BitcoinCounters/counters - The mintbitbars.xyz checkout (antron3000/Bitbar-Minting-App): index.html, server/, minter/ · https://github.com/antron3000/Bitbar-Minting-App - counters.fun README (BitcoinCounters/counters.fun) · https://github.com/BitcoinCounters/counters.fun - block.space leaderboard API · https://block.space/api/leaderboard - block.space docs: rankings · https://block.space/docs/rankings - The blockspacelabs.com page (index.html) · https://blockspacelabs.com - blockspace.wiki README · https://blockspace.wiki Updated: 2026-10-20 --- # Sources The bibliography, every document, spec and data source the wiki cites, and which pages cite it. URL: https://blockspace.wiki/sources/ Every source with a public address is listed here, with the pages that cite it. Facts from Blockspace Holdings' own records, node and indexers are cited as "Blockspace Holdings records". Live data is read hourly, and each figure on a page carries its "as of". - **Atomicals as a natural experiment for BVT** · https://block.space/docs/atomicals - **BTP, the Blockspace Token Protocol, draft 0.1** · https://block.space/docs/btp - **Blockspace Value Theory** · https://block.space/docs/bvt - **BYTES, a fungible blockspace token, draft 0.2** · https://block.space/docs/bytes - **Bitcoin Counters build reference v3** · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/build-reference-v3.md - **Counters notes** · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/notes.md - **Bitcoin Counters v3, indexer and wallet: README (BitcoinCounters/counters)** · https://github.com/BitcoinCounters/counters - **Counters server: rendering rules** · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/rules.md - **XCP wallet and transactions: a field guide** · https://github.com/BitcoinCounters/counters/blob/HEAD/docs/xcp-wallet-transactions.md - **counters.fun README (BitcoinCounters/counters.fun)** · https://github.com/BitcoinCounters/counters.fun - **DegentClub/degent ART-AND-TRADEMARKS** · https://github.com/DegentClub/degent - **DegentClub/degent GOVERNANCE** · https://github.com/DegentClub/degent - **DegentClub/degent README** · https://github.com/DegentClub/degent - **DegentClub/degent TRADEMARKS** · https://github.com/DegentClub/degent - **Devcash site copy, from the reference clone (locales/en.json)** · https://devcash.dev - **block.space docs: Atomicals** · https://block.space/docs/atomicals - **block.space docs: the axiom** · https://block.space/docs/axiom - **block.space docs: BTI** · https://block.space/docs/bti - **block.space docs: BTP** · https://block.space/docs/btp - **block.space docs: Blockspace Value Theory** · https://block.space/docs/bvt - **block.space docs: BYTES** · https://block.space/docs/bytes - **block.space docs: data types** · https://block.space/docs/datatypes - **block.space docs: measurements** · https://block.space/docs/measurements - **block.space docs: rankings** · https://block.space/docs/rankings - **blockspace-explorer REST API documentation (frontend/src/app/docs/api-docs/api-docs-data.ts), served at /docs/api/rest** · https://explore.block.space/docs/api/rest - **blockspace-explorer nginx-mempool.conf: the /api, /api/v1 and /ws routes** · https://github.com/BLOCKdotSPACE/blockspace-explorer - **BLOCKdotSPACE/blockspace-explorer README** · https://github.com/BLOCKdotSPACE/blockspace-explorer - **The blockspace.holdings page (site/index.html)** · https://blockspace.holdings - **Blockspace Labs facts (data/facts.json)** · https://blockspacelabs.com - **The blockspacelabs.com page (index.html)** · https://blockspacelabs.com - **The litepedia.space landing page (index.html)** · https://litepedia.space - **block.space JSON API, read-only GETs (every /api/* endpoint)** · https://block.space/api/summary - **block.space buy board API (/buy/api/board, /buy/api/status)** · https://block.space/buy/api/board - **The counters server /status (the index behind counters.gallery)** · https://counters.gallery/status - **block.space leaderboard coverage API (holders measured per protocol)** · https://block.space/api/leaderboard/coverage - **explore.block.space REST API, read-only GETs** · https://explore.block.space/api/blocks/tip/height - **block.space frontier API (the three tier cursors and the chain tip)** · https://block.space/api/frontier - **block.space leaderboard API** · https://block.space/api/leaderboard - **block.space meter and summary APIs** · https://block.space/api/summary - **ord /status (the blockspace.to ord server)** · https://blockspace.to/status - **blockspace.to ord JSON API, read-only GETs with Accept: application/json** · https://blockspace.to/status - **block.space protocols API** · https://block.space/api/protocols - **block.space rankings API (the four boards' top rows and their heights)** · https://block.space/api/rankings - **block.space live pages (/, /rankings, /leaderboard, /largest-inscriptions, /heaviest-tokens, /collections, /sync)** · https://block.space - **The project list at block.space/projects** · https://block.space/projects - **Scribbit facts: every figure on scribb.it with its source, and its glossary (facts.json)** · https://scribb.it/facts.json - **The Shared Claim Axiom** · https://block.space/docs/axiom - **bitmap.holdings, its own home page, read 2026-10-20** · https://bitmap.holdings - **The blockspace.loans landing page and README** · https://blockspace.loans - **The blockspace.markets site: README, tools/build.py and the page** · https://blockspace.markets - **The mintbitbars.xyz checkout (antron3000/Bitbar-Minting-App): index.html, server/, minter/** · https://github.com/antron3000/Bitbar-Minting-App - **The blockspace.news site: README, tools/build.py and the editions** · https://blockspace.news - **The blockspace.space landing page and README** · https://blockspace.space - **The spaceblocks.art site: README, index.html, whole-blocks/ and tools/build.py** · https://spaceblocks.art - **blockspace.wiki README** · https://blockspace.wiki - Blockspace Holdings records: Blockspace Holdings' own records, node and indexers (no public address) Updated: 2026-10-20 --- # Errata Corrections to the wiki, dated, never silently erased. URL: https://blockspace.wiki/errata/ When a page is corrected, the correction is listed here with its date and the page it changed. The page's own history is in the repository. - 2026-08-05 /protocols/alkanes/: Alkanes' first message on mainnet runs at block 880,004, four blocks after alkanes activates at 880,000. An earlier figure of 897,413 marked where an explorer had been pointed, not where alkanes starts; it was 17,409 blocks late. - 2026-10-19 /glossary/ordinal-sats/: block.space's name for the sat family is Ordinal Sats. Until 2026-10-19 it read "Individual Sats". Only the label changed: the key stays `sat` in every URL, API field and database row. - 2026-10-19 /glossary/five-colour-family-key/: block.space's colour key gives five families their own colour and every other family a grey Other. It replaces a first key that gave eight families their own hues; in a stacked bar some neighbours, such as BRC-20 and ARC-20, were too close to tell apart. - 2026-10-20 /glossary/five-colour-family-key/: The leaderboard's composition bars, and the key row above the table, run largest family first. Before 2026-10-20 the bars kept one fixed family order on every row. - 2026-10-20 /glossary/blockspace-holdings/: The company's name is Blockspace Holdings. Pages published before 2026-10-20 used an older form of the name. - 2026-10-20 /projects/degent.club/: degent.club's 10,000 is the size of the collection when fully minted, not a count of Degents that exist; the live count is {{degent.inscribed}} inscribed ({{asof:degent}}). The old site's figure of 4,027 minted disagreed with the collection list. Sources: - Blockspace Holdings records - block.space protocols API · https://block.space/api/protocols - The project list at block.space/projects · https://block.space/projects Updated: 2026-10-20