Filed elsewhere

A certificate is only useful if an application can ask for one and later prove you hold it. This defines the requests an application makes to a wallet to obtain a certificate and to reveal selected fields from it.

Leads on Certificates·mostly in Peer to peer

Different proof systems will be used to back up key-linkage claims, and hard-coding one of them makes the format a dead end. This defines a container that names which proof type it carries, so new ones can be added later.

Leads on Key linkage·mostly in Key derivation

A wallet can hand out a fresh receive address to anyone, but if that sender is a custodial exchange, swap service, or anyone who just sends money without telling the wallet, there is no way for the wallet to notice the payment arrived. Watching every possible address the wallet could ever generate is slow, leaks privacy, and can still miss late payments. This lets a wallet reliably notice payments to addresses it gave out, without the sender's cooperation and without scanning forever.

Leads on SPV·mostly in Transactions

Apps that want to know who a user is usually force them into yet another signup, hand their identity to a central provider, or trust whatever name a person types into a form. There was no good way for a person to prove a single cryptographic identity across many apps, selectively reveal only the attributes they choose, and let each app apply the trust decisions the user has actually made. This makes it possible for an app to recognize a person by their key, pull up attributes they published, and ask them directly for more proof, all without building an account system or an identity bureau.

Leads on Identity·mostly in Peer to peer

Wallets that handle plain bitcoin payments have no built-in idea of a custom token such as a loyalty point or a share. Without shared rules for finding, verifying, spending and tracking such tokens, every app would reinvent issuance, transfers and swaps from scratch, and wallets could not interoperate on the same asset. This lets a wallet manage fungible tokens with the same safety, automatic input selection, and consent prompts it already gives ordinary payments.

Leads on Token rulebooks·mostly in Tokens

Someone running a wallet app for several separate purposes, a personal account, a shop, a brand, normally ends up juggling a different seed phrase or backup for each one, which is tedious to secure and easy to lose track of. This describes a way for one single backed-up secret to safely produce as many separate, unlinkable accounts as needed, each behaving like its own independent wallet, and for all of them to be found again from that one secret alone.

Leads on Keys from one secret·mostly in Key derivation

Some apps want a wallet to track and move a named digital item, like a ticket or a badge, without the wallet pretending to guarantee how many exist, who issued them, or whether one is the "real" one. Before this, a wallet either had to apply full token rules it didn't need, or drop structure entirely and lose any way to recognize the item at all. This gives apps a lightweight way to say "sign this thing and identify it" without any false promises about scarcity or ownership history.

Leads on Token rulebooks·mostly in Tokens

Wallets that show balances for chains other than BSV, like Litecoin or Dogecoin, usually have to trust a custodian holding wrapped tokens or an indexer reporting balances and confirmations, putting a third party between the user and their money. This makes it possible for a wallet to hold and spend coins on another chain directly, verifying everything itself from raw transaction bytes and its own copy of that chain's block headers.

Leads on SPV·mostly in Transactions

Some multi-party card and shuffle games need each player to secretly scramble and later unscramble shared data using a private number only they know, in a way that works no matter what order players apply or remove their scrambling. Normal wallet features can derive keys or encrypt data, but there was no way to ask a wallet to multiply an arbitrary point someone else gave you by your own secret number without ever learning that number or exposing it to the app.

Leads on Keys from one secret·mostly in Key derivation

A web app can only find the Bitcoin wallet running on a user's own computer by poking a handful of local addresses, and newer browsers treat that poke as suspicious and interrupt the user with a security dialog that never mentions the word "wallet". If the user clicks the wrong button, nothing explains what just happened, and the browser locks out that discovery permanently for that site. This leaves developers needing a way to prepare the user before that dialog appears, so a refusal is recoverable instead of final.

Leads on User experience·mostly in Opinions

When a wallet request fails, today's wallets each write their own error sentence and hand it straight to the app, which has no choice but to show it to the user unchanged. That sentence rarely says whose fault the failure was, whether trying again is safe, or whether the payment might actually have gone through anyway. The result is users double-spending after a timeout, support tickets full of mismatched wording, and apps that cannot translate or shorten a message they did not write.

Leads on User experience·mostly in Opinions

