Counterparty

XCP assets, the first blockspace tokens (2014), with Stamps and Counters as subsets: one asset, one claim, however many sources sight it.

Counterparty 0.16 % of the chain's bytes in Book A, as of block 972,299, 2026-10-20 09:30:48 UTC

XCP assets are the assets of the Counterparty ledger. 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, 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 messages, ARC4-encrypted, and bare multisig outputs; its earliest channel was fake P2PKH data outputs. Counterparty Core v11.0.0 added a taproot envelope, active from block 902,000. The message then travels in the reveal's input-0 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 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 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 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 (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 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; counters.fun pairs them with XCP pools (counters.fun).

The case studies show both envelope styles. In case 8, the counterparty + 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 #

Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC. Refreshed hourly.