Miner-Enforced Resale-Royalty Covenant Tokens (OP_PUSH_TX)

Abstract

This BRC specifies a class of self-replicating covenant tokens whose spending rules are enforced by miners at consensus, not by any platform. Using OP_PUSH_TX transaction introspection, each token's locking script forces the transaction that spends it to (a) re-create the token for its new holder and (b) pay fixed royalty/creator outputs to immutable addresses. A resale that omits, reorders, underpays, or redirects any required payout is simply an invalid transaction — so the resale terms are unstrippable and travel with the coin.

One mechanism carries two profiles:

• Single-payee — every transfer or permissionless purchase pays a fixed publisher fee and holder fee. Deployed and mainnet-validated.
• Multi-payee — every resale pays N fixed creator payouts, each bound to an immutable address (e.g. an on-chain split sheet, or paying the original creators of referenced/bundled components). Validated against the reference Script interpreter; ready for deployment.

Tokens are self-verifying: identity binds to a genesis transaction and is confirmed by a single Merkle proof, with no lineage walk — the same principle as the Merkle Proof Token protocol¹.

The Abstract section should concisely describe your proposal at a high-level.

Motivation

On-chain assets can express resale royalties and creator splits, but as a convention those payments are strippable — a reseller can simply omit them — and enforcing them at a marketplace requires trust and is bypassed by trading elsewhere. BSV Script's transaction-introspection capability lets a token enforce its own resale terms at consensus: any spend that fails to carry the required outputs is rejected by miners. This yields:

1. Unstrippable resale royalties. The creator payout is a validity condition of the spend, not a courtesy.
2. Multi-party splits and reuse royalties. A single covenant can force N payouts — a music split sheet (songwriter / producer / label), or paying the original creators of the components a composition reuses⁴ — each bound to an immutable address.
3. Platform independence. No marketplace, escrow, or trusted intermediary; the rules are in the coin.
4. A recognized transaction class. A documented, uniform format so any wallet can recognize, validate, transfer, and display these tokens interoperably — rather than every implementation being bespoke. Standardizing the format is the purpose of this BRC: one implementation already produces and validates these tokens on mainnet; this lets others support the same class.

The Motivation section should let people know the context for your proposal, and why it was written.

Specification

1. Overview

A covenant token is a Bitcoin output whose locking script, on every spend, verifies the spending transaction against itself (OP_PUSH_TX) and forces a specific ordered output layout: output 0 re-creates the token (re-locked to the new holder), followed by one or more fixed payout outputs, followed by spender-controlled change. The immutable terms (payout addresses and amounts) are committed at mint and propagate unchanged forever.

2. Transaction introspection (OP_PUSH_TX)

BSV has no native "push the sighash" opcode, so a locking script inspects its spending transaction using the Push TX construction (BRC-21⁵):

1. The unlocking script pushes the BIP-143/FORKID sighash preimage of the spending input.
2. The locking script computes e = HASH256(preimage) and, using a fixed, PUBLIC keypair (a, k), derives a valid ECDSA signature s = k⁻¹·(e + r·a) mod n (with r = (k·G).x mod n), assembles it as minimal DER, and verifies it with OP_CHECKSIG against Q = a·G.

Because OP_CHECKSIG independently recomputes the sighash from the actual transaction, the spend validates only when HASH256(pushed preimage) == actual sighash — i.e. the spender is forced to reveal the genuine preimage. (a, k) are public constants and protect nothing; the covenant's security rests entirely on this binding, not on key secrecy. Having proven the preimage genuine, the covenant OP_SPLITs it to read fields such as hashOutputs and enforces rules on the spending transaction.

Requirements: transaction version MUST be > 1 (so low-S is not enforced and big-integer arithmetic is available); DER minimality of s is obtained by OP_NUM2BIN to a fixed width followed by fixed-length reversal. Implementations MUST use a consistent sighash scope so that hashOutputs commits to the full ordered output list.

3. Token model

Tokens are carried in PushDrop outputs (Pay to Push Drop, BRC-48⁶): a sequence of pushed data fields followed by a <lockKey> OP_CHECKSIG-style authentication of the current holder. A record-type byte distinguishes token kinds; this BRC concerns the covenant token record, whose immutable field prefix is:

[ P (protocol byte), version, recordType, genesisRef (32-byte txid), ownerPubKey (33 bytes), <profile fields…> ]

• genesisRef — the txid of the genesis transaction that minted the covenant and committed its immutable terms (payout address(es) and amounts). It is the token's identity and is identical across every replicated copy.
• ownerPubKey — the current holder's public key; this is the only field that changes across a transfer.
• Immutable terms are committed by the genesis transaction and/or baked as constants in the covenant script.

4. Self-replicating covenant (the quine)

On any spend the covenant reconstructs its own locking script for output 0 directly from the preimage's scriptCode — it never embeds a second copy of itself. It extracts the scriptCode field, splits it at the ownerPubKey offset into (prefix ‖ ownerPubKey ‖ suffix), substitutes the new holder's key, and requires output 0 to equal value ‖ prefix ‖ newOwnerPubKey ‖ suffix. Because prefix/suffix are reproduced verbatim, the immutable terms propagate unchanged; only the holder changes.

5. Enforced outputs

