Basket Permission Scheme Registry and Governance

Abstract

We define a governance framework for BRC-99 basket permission schemes. BRC-99 reserves basket identifiers beginning with p for future permission schemes and establishes the format p <scheme-id> <basket-name>, 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> 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'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 and BRC-100 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:

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 provides the extensibility mechanism — the p <scheme-id> <basket-name> format — but deliberately defers the definition of actual schemes to future specifications. BRC-116¹ provides the implementation machinery — permission modules that route p <scheme> 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 basket identifier space is partitioned as follows. This table is a summary of existing rules — this specification does not alter any of these partitions.

This specification governs the permission schemes zone — specifically, the process by which new p <scheme> scheme IDs are registered and classified.

2. Scheme Categories

Permission schemes registered under p <scheme> 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 <scheme-id> <rest>, looks up the scheme ID in its module registry (BRC-116¹ permissionModules), and routes to the module or rejects per BRC-99.

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 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> 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)
• 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 <rest> portion after p <scheme-id>
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¹

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

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¹ originator-based access control, which operates at the permission layer rather than the naming layer.

5. Validation Guidance

Wallets implementing BRC-99 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¹ 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: "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 and BRC-116¹ 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.

Backwards Compatibility

This specification introduces no changes to BRC-100'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 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.

References

• <a name="footnote-1">1</a>: BRC-116: Wallet Permissions and Counterparty Trust
• <a name="footnote-2">2</a>: BRC-99: P Baskets
• <a name="footnote-3">3</a>: BRC-100: Wallet Interface
• <a name="footnote-4">4</a>: BRC-44: Admin-reserved and Prohibited Key Derivation Protocols
• <a name="footnote-5">5</a>: BRC-46: Wallet Transaction Output Tracking (Output Baskets)
• <a name="footnote-6">6</a>: BRC-112: Balance Baskets