Attribution and the Shared Claim Axiom

The Shared Claim Axiom: when several tokens claim the same consumed bytes, they share them equally. Plus the B19 draft, which proposes a different test.

The Shared Claim Axiom is the accounting rule under Blockspace Value Theory. It answers one question: when a token is said to represent consumed kilobytes, which kilobytes, and what happens when several tokens claim the same ones. It was noted on 2026-07-28 as a proposed refinement of BVT's definition of a blockspace token. Its own text says "'Shared equally' is explicitly a rule of thumb, not a derived result." This page describes the rule as the documents state it. It is theory, not a measured fact.

The axiom #

A blockspace token represents consumed kilobytes. When multiple tokens claim the same consumed bytes, the kilobytes are shared equally among the claims.

A token's backing is the bytes consumed divided by n, where n counts "distinct assets — separately ownable tokens — claiming the bytes". It does not count protocol names or owners. Who holds the tokens is irrelevant to the split.

The scope is "all kilobytes consumed during or by a transaction": the full serialized size, plus transactions that exist only to enable it, such as the commit half of a commit and reveal pair. Witness bytes count at full size, with no weight discount, in line with BVT.

Batches, enablers and fungible tokens #

Batch transactions. Each token owns its own payload bytes. The shared bytes (frame, signatures, overhead) split in proportion to each token's direct payload, with an equal split when no payload tells the claims apart. "Co-tenancy of a transaction is still not co-claiming of bytes."
Enabling transactions. Commit transactions, CPFP children and funding ("fuel") transactions join the pool of the operation they enable.
Fungible tokens. Backing is "the sum of all its lifecycle operations": deploy, every mint and every transfer. Backing grows with use. Per-unit backing is aggregate backing divided by surviving supply.

The axiom gives two reasons. Conservation: total backing across all tokens always equals total bytes consumed, with nothing double-counted or orphaned. Neutrality: an equal split needs no judgment about which claim is primary. "The rule of thumb is the Schelling point."

What counts as a claimant #

"A token is anything that is holdable and transferrable." The test: "can you transfer it by itself? It's a token. Does it only travel with something else? It's not."

From that test: "An envelope never claims. The token it is bound to claims." An inscription on a sat is claimed by the sat; a COUNT envelope or a stamp on a Counterparty asset is claimed by the asset. "An inscription is not a token. It is content bound to a token." Labels such as inscription, stamp or counter numbers name the content and add no claims. The axiom sums this up as three levels: "label → content → token. Only the last one claims." See inscriptions and sats and ordinals.

The consequence principle #

The axiom sharpens this with the consequence principle: a token claims bytes "iff the protocol assigned those bytes a consequence in that token's state". Its worked examples: a malformed runestone (cenotaph) burns input runes, so the burned runes claim it; a failed rune mint changes nothing and stays unclaimed; a failed BRC-20 mint is claimed by its inscription but not by the tick. Failed attempts are measured separately as failed-demand KB, "never part of backing".

Worked cases and dust claims #

The axiom's table gives one claimant (full bytes) for a plain inscription, stamp, rune or alkane, and for an alkanes contract deploy. A Counters v3 artifact with an ordinals-compatible envelope has two claimants, split 50/50; a bare envelope has one. A BRC-20 deploy or transfer inscription has two in principle.

Many such second claims are dust claims: "a valid claim whose standalone value sits below the cost and friction of exercising it". The split stays 50/50 on paper, but the market treats the share as going to the co-claimant. A famous deploy inscription is not a dust claim that woke up; its price is a provenance premium.

Unclaimed and burned blockspace #

"Most consumed blockspace has no claim on it at all." Payments, consolidations and sweeps sit at n = 0. So consumed blockspace has three states: claimed, unclaimed and burned. "Unclaimed is not burned. Burned blockspace exited the market; unclaimed blockspace never entered it."

The axiom adds that a new protocol could claim unclaimed bytes, for example by proof of authorship: signing with a key that controlled an input of a historical transaction. That would turn unclaimed bytes into tokenized blockspace, "Your own past consumption, tokenized after the fact." It calls the unclaimed pool "a vast latent supply". BTP drafts this as its CLAIM operation.

The burn rules: a burned claim's share goes to the other tokens on the same bytes, unless the burn directs it to a successor (BTP's SUCCEED). Only provable forever-unspendability counts as burned; "Key loss never counts as burned". When every token on some bytes is burned, that blockspace is burned, "the asset class's only deflationary sink". And "A claim's validity does not depend on anyone caring": dead but unburned tokens keep their claims.

The proposed revision to BVT #

The axiom ends with proposed wording for BVT §2.1: a blockspace token's backing is "measured as those kilobytes divided equally among the distinct tokens claiming the same bytes", and "attribution is shared, conserved, and concentrates only by burn."

Amendments of 2026-08-11 #

Blockspace Holdings' records of the axiom hold three amendments, ruled on 2026-08-11:

A1. Groups (collections, subasset families, series) are neither tokens nor labels. They never add claims or change n. Membership is fractional: k memberships weigh 1/k each. Ordinals collections are groups with curated membership, provenance class "asserted".
A2. A protocol total is a sum of shares. Backing, carrier slice and footprint are distinct quantities.
A3. Identity provenance is chain-derived, index-derived or flagged, plus asserted for group membership.

The B19 draft #

On 2026-07-31 a draft proposed one sentence to govern the axiom:

Bytes are attributed to a token iff they were bought for that token's purpose. Attribution is backing.

The draft is marked "Not applied": it is proposed wording for the owner's documents, not a change to them. It would demote the consequence principle "to a description" and make a failed operation claim its bytes: "failing at a token you do not hold donates backing to whoever does." It keeps carriage out: a token carried through a stranger's payment does not claim, because "Attributable" must mean "bought for, never identifiable with." It leaves one case open: a third party naming a rival's token in a failing operation.

The public axiom text still states the consequence principle and keeps failed attempts out of backing. BTI's own law went the other way. Ruleset v1 (2026-08-06) reads "Attribution is backing — one category (B19)" and makes a counterfactual test the gate, with "the consequence principle is the description". The public BTI docs say that a failed operation recorded in its protocol's ledger "still bought its blockspace, and those bytes count as backing". How BTI applies this is covered under claims, the books and carriage.