Counterparty's XCP Burn: 2,125 BTC Destroyed in a Month
Counterparty XCP proof-of-burn address
4°
this address's ancestry traces 4 degrees to the earliest coins
Between blocks 278,310 and 283,810 in early 2014, Counterparty distributed its native token by making people destroy bitcoin for it: no pre-mine, no sale, no refunds. The full ledger of that month still ships inside the software.
Counterparty launched in January 2014 as a protocol layer written on top of Bitcoin, authored by Adam Krellenstein, Evan Wagner and Robby Dermody. It needed a native token, XCP, to pay for protocol operations, and the founders chose a distribution method that gave them nothing: the only way to obtain XCP was to destroy bitcoin. The project's documentation is explicit about why. Proof of burn, it argues, "created an equal opportunity for all potential Counterparty users to acquire XCP, with no centralization or trust at all," avoided "issues with regulatory uncertainty and legal liability," and pointedly "does not provide the founders with starting capital (as with a 'pre-mine')." In January 2014, months before the token-sale era got going in earnest, that was an unusual position to take.
The mechanism is still legible in the reference implementation. config.py sets UNSPENDABLE_MAINNET to 1CounterpartyXXXXXXXXXXXXXXXUWLpVr, a constructed address whose hash has no known preimage, and fixes the window at BURN_START_MAINNET = 278310 and BURN_END_MAINNET = 283810. Block 278,310 was mined on 2 January 2014 at 20:11:51 UTC; block 283,810 on 2 February 2014 at 19:58:28 UTC. Inside that window, bitcoin sent to the address credited XCP at a rate decaying linearly with block height: 1000 + 500 x (BURN_END - block) / (BURN_END - BURN_START), so 1,500 XCP per BTC at the opening and 1,000 at the close. Each address was capped at one bitcoin.
The full ledger is not a matter of reconstruction; it ships as a static CSV inside the client. It records 2,576 burn transactions from 2,354 distinct source addresses, 2,125.63000728 BTC destroyed and 2,649,791.07838225 XCP created. The first accepted burn landed in block 278,319 and earned 1,499.18 XCP per BTC. The last, in block 283,810, earned exactly 1,000.00.
The edges are where the human detail is. Twelve transactions were credited for less than they sent, so roughly 1.045 BTC reached the burn address and earned nothing; seven of those broke the one-bitcoin ceiling outright. Sharper still, one address sent exactly 1 BTC to the burn address in block 283,811, sixteen minutes and twenty seconds after the closing block, and received zero XCP. It does not appear in the ledger at all. On the project forum a developer explained why it had lost the race under Bitcoin's then-current priority rules: the transaction's inputs had an age of zero blocks, giving it an effective priority of zero, while a competing 0.1 BTC burn carried a priority of 137,931 and made it into the earlier block. A month-long window, missed by a single block, on a fee policy that no longer exists.
What the burn bought turned out to matter. Overstock.com integrated Counterparty into its blockchain securities project in July 2014, work first called Medici that eventually became tZERO; EVM support was added in November 2014. More durably, Counterparty became the substrate for what are now treated as the first NFTs: EverdreamSoft issued FDCARD in March 2015, described as the first blockchain trading card and later folded into Spells of Genesis, and the first Rare Pepes were minted in September 2016, bought and sold with BTC or XCP. Emblem Vault began wrapping these assets as ERC-721 tokens in September 2020, and Bitcoin Stamps has used Counterparty for on-chain image storage since 2023. Counterwallet, the original web wallet, was discontinued in July 2024, while core developers returned that same year to work on stability, correctness and performance.
The address outlived its purpose. Payments kept arriving long after the window shut: 3,134 transactions have now touched it against the 2,576 the protocol ever credited, the most recent in August 2026, and every one of them bought nothing at all.
Timeline
Details
The whole burn ledger is a file in the client
counterparty-core ships mainnet_burns.csv, the canonical record: 2,576 burn transactions from 2,354 distinct addresses, 2,125.63000728 BTC destroyed, 2,649,791.07838225 XCP created. Nothing about the distribution has to be reconstructed from the chain.
The rate was a straight line in block height
burn.py computes the multiplier as 1000 + 500 x (BURN_END - block) / (BURN_END - BURN_START), with a hard one-bitcoin cap per address enforced across all of that address's burns. The first burn realised 1,499.18 XCP per BTC; the last realised exactly 1,000.00.
One burn missed the deadline by a single block
Transaction 38080960fbe94f9e1fb0725f0aff8efe844ffffd1779e006630f1577ffec415c put 1 BTC into the burn address in block 283,811 at 20:14:48 UTC, sixteen minutes and twenty seconds past the cutoff block, and earned zero XCP; its source address appears nowhere in the ledger. A developer traced the miss to the old priority rules: zero-age inputs meant zero priority, and a 0.1 BTC burn with priority 137,931 got in first.
Twelve transactions were credited for less than they sent
The ledger records twelve transactions whose credited amount is below the amount sent, about 1.045 BTC destroyed for no XCP at all. Seven of the twelve sent more than the one-bitcoin ceiling in a single transaction; the rest fell foul of the per-address cap or smaller shortfalls.
Why burn rather than sell
The documentation frames proof of burn as giving all prospective users equal opportunity with no centralisation or trust, while avoiding regulatory uncertainty and legal liability, and pointedly notes it "does not provide the founders with starting capital (as with a 'pre-mine')."
What is and is not established. The burn totals, transaction counts, per-transaction rates and shortfall figures were recomputed from mainnet_burns.csv as shipped in the reference implementation, and every one matched: 2,576 rows, 2,354 distinct sources, 2,125.63000728 BTC, 2,649,791.07838225 XCP, first burn at block 278,319 realising 1,499.18 XCP per BTC and the last at 283,810 realising exactly 1,000. The constants 278310 and 283810 and the burn address were read from config.py, the rate formula and the one-bitcoin cap from burn.py, and all three block timestamps from chain data. The late burn was verified on-chain: 1 BTC to 1CounterpartyXXXXXXXXXXXXXXXUWLpVr in block 283,811, from source address 12gcRUPqEqQkdCzjKBPTqfirZ4b7L2GKM1, which does not appear anywhere in the ledger.
One correction was applied during checking. An earlier draft said twelve transactions sent more than the one-bitcoin ceiling; recomputation shows only seven did so in a single transaction. Twelve rows have credited amounts below the amount sent, from ten distinct addresses, and the roughly 1.045 BTC total is the sum of those shortfalls. Some of the smaller shortfalls are fractions of a satoshi-scale amount that the CSV alone does not fully explain, so the claim is now stated as "credited for less than they sent" rather than attributed entirely to the cap.
Two points of divergence with secondary sources are worth naming. Counterparty's own documentation describes the window as "5,000 Bitcoin blocks" running to 3 February 2014, whereas the constants in config.py give blocks 278,310 to 283,810, which is 5,500 blocks, with the closing block mined on 2 February; the code has been preferred. Published totals for BTC burned also vary, with Wikipedia giving approximately 2,140 BTC, because some counts include coins that arrived at the address outside the valid window; only the in-window figure is stated here. Founder names are given as they appear in project and encyclopaedic sources, which differ on whether the third author is "Robby" or "Robert" Dermody. The forum explanation of the missed burn comes from a developer posting under the handle jimhsu and is a contemporaneous account, not an audited finding. Per site policy, no balance is stated for the burn address; the 3,134 figure is a transaction count, not a balance.