BRC-184

Optional Metadata Registries and Their Stewardship

When an app asks a wallet for permission to do something, or asks it to use a storage bucket or a certificate type, the request often shows up as raw codes and numbers with no human explanation. Users cannot tell what they are approving, and there has been no shared, trustworthy place to look up what an identifier actually means. This makes it hard to build clear permission prompts without every wallet inventing its own private glossary.

Ty Everett25 Sept 2026changed 25 Sept 202614 min read

Reference for an AI

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

Why: Wallets need a way to show users understandable names and descriptions for protocol identifiers, baskets and certificate types without turning that lookup into a gatekeeper over what the wallet will allow.
What: BRC-184 defines three optional metadata registries, ProtoMap, BasketMap and CertMap, that attach human-readable names, descriptions, icons and documentation to protocol identifiers, output baskets and certificate types, along with rules for how registry stewards and wallets may use that information.
How: A publisher signs metadata as a small on-chain token in the relevant basket, an overlay topic indexes it, and a wallet performs a bounded lookup by exact identifier to enrich its normal permission prompt, falling back to the raw identifier if no record is found or the lookup fails.

What this lets you do

Look up a human-readable description for a protocol ID, basket or certificate type
Publish a signed metadata record as a registry steward
Fall back safely to raw identifiers when metadata is missing or unreachable
Swap or disable metadata sources without breaking underlying protocols
Dispute or correct an inaccurate registry entry

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

This diagram is a placeholder based on the topic. A diagram drawn from this standard has not been generated yet.

The specification

Read the original

Abstract

ProtoMap, BasketMap and CertMap associate wallet protocol identifiers, output baskets and certificate types with understandable names, descriptions, documentation and images. This proposal explains those registries and defines a limited role for their stewards: improving public information, without deciding who may implement a protocol, request a wallet operation or use an application.

Registry metadata is optional. A wallet adopting this proposal MUST NOT make registry inclusion, omission, opinion or availability a condition of using an otherwise supported protocol. Protocol validation, application permissions, spending approval and certificate verification remain separate. Builders are encouraged to document their protocols through the BRC process and then ask their chosen registry operators for inclusion. The initial process is deliberately lightweight and expected to evolve through public review.

Status and scope

This is a proposed explanatory and stewardship framework with a wallet consumption profile. The uppercase terms MUST, MUST NOT, SHOULD and MAY express requirements of this proposal for implementations claiming to follow it, as described by RFC 2119 and RFC 8174. They are not a claim that every existing wallet already behaves this way, that the proposal has ecosystem consensus, or that a formal appeals institution already exists.

The proposal does not change BRC-100, key derivation, transaction validation, overlay wire protocols or existing identifier reservations. The implementation map below describes deployed conventions; it is not a replacement wire-format specification. This proposal does not create a global namespace allocator, installable permission scheme, certificate issuer accreditation process, application store or security reputation feed.

Motivation: coordination without control

A permission prompt containing only [2, "auth message signature"] is hard to understand. A useful description can explain that an application wants to sign authentication messages, while retaining the exact tuple and the actual counterparty. Similar problems arise when showing unfamiliar baskets and certificate fields. Shared, maintained descriptions reduce duplicated research and help builders explain interoperable identifiers consistently.

IANA's service-name and transport-port registry is a useful analogy for this coordination function: publish a stable reference, make assignments understandable, reduce collisions and steward information impartially. IANA itself distinguishes registration from endorsement and warns against treating a registered port as proof of trustworthy traffic. Registry stewardship does not provide a technical mechanism to stop someone using a port.

The analogy has limits. IANA has its own defined assignment procedures and authority; this proposal neither imports them nor claims affiliation. These metadata registries record publisher-attributed descriptions of identifiers, rather than allocating exclusive rights to use them. A developer does not need a registry operator's permission to use a valid protocol identifier. No registry operator receives authority over BRC adoption or the wallet's permission decisions from this proposal.

1. Participants and boundaries

Participant	Role	Authority it does not acquire from metadata
Protocol or application author	Defines and documents intended behavior and actual identifiers	Ownership of an identifier merely by requesting a listing
BRC contributors and maintainers	Discuss and publish specifications under the BRC contribution process	Control of a separate operator's publication key
Registry publisher or steward	Signs and maintains descriptions under its own identity	Power to authorize a user's wallet operation, revoke a protocol or grant certificate trust
Overlay host	Indexes and serves registry transactions according to its topic rules	Authorship of a record merely by serving it
Wallet implementer	Chooses metadata sources, validates and renders results, implements supported protocols	A metadata-based veto over otherwise supported use under this profile
Wallet user	Grants or denies permissions and chooses available trust preferences	An obligation to use a particular registry publisher

