# Basket Permission Scheme Registry and Governance Simon Bettison () ## Abstract We define a governance framework for [BRC-99](/wallet/0099.md) basket permission schemes. [BRC-99](/wallet/0099.md) reserves basket identifiers beginning with `p` for future permission schemes and establishes the format `p `, but defines no process for registering scheme IDs, no taxonomy for classifying schemes, and no consolidated reference for the basket name reservations scattered across multiple wallet BRCs. This specification addresses those gaps. It provides: 1. A **registry** of registered and reserved `p ` scheme IDs 2. A **taxonomy** that classifies schemes by purpose 3. A **registration process** for claiming new scheme IDs via BRC specifications 4. A **consolidated reference** of all basket name reservations across the wallet BRC family No changes to [BRC-100](/wallet/0100.md)'s basket naming rules or character validation are required. This specification operates entirely within the existing `[a-z0-9 ]` character set and builds on the `p` reservation that [BRC-99](/wallet/0099.md) and [BRC-100](/wallet/0100.md) already enforce. ## Motivation As the BSV wallet ecosystem grows, basket names are being used for increasingly diverse purposes: token tracking, payment receipts, UTXO management, permission tokens, and module-defined digital asset schemes. Each new protocol that uses baskets must choose a naming convention, and without a framework, the risk of collision increases with every new standard. The current state is fragmented: | Reservation | Reserved by | Mechanism | | ------------------ | --------------------------------- | ------------------------------------------ | | `default` | [BRC-100](/wallet/0100.md) | Wallet rejects at validation | | `admin *` | [BRC-44](/key-derivation/0044.md) | Wallet rejects at validation | | `p *` | [BRC-99](/wallet/0099.md) | Wallet rejects unless scheme supported | | `balance ` | [BRC-112](/wallet/0112.md) | Virtual prefix, reinterprets `listOutputs` | | `* basket` | [BRC-100](/wallet/0100.md) | Wallet rejects (redundant suffix) | Each BRC independently grabs a prefix with no coordination, no registry, and no way to answer "is this scheme ID taken?" without reading every wallet-related BRC. [BRC-99](/wallet/0099.md) provides the extensibility mechanism — the `p ` format — but deliberately defers the definition of actual schemes to future specifications. [BRC-116](/wallet/0116.md)1 provides the implementation machinery — permission modules that route `p ` baskets to scheme-specific handlers. What is missing is the governance layer: a registry of scheme IDs, a process for claiming them, and a taxonomy that helps wallet implementers understand the landscape. ## Specification ### 1. Basket Name Space Overview The [BRC-100](/wallet/0100.md) basket identifier space is partitioned as follows. This table is a summary of existing rules — this specification does not alter any of these partitions. | Zone | Pattern | Governed by | Example | | -------------------- | ------------------------------ | ------------------------------------------------------------- | ----------------------- | | System-reserved | `default`, `admin *` | [BRC-44](/key-derivation/0044.md), [BRC-100](/wallet/0100.md) | `admin originator keys` | | Virtual query prefix | `balance *` | [BRC-112](/wallet/0112.md) | `balance savings` | | Permission schemes | `p *` | [BRC-99](/wallet/0099.md), **this spec** | `p token usd` | | Prohibited suffix | `* basket` | [BRC-100](/wallet/0100.md) | *(rejected)* | | Unreserved | Everything else in `[a-z0-9 ]` | [BRC-100](/wallet/0100.md) | `game inventory` | This specification governs the **permission schemes** zone — specifically, the process by which new `p ` scheme IDs are registered and classified. ### 2. Scheme Categories Permission schemes registered under `p ` are classified into categories based on their purpose. The taxonomy is informational — a scheme's category does not change its validation or routing behaviour. The normative behaviour is always: the wallet encounters `p `, looks up the scheme ID in its module registry ([BRC-116](/wallet/0116.md)1 `permissionModules`), and routes to the module or rejects per [BRC-99](/wallet/0099.md). #### Category 1: Asset Permission Schemes Schemes that define permission rules for specific types of digital assets. The scheme governs what kinds of UTXOs can be placed in the basket and what access rules apply. Permissions may be based on locking scripts, script templates, tokenisation protocols, or value constraints. This is the category [BRC-99](/wallet/0099.md) originally envisioned — for example, a scheme that allows access to a maximum of 10 dollars of tokenised fiat money per month within an application. #### Category 2: Infrastructure Schemes Schemes that provide wallet infrastructure capabilities. The basket requires specific wallet functionality to manage — the scheme exists not to restrict asset types but to ensure the wallet has the operational capability the basket demands. For example, a scheme for managed UTXO provisioning would require the wallet to have specific output management capabilities before it can accept operations on baskets in that scheme. #### Category 3: Reserved Scheme IDs reserved for anticipated future use. A reserved scheme ID has no defining BRC and no active semantics — it serves as a placeholder to prevent the ID from being claimed for an incompatible purpose. Reserved IDs MAY be promoted to Category 1 or 2 when a defining BRC is written. ### 3. Scheme Registration Process A new `p ` scheme ID is registered by defining it in a BRC specification and adding it to the registry in Section 4. #### 3.1 Scheme ID Rules The scheme ID (the first space-delimited token after `p` ) MUST satisfy: * Matches `[a-z][a-z0-9]*` — starts with a lowercase letter, followed by zero or more lowercase letters or digits * Minimum 2 characters (single-letter IDs are reserved for future core use) * Maximum 30 characters * Contains no spaces (per [BRC-99](/wallet/0099.md)) * Is unique — does not conflict with any registered or reserved scheme ID in the registry #### 3.2 Required Documentation The defining BRC MUST include a section titled "Basket Namespace" (or equivalent) that specifies: 1. **Scheme ID** — the claimed identifier 2. **Category** — per Section 2 3. **Basket name format** — the expected structure of the `` portion after `p ` 4. **Wallet capability** — what functionality the wallet must provide to handle baskets in this scheme 5. **Permission semantics** — how access is controlled, or a statement that permission enforcement is deferred to the module's implementation per [BRC-116](/wallet/0116.md)1 #### 3.3 Registration A scheme ID is considered registered when its defining BRC is merged into the BRC repository. This specification's registry table (Section 4) SHOULD be updated in the same pull request. ### 4. Scheme Registry | Scheme ID | Category | Defining BRC | Purpose | Example basket | | --------- | ------------ | -------------- | ----------------------------------- | -------------- | | `app` | *(Reserved)* | *(Future BRC)* | Application-scoped basket isolation | *(TBD)* | The `app` scheme ID is reserved to allow a future specification to define application-scoped baskets where the originator's identity is encoded in the basket name. This supplements (rather than replaces) [BRC-116](/wallet/0116.md)1 originator-based access control, which operates at the permission layer rather than the naming layer. ### 5. Validation Guidance Wallets implementing [BRC-99](/wallet/0099.md) permission schemes SHOULD apply the following logic when encountering a basket name beginning with `p` : 1. Extract the scheme ID — the first space-delimited token after `p` 2. Look up the scheme ID in the wallet's registered permission modules ([BRC-116](/wallet/0116.md)1 `permissionModules` configuration) 3. If a module is registered for the scheme ID, route the operation to the module 4. If no module is registered, reject the operation — per [BRC-99](/wallet/0099.md): "wallets must reject any operation requests made under basket IDs beginning with `p` " unless they explicitly support the scheme This is a restatement of existing [BRC-99](/wallet/0099.md) and [BRC-116](/wallet/0116.md)1 behaviour, consolidated here for clarity. ### 6. Consolidated Reservation Reference The following table lists all basket name reservations across the wallet BRC family, presented as a single point of reference. Each reservation is normatively defined by its source BRC — this table is informational. | Pattern | Meaning | Source | Notes | | ------------------ | ------------------------- | ------------------------------------------------------------------------- | --------------------------------------------- | | `default` | Wallet balance basket | [BRC-100](/wallet/0100.md) | Historically used for internal operations | | `admin *` | Administrative baskets | [BRC-44](/key-derivation/0044.md), [BRC-116](/wallet/0116.md)1 | Wallet rejects from non-admin originators | | `balance ` | Virtual query prefix | [BRC-112](/wallet/0112.md) | Not a real basket; reinterprets `listOutputs` | | `p *` | Permission scheme baskets | [BRC-99](/wallet/0099.md) | Wallet rejects unless scheme is supported | | `* basket` | Prohibited suffix | [BRC-100](/wallet/0100.md) | Redundant naming; always rejected | ## Backwards Compatibility This specification introduces no changes to [BRC-100](/wallet/0100.md)'s basket naming rules. The character set remains `[a-z0-9 ]`. No existing basket name, validation rule, or wallet behaviour is affected. The `p` reservation has been enforced by [BRC-100](/wallet/0100.md) since its introduction — wallets already reject `p` -prefixed baskets unless they support the scheme. This specification provides governance for which scheme IDs exist; it does not alter the mechanism by which they are enforced. Wallets that do not implement any permission scheme modules will continue to reject all `p` baskets, which is the correct and safe behaviour defined by [BRC-99](/wallet/0099.md). ## References * 1: [BRC-116: Wallet Permissions and Counterparty Trust](/wallet/0116.md) * 2: [BRC-99: P Baskets](/wallet/0099.md) * 3: [BRC-100: Wallet Interface](/wallet/0100.md) * 4: [BRC-44: Admin-reserved and Prohibited Key Derivation Protocols](/key-derivation/0044.md) * 5: [BRC-46: Wallet Transaction Output Tracking (Output Baskets)](/wallet/0046.md) * 6: [BRC-112: Balance Baskets](/wallet/0112.md) --- # Agent Instructions: 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: ``` GET https://bsv.brc.dev/wallet/0123.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.