Admin-reserved and Prohibited Key Derivation Protocols
If applications and the wallet itself draw keys from the same pool, an application can trample on the wallet's own records. This sets aside a range of names for the wallet's internal use and puts them beyond application reach.
About Keys from one secret, generating an endless supply of keys from one secret.
Reference for an AI
Everything an assistant needs to answer questions about BRC-44 accurately, including what it depends on.
Summary
- Why
- Wallet software needs internal and payment-related key labels that application code cannot reuse, forge, or exploit to reach protected keys.
- What
- BRC-44 reserves certain BRC-43 protocol ID namespaces, including anything starting with "admin" and the BRC-29 payment protocol ID, so wallets must refuse application requests that touch them.
- How
- A wallet checks the protocol ID on every incoming BRC-43 derivation request and rejects it outright if it starts with "admin", or rejects specific risky operations (signing, encryption, decryption, HMAC, linkage) if it matches the BRC-29 payment protocol ID, while still allowing public derivation and signature…
What this lets you do
- Reserve admin-prefixed protocol IDs for wallet-internal use only
- Block app access to risky operations on the BRC-29 payment namespace
- Keep public derivation and signature verification available to apps
- Prevent root-linkage disclosures that would expose payment keys
- Route non-payment signature needs to a separate domain like BRC-207
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
The specification
Abstract
We define a set of reserved protocol namespaces that can be employed by clients utilizing the BRC-43 invoice numbering scheme to be set aside for administrative and internal use by the client software itself. This enables client software to manage its own internal state without the risk that application software will utilize the same internal protocols.
Motivation
BRC-43<sup>1</sup> defines an open-ended way to create protocols and systems of interaction within a BRC-42<sup>2</sup> key derivation architecture. However, client software implementing the BRC-43<sup>1</sup> invoice numbering scheme needs a way to manage its own internal state, encrypt data and perform administrative tasks like permissions management without interference from applications.
This specification distinguishes fully internal namespaces from payment namespaces with operation-specific restrictions. Public derivation can remain available while private-key operations remain internal.
Specification
The uppercase terms MUST, MUST NOT, SHOULD and MAY indicate normative requirements for implementations adopting this specification.
Fully internal namespaces
Any protocol ID that starts with admin is reserved for administrative and
internal use, regardless of security level. Wallets MUST reject application
requests involving these protocols.
BRC-29 payment namespace
For the exact normalized protocol name 3241645161d8, at every security level,
wallets MUST reject application signing, encryption, decryption, HMAC and
protocol-specific linkage requests. Public derivation and signature verification
remain available under ordinary permissions. Wallets MUST also reject root-linkage
disclosures that expose protected payment keys. Generic grants, privileged access
and auxiliary methods MUST NOT bypass this boundary.
BRC-29 payment derivation is unchanged. Wallet-internal transaction signing and receipt remain available through authorized BRC-100 flows. Applications requiring non-payment data signatures must use a separate domain; BRC-207 defines the 1Color asset module. A policy or basket rename does not change existing on-chain keys.