The entity hosting an overlay and the entity signing a record can be different. Trusting a host for availability is not the same as accepting a publisher's statement. Metanet Trust Services is one publishing identity used by some wallet defaults, not a fourth registry type, a universal authority or a requirement imposed by BRC-100.

2. What a registry record describes

Registry	Exact lookup identity	Human-readable information	Existing topic / lookup service
ProtoMap	BRC-43 security level and protocol string	Name, description, icon and documentation	`tm_protomap` / `ls_protomap`
BasketMap	Basket identifier	Name, description, icon and documentation	`tm_basketmap` / `ls_basketmap`
CertMap	Certificate type bytes, conventionally expressed as base64	Name, description, icon, documentation and per-field descriptors	`tm_certmap` / `ls_certmap`

A consumer's record identity also includes the network and publisher public key. Identical identifiers described by two publishers are two attributable statements, not an instruction to overwrite one with the other. Protocol security levels must not be collapsed; a BRC number is not itself a BRC-43 protocol tuple. Use the identifier accepted by the applicable wallet standard and implementation, with its required normalization. Do not derive identity from a friendly name or registry search result.

A certificate type is not a certifier identity. Describing a type or its fields does not mean trusting every issuer that uses it. Field spelling and case identify the signed certificate data; changing a display label must not rename those fields or alter the certificate. A basket description does not grant access to its outputs or permission to spend them. There is no additional spending-registry type in this model.

Parameterized identifiers need protocol documentation of their family and parameters. A literal record is not a wildcard matching rule. Avoid publishing user-specific counterparties, linkage data or dynamically generated identifiers as a public catalogue.

2.1 Existing publication lifecycle (informative)

Current RegistryClient implementations publish one-satoshi signed PushDrop outputs. The registry publisher signs the metadata and controls the output. Creating a definition creates a token; updating spends the previous output and creates a replacement; removing spends it without a replacement. Implementations use the respective protomap, basketmap or certmap wallet basket and signing protocol [1, registryName], key ID 1, with the anyone counterparty. The corresponding overlay topic indexes accepted outputs and its lookup service returns matching transaction outputs.

Removal withdraws that publisher's current description. It does not erase blockchain history, revoke a certificate, spend application assets, change wallet grants or prohibit the underlying identifier. An old database row or cached response is not by itself proof of a current unspent record. Consumers must distinguish authenticated content from freshness, availability and completeness.

The on-chain payload contains descriptive fields and publisher attribution. Review decisions, disputes, source revisions and operator policy changes can be maintained in a linked public review log; this proposal does not pretend they are additional fields already present in the deployed token format.

3. Wallet consumption profile

3.1 Metadata must not become permission

A conforming wallet MUST keep the registry result outside its decision about whether an otherwise valid and supported protocol operation is available. It MUST NOT block, hide, disable or impose an additional confirmation solely because a record is missing, withdrawn, disputed, comes from an unselected publisher, or cannot be fetched. It MUST NOT require a builder to obtain a BRC number, registry approval, payment or operator relationship before an application can use the underlying protocol.

A record's presence, friendly wording, icon or publisher trust score MUST NOT grant, enlarge or renew permissions, approve spending, select a counterparty or establish trust in a certificate issuer. Registry strings MUST NOT be executed as policy or converted into an allowlist or denylist.

This does not remove normal wallet checks: user denial, protocol validity, reserved administrative identifiers, unsupported executable permission modules, transaction validity, fee limits, originator isolation and independently authorized application policies still apply. The reason for such a refusal must be the actual rule, not registry listing status. In particular, BRC-98/99/111 module support and the BRC-123 scheme registry are distinct from descriptive ProtoMap/BasketMap/CertMap records.

3.2 Fallback and presentation

Wallets MUST retain a usable normal authorization path showing the exact requested identifier and relevant request details when optional metadata fails. Start from that fallback; enrich it when a bounded lookup succeeds. Do not indefinitely delay a permission prompt, require a lookup retry, or reset a user's pending choice because the registry is unavailable. A neutral “description unavailable” indication is appropriate; presenting “unregistered” as evidence of danger or an extra barrier is not.