Two parties who each hold part of a transaction history need to reconcile without sending each other everything. This describes a back-and-forth that works out exactly what is missing and fills only the gaps.

Leads on Synchronization·mostly in Overlay services

Handling very high transaction volume means doing as much as possible at the same time, while some checks must still happen in order. This describes how that work is divided across the network so throughput rises without correctness slipping.

Leads on Network architecture·mostly in Opinions

A transaction can be larger than the biggest packet the network will carry. This splits it into numbered pieces the receiver can reassemble, and says how to tell when one is missing.

Leads on Frames and fragmentation·mostly in Peer to peer

A master key is a long string nobody can write down reliably, and losing it loses everything. This adapts the familiar twelve-to-twenty-four word phrase so a single key can be recorded as words and restored from them.

Leads on Backup and recovery·mostly in Wallet

A single key is a single point of failure: lose it and everything is gone, and copying it multiplies the chance of theft. This splits it into pieces where a chosen number of them rebuild it and any fewer reveal nothing.

Leads on Backup and recovery·mostly in Wallet

Wallet users end up locked into one backup method forever. If your wallet was set up with a written-down word phrase, you cannot later split your backup into shares you hand to trusted people, and if it was set up with shares, you cannot get a word phrase out of it. Someone switching wallets or wanting both options at once has been stuck picking one at creation time.

Leads on Backup and recovery·mostly in Wallet

The readable-name payment scheme was built before there was a good way to send verifiable transactions. This updates it to carry the newer self-verifying bundle instead of bare transaction bytes.

Leads on BEEF·mostly in Transactions

Sending someone a bit of digital cash normally means telling them who you are, because the payment format includes your long-term identity key. That's fine for a friend or a business you trust, but it means every coffee tip or casual peer payment lets the recipient permanently tag it to your identity and link it to every other payment you've ever made them. There was no easy way to pay someone spendable coins for a one-off transaction while keeping your long-term identity out of the record.

Leads on Privacy·mostly in Wallet

A wallet that wants to pay someone usually has just a long string of random-looking characters, a public key, with no way to know if it really belongs to the person named by an email-like address such as alice@example.com. Flipping it around is just as broken: a wallet that just received a payment has no name to show for the sender, only that string of characters. There was no safe way to look a name up and get back a key you could trust, or to look up a key and get back a name.

Leads on Identity·mostly in Peer to peer

Attaching data to an output normally makes it unspendable, so the data and the ownership cannot travel together. This describes a script that carries arbitrary data and leaves the output spendable, letting a token hold its own details.

Leads on Token rulebooks·mostly in Tokens

When a token carries compliance rules, two wallets checking it must reach the same answer or transfers will be accepted by one and refused by the other. This pins the check down step by step so the outcome is never in doubt.

Leads on Access gating·mostly in Applications

Fungible tokens on BSV live as special one-satoshi outputs, but nothing told wallets where to keep them, how to tell them apart from ordinary payment coins or collectibles, or what information to pass along when sending them to another wallet. Without agreement, one wallet's token transfer could arrive at another wallet looking like junk, with no amount, symbol, or icon attached, and apps could not reliably list a user's token balances. This standard gives wallets a shared box and labeling convention so tokens move between them cleanly.

Leads on Baskets·mostly in Wallet

Apps that want to show or move collectable items (like NFTs) in a wallet face a bad choice: either dump everything into one basket where any app that gets access sees the user's whole collection, or invent a separate storage bucket for every collection, creator, or app. There was also no clean way to ask a wallet "let me spend this one specific item" without accidentally granting access to spend anything in the collectables basket. This leaves users exposing more than intended, or developers building fragile one-off storage schemes.

Leads on Permissions·mostly in Wallet

When someone sends you a token on Bitcoin, you cannot just trust the number they tell you: you need to check it came from a real issuance and was never double-counted through splits or merges, without running a full blockchain indexer. Existing proof formats either strip out the very transaction history token math depends on, or only work for simple single-path assets, leaving no safe way to check a token tip you just received while offline.

Leads on SPV·mostly in Transactions

Referring to one particular coin is easy; referring to it so another program can act on it is not, because its amount and its lock live elsewhere. This defines the smallest complete way to name an output together with what is needed to use it.

Leads on Transaction formats·mostly in Transactions

