Wallets & Identity
As BRC-100 wallets gain richer permissions, applications can ask users to approve increasingly specific operations.
The technical identifiers behind those requests are useful to software, but they are not always useful to people. A wallet might need to show a protocol identifier, an output basket or a certificate type while asking a user for permission. To the application and wallet, those identifiers can be precise and meaningful. To an ordinary user, they may appear as little more than unfamiliar strings, numbers or codes.
BRC-184 — Optional Metadata Registries and Their Stewardship, proposed by Ty Everett on September 25, addresses that interface problem.
It defines three optional metadata registries—ProtoMap, BasketMap and CertMap—that can associate technical wallet identifiers with readable names, descriptions, documentation and images.
The more important part of the proposal, however, is the boundary it places around those registries: they are intended to explain, not to decide.
A wallet must not turn absence from a metadata registry into a reason to block an otherwise supported protocol, and the presence of a friendly description must not become permission to spend, proof that a certificate issuer is trustworthy or authorization to use an application. Beersy
When a Permission Prompt Needs Translation
BRC-100 defines a broad wallet-to-application interface covering transactions, cryptographic operations, certificates and other application requests. The interface is designed so applications can ask a wallet to perform functions while the wallet remains responsible for mediating user permissions. GitHub
That creates a user-interface problem as the number of supported capabilities grows.
An application may request access to a particular protocol, ask to work with an output basket or request disclosure of a particular certificate type. The wallet can know exactly which identifier the application requested and still have difficulty explaining that request to the person looking at the permission window.
BRC-184 gives wallets a standardized place to look for the explanatory layer.
The three proposed registries serve different kinds of identifiers:
- ProtoMap describes wallet protocol identifiers.
- BasketMap describes output-basket identifiers.
- CertMap describes certificate types and, where appropriate, their fields.
A metadata record can provide a readable name, description, icon and documentation while preserving the underlying technical identifier that the wallet is actually being asked to use. Open Standards
The Raw Identifier Still Matters
BRC-184 does not propose replacing technical identifiers with friendly names. It proposes showing the friendly information alongside them.
That distinction matters because the readable description is not the protocol itself.
A protocol might be represented internally by a BRC-43 security level and protocol string. A basket has its own identifier, while a certificate type has its own identifying bytes. Those values remain the actual objects being requested; the metadata merely helps explain them.
BRC-184 therefore requires wallets adopting the proposal to retain a usable fallback when metadata cannot be found.
If the registry is unavailable, if no description exists, or if a wallet chooses not to use a particular publisher, the wallet should still be able to display the raw identifier and continue through its normal authorization process. The user should not suddenly lose access to the underlying protocol because its description service disappeared.
Metadata Is Not Permission
This is the proposal’s most important design choice.
BRC-184 explicitly separates information from authority.
A registry entry cannot grant permission for an application to spend, enlarge an existing permission, decide which counterparty a wallet should trust or establish that a certificate issuer is legitimate. Likewise, the absence of an entry cannot be used as a reason to block a protocol that the wallet otherwise supports. Open Standards
That prevents a useful directory from quietly becoming an application gatekeeper.
Consider the opposite design. If a wallet only allowed protocols appearing in one approved metadata registry, whoever controlled that registry would effectively gain power over which applications could communicate with the wallet. A descriptive service would have become an authorization layer.
BRC-184 rejects that model.
Wallet implementations may choose default metadata publishers, while users or wallet developers may choose different ones. Sources can be replaced or disabled without disabling the underlying protocol.
Who Publishes the Description?
The proposal also distinguishes the organization serving metadata from the organization that authored it.
Registry records are signed by their publisher, and an overlay host can then index and serve those records. The party hosting the lookup infrastructure does not automatically become the author of the description, and trusting a host to make data available is not the same thing as accepting the publisher’s description as accurate.
BRC-184 also allows different publishers to describe the same identifier. Those descriptions remain separately attributable statements rather than being combined into one supposedly authoritative definition. Open Standards
That makes source selection a wallet-level decision.
One wallet could ship with a particular metadata publisher as its default, another could use a different publisher, a community could maintain its own, and a user could disable one. None of those choices should disable the actual protocol.
Existing Infrastructure, New Stewardship Rules
BRC-184 is not starting entirely from zero.
The specification describes existing RegistryClient tooling and ProtoMap, BasketMap and CertMap overlay conventions.
Current implementations can publish signed metadata records through one-satoshi PushDrop outputs, with overlay topics indexing those records for lookup. Updating a definition spends the previous output and replaces it with another, while removing a definition spends it without publishing a replacement. Open Standards
But BRC-184 is not primarily a new wire-format specification. Its larger purpose is to define how this metadata should be treated.
A signed description is still only a description. A registry operator should not be able to convert its position into control over wallet permissions, a metadata publisher should not condition inclusion on using its commercial services or endorsing its views, and wallets should distinguish metadata availability from the validity of the underlying protocol request.
The proposal is therefore partly technical and partly about stewardship.
A Registry Without an App Store
BRC-184 is unusually explicit about what it does not create.
It does not create a global namespace authority, application store, certificate-issuer accreditation system or reputation service. It also does not give registry operators a mechanism to remotely disable applications. Open Standards
That limitation is important because metadata systems can accumulate power indirectly.
Once users begin relying on recognizable names, logos and descriptions, an informational directory can become a practical approval list even if that was not its original purpose.
BRC-184 attempts to address that risk in advance. A wallet can use metadata to make a prompt easier to understand while still making the actual permission decision according to the wallet’s own rules and the user’s choice.
Why This Matters for BRC-100 Wallets
BRC-100 is increasingly less like the interface of a simple send-and-receive wallet.
It provides applications with standardized access to wallet functions including transaction creation, signing, encryption, key derivation and identity certificates. GitHub
As those capabilities expand, the permission interface becomes part of the security architecture.
A technically correct request is not necessarily an understandable request, and consent is weaker if a user is being asked to approve something that cannot be meaningfully interpreted.
BRC-73 already addresses part of this problem by allowing applications to group expected wallet permissions into a coherent declaration rather than presenting a series of disconnected prompts. GitHub
BRC-184 approaches the next layer.
Even when permissions are grouped correctly, the identifiers inside those permissions still need to mean something to the person making the decision. Readable metadata can help close that gap.
The Important Boundary
There is a subtle balance here.
Without shared descriptions, every wallet may have to build its own glossary of protocols, baskets and certificate types, creating duplicated work and potentially inconsistent explanations.
But placing all descriptions under one authoritative registry creates another problem: the registry can become a point of control.
BRC-184 tries to occupy the space between those two extremes.
Shared metadata can exist, publishers can maintain it, and wallets can use it, while the metadata source remains optional and replaceable and the underlying technical identifier remains visible and usable independently.
That is what makes the proposal more interesting than a simple user-interface improvement.
It treats human readability as infrastructure without turning readability into permission.
Why This Matters
BRC-184 addresses a problem that becomes more important precisely when wallet infrastructure becomes more capable.
Technical interoperability is not enough. A wallet can correctly understand what an application is requesting while the person controlling the wallet still has little idea what the request means.
Human-readable metadata helps bridge that gap, but the proposal’s more consequential idea is that the explanatory layer should remain separate from the authority layer.
A registry can say, “This identifier is commonly described this way.” It should not thereby acquire the power to decide which applications may operate and which may not.
That boundary preserves something important in an open wallet architecture.
Standardization can improve coordination without requiring centralized approval, while human-readable interfaces can improve informed consent without creating a new gatekeeper between applications and users.
For BRC-100 wallets, that may become increasingly important as the permission system grows beyond simple payments into identity, certificates, application storage and machine-operated services.
The wallet does not only need to know what software is asking for. Eventually, the person using it has to understand too.
Proposed by
Ty Everett
Other notable BRC work includes:
- BRC-26 — Universal Hash Resolution Protocol, authored by Everett, defining a UTXO-based overlay model for advertising content availability. GitHub
- BRC-29 — Simple Authenticated BSV P2PKH Payment Protocol, authored by Everett. GitHub
- BRC-73 — Group Permissions for App Access, authored by Everett. GitHub
- BRC-100 — Unified Wallet-to-Application Interface, coauthored with Tone Engel and Brayden Langley. GitHub
Source Links
BRC-184 — Optional Metadata Registries and Their Stewardship
BRC-100 — Unified Wallet-to-Application Interface
BRC-73 — Group Permissions for App Access
BSV TIMES – Under the Surface
Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.
Update — October 2, 2026
Leave a comment