The covenant assembles the expected output serialization out0 ‖ <fixed payout outputs> ‖ <spender change> and asserts HASH256(expected) == hashOutputs. Each payout output is a fixed-value P2PKH to an immutable address. Any spend that omits, reorders, alters an amount, or redirects a payout produces a different hashOutputs and fails. Outputs after the forced set are spender-controlled (change, buyer funding return, etc.). Because enforcement is on outputs only, additional inputs MAY be added by a buyer to fund the spend.

6. Profile A — single-payee (deployed)

The genesis transaction commits a covenant template (publisher address + fee schedule) and, optionally, content. Covenant tokens are three-way spendable via an unlock selector:

• Transfer (holder-authorized): out0 = token re-locked to newOwnerPubKey; the current holder MUST sign (OP_CHECKSIGVERIFY against the extracted ownerPubKey).
• Purchase / replicate (permissionless): out0 = token returned to the holder (verbatim), out1 = replica to the buyer (owner = buyer), out2 = publisher fee (fixed sats → the immutable publisher address), out3 = holder fee (fixed sats → HASH160(ownerPubKey)), out4+ = buyer change. No holder signature is required — anyone may buy, but the two fees are compulsory.
• Burn (holder-authorized): reclaim the token's refundable bond.

Result: every sale pays the publisher (creator royalty) and the current holder, enforced by consensus. Status: deployed on BSV mainnet.

7. Profile B — multi-payee (ready)

Identical mechanism; the forced-output tail generalizes from one publisher fee to N fixed payouts:

out0        = token re-locked to newOwnerPubKey        (self-replica)
out1 … outN = feeSats_i → P2PKH(creatorAddr_i)         (N fixed, genesis-bound payouts)
out(N+1)…   = spender change

The current holder signs to sell. The N payees SHOULD be genesis-bound: each creatorAddr_i is the immutable publisher address of a referenced component's own genesis mint, so a verifier can confirm the covenant pays the real creators (fetch each component's genesis, compare) and the minter cannot substitute addresses. Percentages are a UI concern — an interface displays "50 / 30 / 20" and computes the fixed sat amounts at the chosen price; the covenant only ever enforces fixed amounts. Uses: enforced reuse royalties (a composition pays each referenced component's creator on resale) and multi-party splits (a single work's collaborators). Status: validated against the reference @bsv/sdk Script interpreter (transaction version 2); not yet deployed.

8. Self-verification (no lineage walk)

A token is genuine if and only if its covenant's immutable portion matches the terms committed by its genesis transaction (genesisRef), confirmed by a single Merkle proof (BUMP²) of that genesis transaction to a block header. There is no need to trace the token's transfer history: identity binds to genesis, and the covenant guarantees the terms propagated unchanged. This is the "genuine-penny" / MPT principle¹ — bind to genesis, don't trace every hop — and it makes verification O(1) in the number of transfers. No ancestor/lineage chain (e.g. BRC-62 BEEF³) is required.

9. Conformant wallet requirements

A wallet claiming support for this class:

1. MUST construct spends that satisfy the active profile's forced output layout (OP_PUSH_TX preimage in the unlock; correct out0 self-replica; all payout outputs present, exact, and in order).
2. MUST validate a received token by matching its covenant against genesisRef's committed terms plus a single Merkle proof to a header (Section 8).
3. SHOULD recognize the record-type byte and display the enforced payouts (creator royalties / splits) to the user.
4. MAY add buyer funding inputs when purchasing (Section 5).

The Specification section of your proposal should stipulate all information needed to implement the standard, and make up the bulk of the document. Generally, people should be able to create a compatible implementation with only the specification.

Implementations

1. Phar Lap — an open-source (Open BSV License) smart-NFT wallet that mints, transfers, purchases (permissionless), burns, and validates the single-payee covenant on BSV mainnet, and ships the multi-payee covenant (interpreter-proven). Repository: https://github.com/sun-dive/PharLap. Covenant sources: src/pushtx.ts (OP_PUSH_TX primitive), src/covenant.ts (single-payee edition covenant + quine), src/bundleCovenant.ts (multi-payee covenant).
2. Reference validation — both profiles are validated end-to-end against the @bsv/sdk Spend interpreter with transactionVersion = 2, including negative tests that reject a spend which skips, underpays, or redirects any payout.

The Implementations section should contain information about places where the standard is implemented, or examples of its implementation.

References

• <a name="footnote-1">1</a>: Merkle Proof Token (MPT) protocol — BRC-113, https://github.com/bitcoin-sv/BRCs (identity binds to genesis; self-verification without a lineage walk).
• <a name="footnote-2">2</a>: BSV Unified Merkle Path (BUMP) — BRC-74, https://github.com/bitcoin-sv/BRCs (single-proof SPV to a block header).
• <a name="footnote-3">3</a>: BEEF — BRC-62, https://github.com/bitcoin-sv/BRCs (ancestor-carrying format; explicitly NOT required by this class).
• <a name="footnote-4">4</a>: Block Media Format (BMF) — BRC-145 (composable on-chain audio/video; the multi-payee profile enforces payment to the creators of the components a BMF composition reuses).
• <a name="footnote-5">5</a>: Push TX — BRC-21, https://github.com/bitcoin-sv/BRCs (transaction introspection by pushing and verifying the sighash preimage).
• <a name="footnote-6">6</a>: Pay to Push Drop — BRC-48, https://github.com/bitcoin-sv/BRCs (data fields pushed then dropped ahead of a spendable locking script).