counters.gallery

Q: How can two explorers be sure they agree?

Each counter extends a rolling hash . Two indexers agree on the whole history if and only if their latest rolling hash matches.

Bitcoin Counters explorer: numbered inscriptions in Bitcoin witness data, owned through Counterparty assets.

Status: Live
Site: counters.gallery
Source: github.com/BitcoinCounters/counters
As of: 2026-10-20

What it is #

counters.gallery is the explorer for Bitcoin Counters. 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, carried in a Counterparty taproot envelope. 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 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, 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 is shown as text, HTML and SVG run sandboxed, and a reinscription adds a new counter to the same asset. A counterparty + ord counter is also an ordinals inscription. The market layer over this index is 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 asset, carried in a Counterparty taproot envelope, and given a global, gap-free number in order of creation, from #0. It passes two tests at once: the bytes are the description of a valid Counterparty issuance or fairminter deploy, and they reached the chain inside witness data. Either test alone is nothing.
Counterparty: The protocol whose assets carry counters. For counters it supplies identity, ownership, naming, transfer and, since its v11 taproot envelope, the content itself. Counterparty Core is its node software. It decides message validity, asset identity, ownership and content; the counters indexer never reimplements that consensus. ("Bitcoin Core" is the separate Bitcoin node; the counters docs always name the two in full.)
counterparty + ord: The style of Counterparty taproot envelope that Counterparty Core emits with inscription=true: the same envelope plus the ordinals framing, with every field an official ordinals tag and tag 7 carrying xcp. Its reveal creates two independently ownable assets: the Counterparty asset, and an ordinals inscription on its own output. The stored value is counterparty/ord. The first five counters are all this style.
Counterparty DEX: Counterparty's on-chain order book. An order gives one asset to get another, with BTC allowed on either side; a non-BTC give is escrowed until the order fills, expires or is cancelled, and a matched BTC leg must be paid within about 20 blocks. Counterparty has one trade message, and consensus alone decides whether it fills against the book or a liquidity pool.
Counterparty taproot envelope: Counterparty v11's witness-data encoding, active from block 902,000: an OP_FALSE OP_IF … OP_ENDIF tapscript revealed by a commit and reveal transaction pair. The message, an asset's description included, travels as data pushes in the reveal's input-0 witness; the output side holds only the literal CNTRPRTY OP_RETURN marker. Two styles exist, the size-optimised counterparty native envelope and the counterparty + ord envelope, and both carry counters equally.
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; the fairmints that follow never are, so "a fair-minted collection gets one counter at deploy". Since Counterparty Core v11.2's fairmint_pool gate (mainnet block 961,100) a fairminter can seed a liquidity pool at soft cap with every satoshi it raised, minting the LP tokens to the unspendable address.
liquidity pool: A constant-product reserve pair on Counterparty, with its own LP token, native since Counterparty Core v11.1's amm_pools gate. There is no "create pool" message: the first deposit creates the pool, and its two amounts set the opening price. counters.fun lists the counters that have pools against XCP.
LP token: The token a Counterparty liquidity pool gives its depositors. Burning LP tokens takes both assets back pro rata. LP tokens sent to the unspendable address lock the liquidity, and counters.fun shows that lock as the share of LP supply at the burn address.
pointer counter: A counter whose content is a single URI token (ipfs:, ar://, http(s)://) rather than a file. It is a full, valid counter, but only the pointer is on chain. A counters server shows the pointer text and never fetches it; counters.fun does not display pointer counters at all.
price per KB: counters.fun's price against on-chain size: the market cap spread over the bytes the asset carries on chain, summed over every counter on it, so price × circulating supply ÷ KB, in the price's own unit. Every pooled card, dispenser card and DEX row on counters.fun shows it.
reinscription: New content attached to a Counterparty asset you own: a Counterparty reissuance with a fresh taproot-carried description (quantity 0, on counters.fun's mint page). It is numbered like any other counter. Numbering is per event, so an unlocked asset collects a new counter each time; its lowest-numbered counter is its original, and no earlier counter is erased.
reveal transaction: In a Counterparty taproot mint, the commit transaction pays to a taproot address committing to the envelope tapscript. The reveal transaction spends that output by the script path, exposing the envelope in input 0's witness, and carries an OP_RETURN holding only the literal marker CNTRPRTY. The reveal is the transaction Counterparty parses and the one a counter is keyed to. An unrevealed commit is nothing.
rolling hash: How independent counters indexers check that they agree. Each counter extends a SHA-256 chain over its number, transaction, position, kind, asset and content hash, seeded from the tag counters:v3:bitcoin-mainnet:902000. Two indexers agree on the whole history if and only if their latest rolling hash matches. It is not BTI's consensus hash.
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 ledger. BTI's token catalogue calls XCP assets "the first blockspace tokens (2014)", counts XCP itself as one, and lists counters as a subset. An asset's description can hold a file; when it reaches the chain in a Counterparty taproot envelope, that description is a counter. On counters.fun's mint page, a named asset burns 0.5 XCP.

FAQ #

What is a counter? #

A counter is a file committed to Bitcoin as the description of a Counterparty asset, carried in witness data by a Counterparty 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 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. Two indexers agree on the whole history if and only if their latest rolling hash matches.