> For the complete documentation index, see [llms.txt](https://bsv.brc.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bsv.brc.dev/apps/0227.md). # Frictionless On-Chain Onboarding via Pre-Funded Claimable Tokens sun-dive () ## 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[1](#footnote-1)) 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[1](#footnote-1)) 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))`[2](#footnote-2), 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=` 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 * 1: 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). * 2: Pay to Public Key Hash — BRC-16, (the voucher output and funding-input template). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://bsv.brc.dev/apps/0227.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.