BTP, the Blockspace Token Protocol

BTP is a draft (0.1, 2026-07-29) of a protocol whose subject is blockspace itself: which token owns which consumed bytes. It does not exist.

BTP, the Blockspace Token Protocol, is a design draft. Blockspace Holdings' records hold draft 0.1, dated 2026-07-29. It describes something that does not exist: its marker encoding, op codes and composition rules are, in its own word, "unwritten". The draft says of itself: "Status: design draft; decisions marked OPEN are undecided." This page reports what the draft describes.

What the draft describes #

The draft calls BTP "an attribution-layer protocol". It works on backing, the claim layer defined by the Shared Claim Axiom, rather than on any host protocol's ledger:

Where every existing metaprotocol answers "who owns which token," BTP answers "which token owns which consumed bytes," and makes that ownership transactable.

Its state would be "a set of backing assignments, deterministically derivable by anyone from chain data plus published rules." The draft calls it "the first protocol whose subject matter IS blockspace." It sees BTP as two passages of the axiom made operational: the idea that a new protocol could claim unclaimed blockspace, and the burn rules.

It places BTP in a stack: Blockspace Value Theory (the theory), the Shared Claim Axiom (the accounting rules), BYTES (the native token) and BTI (the reference indexer).

The operations #

The draft has one marker namespace with several operations per transaction. "Invalid ops mint or move nothing, and are measured as failed demand — never backing."

MINT issues BYTES against the transaction's own bytes. A declared amount is "valid iff x ≤ tx size in bytes; over-declaration is hard-invalid".
TRANSFER moves BYTES in explicit records; balances ride UTXOs. The handling of malformed transfers is OPEN.
SUCCEED is a directed burn: "Any token is burnable for any other token." It joins the provable destruction of token A, under A's own rules, to the naming of a successor B. A's backing then moves to B. This is backing succession.
ATTRIBUTE (proposed) declares "x bytes of this transaction's blockspace go to token X". The declarer claims only the residual, the bytes no other claimant's structure holds.
CLAIM (phase 2) attributes a historical transaction's unclaimed bytes to whoever proves they controlled one of its inputs. It is "Deliberately deferred" because it would open a large cheap-vintage supply.

Succession and conservation #

SUCCEED has two forms in the draft. In the donation form, B's total backing grows and its supply does not change, so every B holder's per-unit backing rises. It "needs nothing from B's protocol". In the exchange form, burning A also mints the target token to the burner, priced by A's backing at the burn height. Only BYTES would honour this at first, and it needs a "backing oracle".

Succession is terminal for A. Burned tokens cannot receive, so successions form a graph with no cycles. The draft names conservation as the invariant: "backing moves, it is never created."

The burn taxonomy #

The draft sorts every burn into three kinds. In all of them "the burn transaction itself claims its own bytes".

Burn	Per-unit backing	Where the backing goes
Undirected partial	rises doubly	stays inside the token
Directed (SUCCEED)	siblings unaffected	the successor
Full population, undirected	none (token dead)	co-claimants, else the blockspace is burned

The draft calls a simple burn "a double pump": the burn transaction adds bytes and the destroyed units reduce supply. Its example is Counterparty's XCP anti-spam fees, which are destroyed rather than paid: "3,858.58 XCP gone through block ~340k by BTI's measure."

Consensus and the reference indexer #

BTP state would be computed by BTI. The draft requires pinned, versioned rulesets; "A rolling consensus hash over BTP state for cross-indexer agreement"; and a reproducible backing figure for the exchange form. "Exchange therefore activates only when pinned-ruleset backing computation is reproducible across independent BTI instances." BTI's design, draft 0.2, takes these as requirements R12 and R13.

What the draft says it does to the theory #

It would give BVT's "one giant collection" thesis arbitrage plumbing, a mechanism that "could actually drive per-KB price convergence."
Holders of dead-protocol tokens, ARC-20 for example, could exit by burning into live tokens. The Atomicals experiment would gain "an observable exit ramp".
The honest cost: backing becomes "partly portable ballast". A token's history would be its own consumption plus what it received by succession.

OPEN decisions #

The draft leaves these undecided: the carrier and marker encoding (a runes-style OP_RETURN marker is "the lean"); defaults for malformed operations; whether SUCCEED-donation ships before exchange; and whether CLAIM is included at all.

Risks the draft states #

The concealed co-claim: minting or declaring against a transaction that also carries an unrecognised protocol's token, selling at face value and leaving the dilution to buyers. The draft's answer is "disclosure, not prohibition": publish unexplained bytes per claimed transaction and the backing-ratio history.
"BTP's authority is accounting-layer consensus". "Adoption is the protocol."
The exchange form inherits every open risk in BYTES, plus oracle reproducibility.
BTP transactions consume blockspace themselves, so the order in which operations in one transaction interact must be specified exactly.