# 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
