Banana-Powered Bitcoin Wallet Control Protocol
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.
48 standards
Wallet calls
The calls an application makes to a wallet: create this transaction, sign this, encrypt that, list what I hold. BRC-100 is the current one, and the early single-purpose standards it replaced are still here for context.
Also searched as wallet interface, BRC-100, wallet API, createAction, listOutputs, wallet-to-application.
What Wallet interface means
The vendor-neutral set of calls an application uses to ask a wallet to do things: build transactions, derive keys, encrypt data, sign messages, prove identity. Defined by BRC-100.
Open in the glossaryFiled under
48 standards, spread across 7 of the 12 topics.
Start with
BRC-100
Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
Every wallet historically had its own way of being talked to, so an application had to pick one and be locked to it. This defines a single interface every wallet can implement, so applications work with whichever wallet the user already has.
Filed under Wallet
Standards about this
Wallet calls is the main subject of these 12.
0 1 Transaction Creation
An application that wants to move money has to build a Bitcoin transaction, and building one correctly means handling keys, fees and change. This lets the application describe what it wants to happen and hand the actual work to a wallet, which already knows how to do it safely.
4 Input Redemption
Spending money you already hold means pointing at the specific coins you own and proving you are allowed to spend them. This gives an application a way to name those coins when asking a wallet to build a transaction, along with everything the wallet needs to check the claim before it signs.
5 HTTP Wallet Communications Substrate
A wallet running on your own machine and a website open in your browser have no natural way to talk to each other. This defines one over ordinary web requests, so any application can reach any wallet on the same device without either side having been built for the other.
7 Window Wallet Communication Substrate
Some wallets live inside the browser itself rather than running as a separate program. This gives applications one way to reach those, so a developer writes the same code regardless of where the user's wallet actually runs.
50 Submitting Received Payments to a Wallet
An application that has received a payment on someone's behalf has no standard way to hand it over. This defines how a transaction and its proofs are submitted into a wallet, so the wallet recognises the funds as the user's own.
56 Unified Abstract Wallet-to-Application Messaging Layer
Every application wanting to use a wallet otherwise integrates with each one separately, making every wallet vendor a dependency. This proposes a single interface covering transactions, keys, encryption and identity, so either side can be replaced without rewriting the other.
100 Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
Every wallet historically had its own way of being talked to, so an application had to pick one and be locked to it. This defines a single interface every wallet can implement, so applications work with whichever wallet the user already has.
177 Wallet-Enforced Expiry for `noSend` Actions
If you hand someone a signed Bitcoin payment transaction but ask your wallet not to broadcast it yet, the wallet still locks away the coins it used, sometimes far more value than the payment itself, and there was no reliable way to get that value back if the other party never sends the transaction. An app-side timer does not help because it cannot undo a signature that already left the wallet. This leaves developers stuck choosing between reserving too much money indefinitely or giving up on delayed-send payment flows.
185 Wallet Substrate Discovery, Selection, and Encrypted Mobile Connections
Right now if you run two wallet-enabled apps on the same computer, or try to use your phone's wallet from a desktop browser, things break: one app grabs the only expected port, or whichever wallet loads last wins and silently takes over. There was no agreed way for an app to see what wallets are available, let the user pick one, and keep that choice stable without accidentally scrambling which wallet handles which connection.
205 Extensible Wallet Version Strings and Account Labels
An app that wants to greet a returning user by the name of their wallet account has no way to ask the wallet what that account is currently called, so it either guesses, hardcodes a vendor name, or stays silent. This leaves users confused when the same account shows up under different branding across apps or over time. A small, optional way to carry that label alongside the version string the wallet already returns solves this without adding new wallet methods."
212 Compact Wallet Feature Flags in `getVersion`
A wallet reporting its version to an app used to need one chunky piece of text for every single feature it wanted to advertise, like "offline payments supported" or "color module supported". Stack up a dozen features and the version string blows past old length limits that some apps still enforce, so the wallet either hides capabilities or risks crashing the app. There was no cheap way to say "I support these twelve things" in the same space it used to take to say "I support this one thing".
Standards that touch it
These are about something else, and deal with wallet calls on the way.
3 Digital Signature Creation and Verification
Proving a message really came from you usually means keeping a signing key inside the application, which is both risky and easy to get wrong. This lets an application ask the wallet to sign on the user's behalf, and can produce a signature only the intended recipient is able to check.
6 XDM Wallet Communications Substrate
Two web pages from different sites cannot safely reach into each other, which becomes a problem when one of them is your wallet. This uses the browser's own page-to-page messaging so an application can ask a wallet to act while each side stays sealed off from the other.
37 Basket and Custom Instructions Extension for Bitcoin Outpoints
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.
40 User Wallet Data Synchronization
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.
43 Security Levels, Protocol IDs, Key IDs and Counterparties
Generating unlimited keys is only safe if software can tell what each one is for and how much the user has agreed to. This defines the naming scheme that separates keys by purpose and sets how much permission each use requires.
46 Wallet Transaction Output Tracking (Output Baskets)
An application keeping things on chain has to track which outputs are its own, and leaving that bookkeeping to the application invites mistakes. This lets the wallet group outputs by application and hand them back on request.
53 Certificate Creation and Revelation
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.
65 Transaction Labels and List Actions
A wallet holding hundreds of transactions with no way to tell them apart is hard to make sense of. This lets an application attach its own labels when a transaction is made, and later list transactions by those labels.
66 Output Basket Removal and Certificate Deletion
Anything an application can add to a wallet it should eventually be able to remove, or the wallet fills with things nobody needs. This adds the ability to drop outputs from a group and delete certificates that are no longer wanted.
73 Group Permissions for App Access
An application asking the user for one permission at a time, over and over, teaches them to click yes without reading. This lets an application declare everything it needs up front, in one place, so the user makes one informed decision.
89 Web 3.0 Standard (at a high level)
Talk about a decentralised web rarely says concretely what the pieces are or how they fit. This sketches one: wallets, indexes, browsers and payments, and where each belongs.
110 Zero-Friction, Mobile-First Onboarding for MetaNet-Enabled Apps
Asking someone to create an account and back up a key before they have seen what an application does loses most of them. This starts them with a temporary key straight away and offers a proper one later, once they care.
112 Balance Baskets: Backwards-Compatible Basket Balance Queries
An application that only wants to know how much is in a group has to fetch every item and add them up. This lets it ask for the total directly, using a form older wallets still handle correctly.
114 Time Labels: Backwards-Compatible Action Timestamp Filters for List Actions
Asking a wallet for activity within a date range means fetching everything and filtering it yourself. This adds a way to express the range in the request, without changing what comes back.
137 Device-Aware Wallet Onboarding and Fallback Login for BRC-100 Applications
A new arrival meeting a sign-in screen that assumes they already have a wallet simply leaves. This organises the options so the familiar route is offered first and the wallet route is there for those who have one.
151 BRC-100 Risk Assessment and Best Integration Practices
A single interface every application uses is convenient, and convenience is how ecosystems end up depending on one provider. This names the risks honestly and gives implementers practical ways to avoid them.
152 Best Practices for Regulated Tokens in a BRC-100 Ecosystem
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.
153 Action Reference Labels for BRC-100 Wallets
When an app asks a wallet to build a transaction, the wallet hands back a temporary token needed to finish or cancel that transaction later. If the app crashes, loses memory, or the signing process gets interrupted before that token is used, there was previously no standard way to get it back, leaving the transaction stuck half-finished with no way to complete or cancel it.
155 Pull-Based Receive Discovery
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.
163 BSV-21 Basket Profile for BRC-46 / BRC-100
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.
164 Output Identity Tags for BRC-100 Wallets
Wallet apps often need to find one specific coin they are holding again later, for example after a restart, or to spend exactly that one and not another, but the usual way to look through a wallet's holdings means scanning everything and hoping the details still match. There was no agreed, simple way to give a single held item a durable nickname that a lookup could search for directly.
179 Signed Capability Manifest for Wallet and Tool-Server Method Exposure
A wallet or AI-agent tool server ends up with a long list of callable methods, and once a new method is registered it is simply live, with no signed record of exactly what was turned on and no way for anyone reviewing the build afterward to tell whether the exposed surface quietly grew. This makes it hard to trust that a wallet used by autonomous software, where a rogue or newly-added method could move funds or sign things, has actually been reviewed and locked down rather than just shipped.
181 Wallet-Enforced Autonomous-Agent Spend Policy
An AI agent or automated script that holds a wallet's keys can be tricked or malfunction into sending money to the wrong place, and the usual safeguard, a human approving every transaction, defeats the whole point of letting software act on its own. Before this, a wallet could only grant a monthly spending ceiling to an app, which limits how much but says nothing about to whom, how fast, or under what conditions, so a single bad request could still drain the budget to an attacker.
184 Optional Metadata Registries and Their Stewardship
When an app asks a wallet to approve something, the wallet often shows a cryptic code, a raw protocol string, an unfamiliar basket name, or a block of certificate bytes. Users cannot tell what is actually being requested, and there has been no shared, trustworthy place to look up a human-readable name or description for these identifiers. This makes it possible to publish and consult optional, attributed descriptions, without letting those descriptions ever decide whether the underlying operation is allowed.
206 Wallet-Native Rabin Signatures as a BRC-98 Module
Smart contracts sometimes need to check a signature over arbitrary data, like a price or a game move, but Bitcoin's scripting language can only verify one kind of signature cheaply, and that kind does not work for arbitrary data. Until now, apps that needed this had to generate and hold the special signing key themselves, which meant the user had no way to see, control, or recover it through their wallet. This lets the wallet hold and use that key instead, so the app never has to.
207 1Color Wallet Module
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.
209 1Color Minimal Resource Profile
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.
213 Native UTXO-Chain Coins in a BRC-100 WalletDraft (proposed number, not a BSVA assignment)
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.
214 Wallet Asset ProfilesDraft (proposed number, not a BSVA assignment)
A wallet can hold many different kinds of value, like Bitcoin, other coins, collectable items, and tokens, but there has been no shared rule for keeping them separate when an app asks to see or spend them. Without that, an app given permission to spend a small amount of Bitcoin could end up able to grab an item or token it was never meant to touch, and apps have no clean way to ask a wallet what kinds of value it even holds before trying.
219 Wallet Permission Prompt Liveness Contract
An application asking a wallet for permission gets an error if the person does not answer straight away, which is unfair to anyone who stepped away. This says the request waits for them rather than timing out.
225 Animated-QR Air-Gap Transport for Arbitrary Payloads (TKQR1)
Carrying data to an offline machine as QR codes fails if a single frame is missed and nobody notices. This frames it as plain text lines with checks that confirm the far side really reassembled the whole thing.
229 Wallet-Native Elliptic Curve Point Multiplication as a BRC-98 Module
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.
251 Bitcoin Native Tokens (BNT): Definition and Wallet DutiesOpen
A wallet balance just shows a number. It does not tell you whether the asset behind that number can be frozen, blocked, or reversed by someone other than the person holding it. Developers end up guessing, or reading custom code, to find out whether a token truly belongs to its holder or is secretly on a leash held by its issuer. This gives a clear, checkable way to tell those two kinds of token apart just by looking at the script.
300 Sponsored Onboarding and Wallet Choice
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.
325 User-Initiated Browser Permission Requests for Wallet Discovery
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.
326 Wallet Failure Presentation
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.
Usually read alongside
Concepts that keep appearing on the same standards as this one.
Was this helpful?