An output on its own says nothing about which application it belongs to or what it is for. This adds a way to tag one with the group it belongs to, and with instructions whose meaning that group defines.

Leads on Baskets·mostly in Wallet

Wallet data trapped inside one provider's software is a problem for the user who wants to leave and for anyone who has to answer a data request. This defines a single portable file holding everything about one user's wallet.

Leads on Backup and recovery·mostly in Wallet

A file containing everything about your wallet is not something to leave lying around unprotected. This defines the encrypted wrapper around such an export, so a backup can be stored safely and restored with a password.

Leads on Backup and recovery·mostly in Wallet

Moving a wallet between storage providers, or keeping two of them in step, otherwise needs custom code for every pairing. This defines a resumable synchronisation protocol so independent providers can exchange wallet state directly.

Leads on Synchronization·mostly in Overlay services

Applications constantly need somewhere to keep small pieces of state, and doing that on chain usually means inventing a scheme per project. This standardises a simple named-value store: a public one others can discover, and a private one held in the wallet.

Leads on On-chain state·mostly in State machines

An index that only keeps current data cannot answer questions about how something got to be the way it is. This extends the index to retain the spent history as well, so past states remain queryable.

Leads on Provenance·mostly in Tokens

An index does not have to build its view purely from what is written on chain. This shows how one can track ordinary payments privately, keeping the interesting details off the public record.

Leads on Privacy·mostly in Wallet

Large files are usually treated as one indivisible blob: you can't name it until the whole thing has finished uploading, a single failed byte range means retrying the entire download, and there's no way to prove a partial chunk actually belongs to the file it claims to be part of. This makes streaming uploads, resumable downloads, and safe partial reads of big files awkward or impossible with simple whole-file hashing.

Leads on Merkle proofs·mostly in Transactions

Right now, if an app relies on a single server to hold and deliver messages or lookup results, that one server becomes the weak point: if it goes down, delays, or drops something, there is no backup and no way to reward anyone else for stepping in. This approach lets several independent hosts race to answer the same request, with the fastest honest ones getting paid automatically, so no single operator can quietly become a bottleneck or single point of failure.

Leads on Payment handshakes·mostly in Payments

Different Bitcoin-based apps use the word "overlay" for two very different setups: one where every server is supposed to agree on the exact same data, and one where servers legitimately hold different, non-matching collections. When people conflate these, it becomes unclear whether a mismatch between two servers is a bug to fix or just two valid, different answers.

Leads on Watching the chain·mostly in Opinions

Some data on the blockchain world needs to stay private until someone pays for it, like a song's decryption key, but the usual way overlay servers share and index information assumes everything is public and copied everywhere. Without a clear contract, a seller has no safe way to accept payment, hold a secret key in reserve, and reliably hand it over, especially if a network hiccup happens between "paid" and "delivered". This makes it possible to run a paid catalogue where buyers always eventually get what they paid for, even after crashes or lost responses.

Leads on Access gating·mostly in Applications

Imagine paying for a digital item, like a song, over a payment network: the network can confirm the payment landed, but has no built-in way to also hand over the thing you paid for only once that payment is genuinely and exclusively yours. Without a clear process, a seller could claim a payment is accepted but never deliver, deliver to the wrong person, or leave a buyer stranded if something fails partway through. This gives buyers and sellers a dependable, replayable sequence for locking in terms, submitting payment, and releasing the purchased secret only to its rightful recipient.

Leads on Access gating·mostly in Applications

A token can change hands hundreds of times, and each new holder is expected to check the token's full history back to its creation to be sure it is real. For a long-lived token that check gets slower and more expensive every time it trades, to the point where a wallet on a laptop simply cannot do it fast enough. This makes it possible to hand a newcomer a single small proof instead of the whole history, while still letting them verify it themselves rather than trust whoever gave it to them.

Leads on Token rulebooks·mostly in Tokens

Signing a plain message is not the same problem as signing a transaction, and doing it ad hoc leads to signatures nobody else can check. This defines how messages are signed and verified, including signatures only the intended recipient can confirm.

Leads on Signatures·mostly in Wallet

Sending every transaction separately to every interested party wastes enormous bandwidth when they all want the same data. This proposes delivering it once to everyone who has asked, using the network's own one-to-many delivery.

