Beersy
BRC-123

Basket Permission Scheme Registry and Governance

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.

About Baskets, the wallet's folders for the outputs an app owns.

AlsoPermissionsGovernance

Simon Bettisonchanged 29 Oct 20267 min read

Reference for an AI

Everything an assistant needs to answer questions about BRC-123 accurately, including what it depends on.

Summary

Why
Wallet-related specifications kept claiming basket-naming prefixes independently, with no shared registry, taxonomy, or process to check for collisions or understand a scheme's purpose.
What
BRC-123 is a governance framework that registers, classifies, and documents the "p scheme-id" permission scheme identifiers used in BRC-99 names.
How
A developer defining a new scheme writes a BRC with a "Basket Namespace" section naming the scheme ID, its category, basket name format, required wallet capability, and permission semantics, then adds a row to the registry table once the BRC is merged.

What this lets you do

  • Look up whether a p-scheme ID is already registered
  • Classify a scheme as Asset, Infrastructure, or Reserved
  • Register a new scheme ID by documenting it in a BRC
  • Check the consolidated list of all basket name reservations
  • Route a p-prefixed basket to the correct or reject it

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

p scheme spacecolor1satapp (reserved)::ffff

The specification

Abstract

We define a governance framework for BRC-99 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.

Relationship to descriptive metadata

This scheme-ID registry is distinct from , which publishes optional friendly descriptions of basket identifiers. The BRC-184 explains descriptive metadata and its limited stewardship role. A BasketMap listing does not register a p scheme, install a or override the module-support rules in this specification.

Motivation

As the BSV wallet grows, basket names are being used for increasingly diverse purposes: token tracking, payment receipts, 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:

ReservationReserved byMechanism
defaultBRC-100Wallet rejects at validation
admin *BRC-44Wallet rejects at validation
p <scheme> *BRC-99Wallet rejects unless scheme supported
balance <basket>BRC-112Virtual prefix, reinterprets listOutputs
* basketBRC-100Wallet 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 provides the extensibility mechanism — the p <scheme-id> <basket-name> format — but deliberately defers the definition of actual schemes to future specifications. BRC-116<sup>1</sup> 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.

ZonePatternGoverned byExample
System-reserveddefault, admin *BRC-44, BRC-100admin originator keys
Virtual query prefixbalance *BRC-112balance savings
Permission schemesp <scheme> *BRC-99, this specp token usd
Prohibited suffix* basketBRC-100(rejected)
UnreservedEverything else in [a-z0-9 ]BRC-100game inventory

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<sup>1</sup> 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 of UTXOs can be placed in the basket and what access rules apply. Permissions may be based on , 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-z0-9]+ — lowercase letters and digits only, the BRC-100 basket character set without spaces
  • 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 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<sup>1</sup>

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 IDCategoryDefining BRCPurposeExample basket
color1 — AssetBRC-207Colored Token custody, authorization and per-asset discoveryp color <assetTag>
1sat1 — AssetBRC-165Scoped view and per-action spend for 1Sat collectables in basket 1satp 1sat collection
bntft1 — AssetDraft BRC-255Scoped view of Bitcoin Native Tokens; the wallet alone moves themp bntft token
bntnft1 — AssetDraft BRC-255Scoped view of Bitcoin Native items; the wallet alone moves themp bntnft collection
iptft1 — AssetDraft BRC-253Scoped view of Issuer-Permissioned Tokens; the wallet alone moves themp iptft asset
iptnft1 — AssetDraft BRC-253Scoped view of Issuer-Permissioned items; the wallet alone moves themp iptnft collection
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<sup>1</sup> 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<sup>1</sup> 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<sup>1</sup> 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.

PatternMeaningSource
defaultWallet balance basketBRC-100Historically used for internal operations
admin *Administrative basketsBRC-44, BRC-116<sup>1</sup>Wallet rejects from non-admin originators
balance <basket>Virtual query prefixBRC-112Not a real basket; reinterprets listOutputs
p <scheme> *Permission scheme basketsBRC-99Wallet rejects unless scheme is supported
* basketProhibited suffixBRC-100Redundant naming; always rejected

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

Was this helpful?

Search Beersy

Search standards by number, title, author or topic