Frictionless On-Chain Onboarding via Pre-Funded Claimable Tokens

Abstract

This BRC specifies a protocol for onboarding a person who has no wallet and no coins directly into ownership of a real on-chain asset — by clicking a link. A publisher pre-funds a batch of voucher outputs; each voucher becomes a claim link. A recipient claims by having the voucher fund an on-chain acquisition (e.g. a covenant-token mint under BRC-146¹) while a key they generate in the moment owns the result — payer and owner are decoupled. The voucher keys are deterministically derived from the publisher's private key, so every issued link and every unclaimed voucher is recoverable from the publisher's key alone, with no separate backup. The blockchain "cold-start" problem — you already need a wallet and coins to receive your first asset — dissolves: the gifter pays; the recipient just claims.

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

Motivation

The single largest barrier to blockchain adoption is the cold start. To receive your first on-chain asset today you must already have a wallet, already hold coins for the fee, and know enough not to lose either. Every one of those prerequisites sheds prospective users before they ever hold anything. "Airdrop" and claim-link schemes rarely fix it — they deliver a fungible balance the recipient still cannot move without gas, or they assume the recipient can already transact.

This protocol removes all of the prerequisites at once:

1. The gifter pre-funds the entire claim — network fee, any bond, and any enforced covenant royalties — so the recipient spends nothing.
2. The recipient receives a real, owned, provenanced asset, controlled by a key they generate at claim time — not a custodial IOU or a balance they must later fund to use.
3. No prior wallet, no prior coins, no purchase — just a link. A newcomer goes from nothing to owning an on-chain asset in a few clicks.

Critically, this uses no new cryptographic primitive. It is a recombination of standard ones — a P2PKH-funded output, a covenant-token acquisition, and a decoupling of the transaction's payer from its owner. Its power lives entirely in the composition, which is exactly why it is easy to overlook — an open secret. This BRC states it plainly so any wallet can implement it and so the pattern can be recognized for what it is: a general-purpose, trustless onboarding primitive. Deterministic voucher keys make it operationally safe at scale — a publisher can issue thousands of links and recover every unclaimed one (and its funds) from a single key.

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

Specification

1. Roles and objects

• Publisher — the issuer/gifter, holding a private key and some coins.
• Recipient — the claimer, who MAY have no wallet and no coins.
• Voucher — a funded on-chain output plus the private key that controls it.
• Asset — the thing claimed: a covenant token (BRC-146¹) or any acquirable on-chain output whose acquisition transaction can be funded by an arbitrary input.

2. Deterministic voucher keys

Voucher keys are derived so that only the publisher can regenerate the batch:

voucherKey_i = SHA-256( publisherPrivKey (32 bytes, big-endian)
                        ‖ collectionRef  (32-byte reference to the asset/collection)
                        ‖ index_i        (4 bytes, little-endian) )

Because the derivation consumes the publisher's private key, no one else can reproduce the voucher keys — so every issued link and every unclaimed voucher is recoverable from (publisherPrivKey, collectionRef) plus the chain, with no separate backup. The one-way hash never reveals the publisher's key, and the resulting voucher WIF is intended to be shared in the link.

3. Issuing vouchers

The publisher creates N voucher outputs in one transaction: for i in [start, start+N), an output of fundEachSats locked to P2PKH(address(voucherKey_i))², plus change back to the publisher. fundEachSats MUST cover a single claim's network fee plus the asset's bond (if any) plus any enforced covenant fees (BRC-146 §6). Each voucherKey_i WIF becomes a claim link.

4. The claim — decoupled payer and owner

The recipient's wallet, given a voucher WIF (from the link):

1. Generates a fresh recipient key — the future owner.
2. Builds the acquisition transaction (e.g. the covenant's permissionless replicate branch, BRC-146 §6) in which:
   • the voucher UTXO funds the spend — the voucher key signs the funding input, paying the fee, bond, and any covenant royalties;
   • the asset is owned by the recipient's fresh key — payer ≠ owner;
   • change returns to the recipient.

The recipient therefore needs no prior coins and no prior wallet: the voucher pays, and a key created in the moment owns the result. This payer/owner decoupling is the crux — it is what lets a funded voucher deliver ownership to a brand-new key.

5. Recovery and reclaim

From the publisher's key alone, regenerate voucherKey_i for ascending i and gap-scan the chain:

• funded and unspent → a live, unclaimed link (rebuild it from the WIF);
• funded and spent → already claimed;
• never funded → the end of the batch (nextIndex).

Unclaimed voucher outputs are ordinary UTXOs the publisher MAY reclaim at any time. No local database is required — the batch is fully reconstructable from (publisherPrivKey, collectionRef) + chain.

6. Link payload (informal)

A claim link MUST carry the voucher WIF and enough context to identify the asset/collection (e.g. its collectionRef). Implementations MAY choose any link scheme (e.g. a g=<wif> query parameter). The WIF is a bearer credential: whoever redeems it first claims the asset.

7. Security considerations

• Bearer semantics. Anyone who obtains a live voucher WIF can claim it; deliver links over channels appropriate to their value.
• Bounded exposure. A voucher SHOULD hold only the amount needed for its intended claim, so a leaked link risks only that amount — which the publisher can also reclaim while unspent.
• No key leakage. The publisher's private key is never derivable from a voucher key or WIF (one-way hash).
• Ownership integrity. Because payer and owner are decoupled, the claimed asset is owned by the recipient's key, never by the voucher key; the voucher is spent purely as funding.

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 implements this end-to-end: createGiftVouchers (batch-funds deterministic vouchers in one tx), deriveVoucherKey (the derivation of §2), and scanGiftVouchers (the recover/reclaim of §5); recipients claim covenant editions (BRC-146) with no prior wallet or coins, each claim funded by its voucher while a freshly-generated recipient key takes ownership. Repository: https://github.com/sun-dive/PharLap (src/editionBuilder.ts).

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>: Miner-Enforced Resale-Royalty Covenant Tokens (OP_PUSH_TX) — BRC-146 (the covenant-token asset a voucher claims; its permissionless replicate branch is the acquisition transaction funded by the voucher).
• <a name="footnote-2">2</a>: Pay to Public Key Hash — BRC-16, https://github.com/bitcoin-sv/BRCs (the voucher output and funding-input template).