Leads on Multicast·mostly in Transactions

Two people who want to transact need each other's public key, and sending it over a channel someone could tamper with is a real risk. This uses a short code shared out of band to confirm the key really came from the right person.

Leads on Key linkage·mostly in Key derivation

Anyone could mint a digital asset on Bitcoin and slap a name on it, but a person holding that asset later had no reliable way to know who actually made it or whether a signature claim was real or copy-pasted from somewhere else. Without a fixed, checkable link between an asset and its creator, buyers were trusting unverifiable labels, and marketplaces had no consistent way to show provenance. This makes it possible to prove, cryptographically and tied to the exact transaction, which wallet identity issued a given asset.

Leads on Provenance·mostly in Tokens

Imagine selling a locked box online, but the "lock" is really just a sign that says "please don't look inside" while the contents sit in plain view for anyone who peeks at the underlying data. That's how paid content has actually been built on this chain: the restriction is a polite fiction, not a real barrier. This makes it possible to actually encrypt content once, publish it openly, and hand out the key only to people who paid or otherwise qualify, so access is real, survives the seller going offline, and gets more reliable the more people buy it.

Leads on Access gating·mostly in Applications

A joke standard, kept in the repository as the template contributors copy when writing their own. It exists to show the expected shape of a proposal without anyone having to take its subject seriously.

Leads on Wallet calls·mostly in Wallet

Committing to a piece of content along with what kind of thing it is usually means registering the type somewhere. This derives a single fixed-length commitment from the type and content directly, so no registry is needed.

Leads on Data in script·mostly in Scripts

Apps that show Bitcoin-derived data (like a music catalogue or a task list) often pull information from more than one source: an overlay network, a wallet's own storage, or a direct message from another peer. Without a shared discipline, an app ends up treating whichever source answered first as the single truth, so later corrections, competing hosts, or spends get silently lost or wrongly overwrite each other. This leaves developers unsure how to combine "someone claims this output exists" with "this output is actually verified on-chain" without conflating the two.

Leads on Watching the chain·mostly in Opinions

A digital collectible is normally just a picture plus a boring list of past owners nobody looks at. This standard describes a way for the picture itself to change over time and with use, so that a piece can visibly age, shift with the seasons, or wear a mark its owner chose, all computed fresh by anyone looking rather than fetched from a server.

Leads on Ordinals·mostly in Tokens

Every chat-style client invents its own commands, so what you learn in one is useless in the next. This fixes a common set of verbs that behave the same way everywhere.

Leads on User experience·mostly in Opinions

A visitor with no wallet lands on an app and has nowhere to go: pick the one wallet the app happens to recommend, or leave. Nobody is paying to get that person set up, so sites either force a single choice that quietly favors one vendor or lose the visitor at the install step. This describes how an app can offer a real choice of wallets and let vendors compete to fund the newcomer's first wallet, without the amount being readable or harvestable by bots.

Leads on User experience·mostly in Opinions

Letting a computer program spend Bitcoin on its own usually means handing it a private key, and a key can sign for anything, not just the one task it was meant for. Even a lightly funded key is a full custodian, which is risky when the program is something like an AI agent reading untrusted instructions. This describes a way to let a program trigger on-chain steps and pay their fees automatically, without ever holding a key that could send money elsewhere.

Leads on Agents and automation·mostly in Wallet

A miner interface gained wide adoption and an equal amount of criticism, with some of its uses pulling against how the network is meant to work. This sets out which of those uses are legitimate and which are not.

Leads on SPV·mostly in Transactions

The standard way for a device to say which network broadcasts it wants was designed for a handful of groups, not for blockchain traffic at scale. This examines where it falls short and what would have to change.

Leads on Multicast·mostly in Transactions

A wallet holding ordinary money, collectibles, credentials and regulated assets at once has to treat them very differently, and nothing says how. This works through what a developer should do so the strict cases stay strict.

Leads on Privacy·mostly in Wallet

Right now, proving who you are online usually means handing over a company's whole account system, your transaction history, or a permanent public record just to buy something or prove a right. If your phone breaks or your provider goes bad, you can lose both your money and years of accumulated app data and relationships, with no clear way to get them back or take them elsewhere.

Leads on Identity·mostly in Peer to peer