What a counter is

A Bitcoin counter is a numbered inscription: a file committed permanently to Bitcoin, stored in witness data, and bound to a Counterparty asset minted in the same transaction. The number marks its place in the sequence; the file is its content; the asset is the handle by which it is identified, owned, and transferred.

The asset does the heavy lifting — identity, ownership, naming, and transfer are all Counterparty's job — so the protocol layer stays small: a witness envelope plus an indexing convention.

The COUNT envelope

The file is serialized as data pushes inside a taproot script-path witness, wrapped in a skipped no-op. It is byte-for-byte ord's envelope with a different marker — so existing parsers are reusable.

OP_FALSE OP_IF
  OP_PUSH "COUNT"          # marker
  OP_PUSH 0x01           # tag 1 = content type
  OP_PUSH <content_type>  # MIME, e.g. image/png
  OP_0                   # separator; body begins
  OP_PUSH <file bytes>    # ≤520 bytes per push
OP_ENDIF
<pubkey> OP_CHECKSIG

Three things travel in the envelope: the COUNT marker, the MIME type, and the file. Nothing else — no pointer, parent, or metadata fields, because the asset already carries them.

Ownership

Whoever holds the Counterparty asset balance owns the counter. Transfer is an ordinary Counterparty send of that asset; the witness file never moves — it stays as permanent provenance pinned to the mint transaction.

Numbering

Counters are numbered globally, gap-free, starting at 0, ordered by block height then position within the block — the same scheme Ordinals uses. Only valid counters get a number.

Minting

A mint is a taproot commit/reveal pair, built and broadcast together. The reveal carries the file in its witness and the Counterparty issuance as a plain OP_RETURN.

# create a wallet (prints a seed phrase once)
counters wallet create --name me

# inscribe a file as a free numeric asset…
counters wallet --name me inscribe --file cat.png

# …or as a named asset (costs 0.5 XCP)
counters wallet --name me inscribe --file cat.png --asset MYCOUNTER

Validity

A transaction is a valid counter when all hold:

• its witness has a well-formed COUNT envelope;
• the same transaction has a Counterparty issuance that successfully mints an asset;
• it is that asset's first issuance;
• exactly one COUNT envelope is present;
• the asset is not BTC or XCP.

Validity depends on Counterparty's verdict, not an explorer's listing — an asset can appear indexed yet be an invalid issuance.

Server API

This explorer reads these endpoints from counters server:

• GET /status — latest synced block + total counter count
• GET /counters?before=N&limit=K — recent counters
• GET /counter/<number|asset> — one counter's record
• GET /block/<height> — counters minted in a block
• GET /content/<number> — the raw file, served with its stored MIME

Point the API constant at the top of this file's script at your server and the sample data is replaced by live results.

Source

Counters is open source — the indexer, CLI, and this explorer all live in one repository: github.com/antron3000/counters ↗.