counters.fun

Status: Live
Role: Product
Related: counters.gallery
Site: counters.fun
Source: github.com/BitcoinCounters/counters.fun
As of: 2026-10-20
For machines: knowledge.json · Markdown

What it is #

counters.fun is the market layer for Bitcoin Counters. 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, 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) knows files and numbers but not markets, and 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 (open orders) and dispensers. 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, a reinscription or a fairminter deploy, and the pool page opens, adds to or withdraws from a pool and can lock the LP tokens 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.

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.

Knowledge #

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 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 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 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, a reinscription on an asset you own, or a fairminter deploy whose description is the file. The XCP-69 preset follows xcp.fun's template and opens a liquidity pool at soft cap.