Add BRC-300: Sponsored Onboarding and Wallet Choice

[vincemedia]

A newcomer arrives with no wallet at all,
And a lone "Sign in" button on the wall.
So we show them a pair,
Bid in cents, fair and square,
And the winner pays them to install.

What this is

apps/0300.md specifies what happens when somebody with no wallet reaches a BRC-100 application and is invited to connect one. Three parts:

1. The connect surface (section 2). The control says connect, never sign in, because for most arrivals the label on the button is the entire explanation of the Metanet they will ever read. Section 2.5 adds a metanet.connect entry to /manifest.json, beside BRC-68's metanet.trust and BRC-116's metanet.groupPermissions, through which a site declares whether an auction runs in front of its users at all.

2. The chooser (section 3). At least two wallets from at least two distinct vendors, on identical cards carrying icon, name, vendor and a short line on what each is good at. Portability is unfalsifiable as a promise and immediate as a list: two companies, either of which opens the same identity. Only order and inclusion are ever for sale.

3. The onboarding auction (sections 4 to 8). Sealed-bid, first-price, resolved in under 250 ms. Vendors bid by committing to fund the newcomer's wallet, and the bid is the bounty: a slot is won on what the person receives and nothing else. What a vendor separately pays the auction house is a distinct number that no ranking may consult.

Three properties worth reviewing

The amount is never transmitted. Offers carry SHA-256(uint64BE(bountySats) || salt) and no amount. A client never given a number cannot rank by it, so the anti-farming property survives a careless implementation and a hostile one alike. Commitments are pre-derived in a batch from the sponsor's own key, sharing an index space with the BRC-227 voucher batch, so commitment i and voucher i are the same slot and the sponsor stores nothing.

Every bid is published; only the winner's is opened. A losing sponsor recomputes its own commitment from its own key and checks two things nobody can lie to it about: was my bid in the set, and did the winner outbid me. Losers' openings stay closed, deliberately, because the full distribution is a market report and that is exactly what a farmer wants.

Targeting is a client-evaluated predicate. A campaign declares its audience; the chooser checks it locally against Bitcoin Attestation Protocol attestations or BRC-52 certificates the person already holds, and discards what does not match. Nothing goes back. The bid request carries no identifier, because at the moment it fires there is not one in existence.

Relationship to existing BRCs

This refines BRC-137 rather than competing with it. Its four buckets, OS detection, catalog contract and connect decision flow apply unchanged and are not restated; this document specifies the Metanet bucket's control, the contents and composition of its no-wallet view, and a fourth ordering mode. Settlement reuses BRC-227's voucher construction unmodified. Nothing is asked of the maintainers: the four type identifiers are derived from printed strings in the manner of BRC-169 section 4.5, so there is nothing to allocate and no registry to add to.

The number

300 is claimed for HTTP 300 Multiple Choices, whose definition is this document's central mechanism almost word for word. Prior Art quotes MDN in full. HTTP reserved a response for the user picks among alternatives and it fell into disuse because nobody standardised how the choosing works; sections 3.3 and 3.4 are that missing part. 402 Payment Required was considered and rejected: BRC-120 and BRC-121 already hold that association here, and 402 means you must pay to proceed, whereas here the vendor pays the user.

Verification

apps/0300-vectors/ holds three scripts. example.py computes every value in Appendix A, verify_vectors.py reads them back out of apps/0300.md and rechecks them, and secp256k1.py self-verifies against the official BRC-42 test vectors. 92 checks, zero failures, no third-party imports, no network. Four are negative vectors: a tampered offer, an altered certificate origin, a flipped retention bit, and a commitment opened one satoshi low.

cd apps/0300-vectors && python3 verify_vectors.py

No BRC has shipped code upstream before, and I am happy to drop these if you would rather the repository stay markdown-only. They are included because the document names them and a reviewer who cannot re-run the vectors is taking the appendix on trust.

Open questions I would value review on

None blocks merging; all are judgement calls where disagreement is the useful signal.

1. The predicate vocabulary is five coarse terms. Every addition is a fingerprinting surface and they combine multiplicatively. Too few, or already too many?
2. retentionBlocks defaults to about a month. Long for a small site's cash flow, short as a test of whether somebody stayed.
3. Pre-funding is mandatory (section 7.1). It deleted a promise-to-pay from the ledger of assertions, and it is also a capital barrier that a two-person wallet team feels hardest.
4. Commitments are consumed per auction entered, not per auction won, because the whole bid set is published. No rule ties batch size to budget.
5. Should maxBidSats carry its own commitment, for symmetry with the bounty?
6. May a site decline a specific campaign? Section 9 leaves it commercial.

Authors

Crumbs, Siggi Oskarsson, Luke Rohenaz. Addresses are omitted to match the prevailing style in this repository; happy to add them if you prefer.

🤖 Generated with Claude Code

[vincemedia]

Superseded by #223.

Building the sponsor console against this revision surfaced six defects, one of which I would not want merged: sections 4.5 and 7.1 derived the commitment salt and the voucher private key from identical inputs, so publishing an opening published the key controlling the bounty. #223 fixes that with a domain-separating tag, plus five smaller gaps, and takes the vectors from 92 checks to 98.

Closing this in favour of #223.