Show the exact protocol tuple, basket or certificate type alongside, or readily inspectable from, the friendly description. Preserve the actual originator, counterparty, requested operation, amount and certificate fields as applicable. Distinguish the application's explanation from the registry publisher's description. If metadata changes during a prompt, it must not silently change the request or the scope of consent.

For conflicting descriptions, apply a disclosed local source-selection policy or show separately attributed alternatives. Never blend fields from different publishers into a falsely unified endorsement. A neutral raw-identifier fallback remains available. A wallet may reject malformed or unauthenticated metadata without rejecting the protocol request.

3.3 Source choice

A wallet MAY ship with default publishers and hosts. Defaults are implementation choices, not permanent ecosystem appointments. Implementations adopting this profile SHOULD provide a documented way to replace or disable metadata sources without disabling the underlying protocols or forcing a user to migrate funds. Different wallets and communities may select different publishers or operate their own.

Registry-publisher trust and certificate-issuer trust have different meanings. Implementations that currently share a settings structure for them SHOULD disclose that coupling and its effects. Consumers MUST NOT infer that a publisher is an acceptable certificate issuer merely because its registry metadata is selected.

3.4 Acceptance scenarios

Scenario	Expected result
Identifier has no record	Normal request and permission flow with exact identifier
Hosts are offline, slow or return an error	Bounded lookup; usable fallback without a registry-dependent veto
Record is withdrawn or under dispute	Description may change or disappear; underlying protocol remains available
Record claims “automatically approved”	Treat it as untrusted prose; enforce the same wallet permissions
Record has an invalid signature or unsafe image URL	Discard the metadata or resource; preserve the request flow
Two chosen publishers disagree	Attribute alternatives or apply the disclosed selection policy; no automatic protocol denial
User changes publisher	Change descriptions, not existing grants, assets or supported protocol semantics
Request names an unsupported `p` module or reserved admin identifier	Apply the relevant wallet rule independently of metadata

These scenarios are an implementation review checklist, not a claim of completed conformance testing for existing products.

4. Builder inclusion workflow

Document the protocol through the BRC process. Open a BRC proposal, or improve an existing relevant BRC, using the repository's contribution and numbering rules. Explain exact tuples, basket identifiers and certificate types; intended semantics; counterparty and key-ID rules; requested capabilities; security and privacy implications; versioning and compatibility; and implementation evidence. Do not invent a new BRC for an already documented standard merely to obtain a listing.
Contact the registry operators you want to publish the description. A BRC pull request is not automatically forwarded to every operator. Supply the BRC or PR link and status, implementation/specification revisions, proposed names and descriptions, public documentation, usable icons and exact certificate-field descriptors where relevant. Identify which publisher and network the request concerns.
Collaborate on accuracy. Operators check the exact identifiers, existing use, collisions, documentation and neutral wording. They may ask for clarification, publish an accurately labeled experimental description, or defer a request with reasons. A merged BRC does not automatically create a registry entry, and an entry does not mean a draft BRC has been adopted.
Keep the record maintained. Notify publishers of changed semantics, documentation, images, maintainers or deprecation. Request a correction against the exact identity and current record, with source evidence. Retain historical compatibility information where deployed clients still need it.

For the initial Metanet Trust Services process, use the BRC submission guide: open or link a BRC issue/discussion or proposal, tag @ty-everett, and reserve ty@projectbabbage.com for genuinely urgent or long-time unresolved matters. These are this operator's contact arrangements, not mandatory channels for every publisher.

This is a lightweight initial process, not a claim of a fully formal registration bureaucracy, guaranteed response time or mandatory universal approval. Operators SHOULD publish their monitored contact route, criteria, queue/status information and current process version. They should make submission and maintenance practical for independent builders. None of these editorial steps is a prerequisite to implementing or using a valid protocol.

5. Impartial stewardship and disputes

Operators adopting this framework commit to impartial treatment under published, consistently applied editorial criteria. Listing decisions should concern identifiable technical meaning, evidence, public documentation, accurate attribution and useful presentation. They MUST NOT be conditioned on using the operator's commercial services, endorsing its views, abandoning a competitor, or granting it additional authority over an application. Any applicable fees, capacity constraints or service arrangements SHOULD be disclosed; payment must not buy misleading descriptions or preferential truth claims.

Operators SHOULD publish dated reasons for inclusion, correction, deferral and removal, with relevant source references and record outpoints where available. Avoid silently repurposing an established identifier's description for an incompatible meaning. A first listing or earlier request is evidence of chronology, not a grant of intellectual-property rights or technical exclusivity. When an identifier has conflicting real uses, document the ambiguity and encourage authors to resolve it or choose distinct identifiers.

5.1 Initial dispute handling

Until a more formal process is agreed, the minimum useful practice is:

Accept a correction or dispute through the operator's published contact route, identifying the publisher, network, exact identifier, disputed statement, evidence and requested remedy.
Acknowledge the issue and give affected parties a reasonable opportunity to provide evidence. Publish a status and reasoned outcome without unnecessary personal information.
Disclose relevant conflicts of interest and seek an uninvolved reviewer where practicable. If none is available, state that limitation rather than claiming independent adjudication.
Allow reconsideration when new evidence appears and retain a visible correction history. Distinguish unresolved technical ambiguity from a finding against a party.
Respect the dispute and review procedures the operator publicly adopts as the process develops. Publish material process changes, their effective dates and a route for community feedback; do not invent or retroactively imply an appeals body that does not exist.

A narrow, urgent removal of misleading or unsafe display material may precede ordinary review, with a prompt explanation and opportunity to challenge the decision. That action cannot become a protocol ban through wallet behavior. Sensitive incident reports belong in an appropriate private channel, not an immutable public record.

This framework does not adjudicate legal rights, establish a universal arbitration authority or require competing publishers to reach identical conclusions. Disagreement remains visible and users retain the option to select other sources.

6. Replication, continuity and exit

Published registry transactions are public on-chain data. Independent parties can retrieve and verify available records, maintain archives and serve compatible overlay indexes without the original publisher operating the only server. Replication preserves the original publisher's signature and attribution; it does not grant possession of its private key or authority to modify its signed outputs. A new publisher can publish its own attributed descriptions, with provenance, and users can choose that publisher.

Public blockchain history is not a promise that every host retains or serves every transaction, that an index is complete or fresh, or that linked images and documentation remain online. Replicators need transaction availability, validation and current-state reconstruction, appropriate synchronization, and a policy for stale or conflicting observations. External resources require their own preservation and licensing arrangements. Operators SHOULD document export/recovery procedures and avoid making a proprietary API or nonportable enrichment the only way to obtain essential metadata.

If a publisher disappears, behaves unfairly or loses its key, its defaults are replaceable. Wallet users and implementers can change source selection; other hosts can serve authentic available records; other publishers can issue alternative descriptions. A replacement publisher must not impersonate the old identity. There is no new master authority or mandatory recovery key introduced by this proposal.

7. Security and privacy considerations

The intended authority of a registry publisher is limited to attributable descriptive statements. Nevertheless, attractive false descriptions can mislead people and lookup infrastructure can observe what identifiers a wallet requests. Optional does not mean harmless.

Consumers SHOULD authenticate records, scope caches by network/publisher/type/identifier, bound lookup and parsing work, and treat text and URLs as untrusted input. Render text without executing markup; constrain images and redirects; avoid using metadata fetches to expose local resources or credentials. Prefer privacy-preserving caching and avoid sending user certificates, secret fields, transaction histories or unnecessary counterparties to metadata services. Validate data independently even when served by a familiar host.

Operators should secure publication keys, separate them from hosting credentials, retain review and change history, and limit what information is placed permanently on-chain. If a key is compromised, disclose the affected identity and scope, preserve evidence and support replacement source selection. Neither a signature nor a familiar publisher proves a description is true, safe, current or endorsed by the protocol author. Registry content must not automatically install software, grant wallet permissions or turn an incident into a remotely administered protocol kill switch.

Implementations and adoption

The TS Stack SDK RegistryClient, the overlay topic implementations, and Registrant provide existing publication and lookup tooling. Wallet settings and presentation layers determine which publishers are consulted and how results are displayed. Hosting, publisher selection and actual permission enforcement must be reviewed separately.

The companion guides can explain current APIs and operator contacts without hardcoding them into a permanent ecosystem authority. Adopting this proposal requires checking the wallet scenarios above and publishing the operator's actual stewardship policy. Documentation of the desired boundary alone is not evidence that every installed wallet implements it.

References

Was this helpful?