14 standards
A wallet holding tokens, certificates and ordinary coins needs to know which output belongs to which application and what each one is for. A basket is that grouping, and these standards cover naming them, querying them, and who may touch them.
Also searched as output basket, custom instructions, BasketMap.
A named grouping a wallet uses to track the outputs belonging to one application or purpose. An application can list what is in its basket, and spending an output removes it from the basket.
Open in the glossary14 standards, spread across 5 of the 12 topics.
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.
Filed under Wallet
Baskets is the main subject of these 7.
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.
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.
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.
Granting an application access to a group of assets is currently all or nothing. This reserves naming space for future schemes that can be more precise about what an application may touch.
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.
Reserving a naming space for future permission schemes is only half the job: somebody still has to decide who gets which name. This sets out how a scheme is registered and who maintains the list.
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.
These are about something else, and deal with baskets on the way.
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.
Wallets and applications both need to agree on where collectible items live and how they are described. This reserves the group name and pins down what may go in it and how it is labelled.
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.
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.
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.
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.
A wallet does not pick its own order for the spendable outputs it knows about; some outside source hands them over in whatever order that source chooses. If a privacy-focused wallet's logic for choosing which outputs to spend secretly depends on that order, the source can quietly steer which of the holder's keys get linked together in a payment, and rebuilding the "same" payment later can spend a different set of outputs than before, exposing both attempts to an observer.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic