Thoughts on Identity, Privacy and Recovery on the Metanet

Identity need not be permission to exist

The first distinction is between a cryptographic identity and a certified description of its holder.

A public key can identify a continuing participant. Demonstrating control of its corresponding private key establishes a cryptographic relationship to that identifier. It does not, by itself, establish a legal name, nationality, age, employment status, or entitlement to a particular service.

Those are additional claims.

An identity certificate associates a subject key with assertions made by a certifier. A verifier decides whether those assertions are relevant and whether that certifier is an appropriate source for them. The certificate does not create the subject’s key, and the subject’s existence does not depend on the continued approval of its issuer. BRC-52 defines this certificate relationship; BRC-100 exposes operations through which wallets acquire, retain, and present certificates. (raw.githubusercontent.com)

Authentication, certification, and authorization must therefore remain separate.

Authentication can establish that a message came from the holder of a particular key. Certification can supply evidence about that holder. Authorization determines what an actor may do in a particular context. None automatically supplies the others.

A person authenticated as a customer is not thereby authorized to withdraw another customer’s funds. A certified professional is not thereby authorized to inspect every private record. A valid certificate about control of an email address is not automatically evidence of civil identity.

Equally, the absence of an accepted certificate is not proof that a person is fraudulent.

The proposed BRC-189 architecture makes room for direct personal recognition. A user can associate a key with someone they know, save that association as a contact, and use it without obtaining a certifier’s permission. It also distinguishes such personal assertions from externally certified claims and from application authorization. (raw.githubusercontent.com)

This matters because freedom requires room for relationships that institutions did not originate.

A certifier may help strangers establish confidence. It should not become a mandatory intermediary between people who already have an adequate basis for recognizing one another.

Privacy requires an observer

The question “Is this system private?” is incomplete.

Private from whom? Concerning which information? Under what assumptions? For how long?

A ledger observer, a counterparty, an application, a wallet process, a remote storage service, and a certifier occupy different positions. Information concealed from one may be deliberately available to another. Privacy analysis must account for identification, correlation, surveillance, disclosure, and the consequences of combining observations across contexts—not merely whether a payload is encrypted. (rfc-editor.org)

For the Metanet, several boundaries deserve separate examination.

The public ledger exposes transaction structure and whatever data has been placed in transactions. A counterparty knows what was exchanged with them. An application knows what the user or wallet gives it. A wallet process may handle sensitive requests and plaintext. A storage provider sees the records and requests its actual storage protocol exposes. A certifier knows the evidence it collected and the assertions it issued.

None of these parties should be described as knowing everything merely because they participate. None should be described as knowing nothing merely because private keys remain elsewhere.

BRC-151 raises legitimate concerns about this concentration of information and authority: a wallet architecture spanning payments, identity, permissions, and application state can become a valuable observation point, while common defaults can consolidate practical control. Those are risks to investigate and mitigate, not objections that disappear when an interface is called vendor-neutral. (raw.githubusercontent.com)

The corresponding response is not to abandon interoperability. It is to make its trust boundaries explicit.

A shared interface is not a shared custodian. A wallet implementation need not send every operation to its developer. A service storing encrypted backup files need not possess their decryption keys. But these are properties of an implementation and deployment, not consequences of displaying a standards badge.

The useful privacy claim is specific: this actor receives these data, cannot derive these other data under these assumptions, retains them for this purpose, and can be replaced through this process.

Anything broader deserves further questions.

The white paper’s privacy model and private key relationships

Section 10 of the Bitcoin white paper does not propose hiding the existence of transactions. It describes preserving privacy by separating public transaction information from identities, and using fresh key pairs to reduce linkage. It also acknowledges that some transaction structures permit linkage, including transactions that combine multiple inputs. (bitcoin.org)

The distinction is fundamental. Publicly verifiable settlement does not require a public directory identifying everyone involved. But neither does the absence of names make transaction graphs invisible.

BRC-42, the BSV Key Derivation Scheme—BKDS—provides a mechanism for maintaining private key relationships between parties. Each party combines its own private key with the other party’s public key to obtain the same ECDH shared secret. An invoice string is processed using that secret to produce a derivation offset. The sender can derive a child public key for the recipient; the recipient can derive the corresponding private key. The sender does not acquire the recipient’s spending key. (bsv.brc.dev)

This permits repeated interactions without requiring the same payment key to appear each time.

The privacy benefit is not that the parties become strangers to one another. They may know exactly whom they are dealing with. It is that an outside observer does not acquire their private derivation relationship merely by obtaining their public identity keys and observing the ledger.

BRC-43 structures derivation through protocol identifiers, key identifiers, and counterparties. It also defines permission granularity: level 0 requires no protocol permission prompt under that scheme; level 1 authorizes use of a protocol across counterparties; level 2 makes grants counterparty-specific. These are distinctions in permission scope, not three different strengths of cryptography. Application identity and permission enforcement remain responsibilities of the wallet. (raw.githubusercontent.com)

The separation also enables interoperability. Two applications deliberately using the same authorized protocol and derivation context may operate on the same user-held data. An application domain is not automatically an extra cryptographic separator simply because the wallet knows which application made the request.

This creates a duty to explain permission requests in terms of capabilities rather than obscure identifiers. A user should understand whether they are allowing one interaction, access to a shared data category, or continuing operations involving a counterparty.

Two special cases also require care. Self-derivation supports operations involving the user’s own key. “Anyone” derivation uses a publicly known private scalar and is appropriate where public verifiability or public access is intended. It is not a private counterparty relationship. (raw.githubusercontent.com)

Most importantly, fresh transaction keys do not guarantee unlinkability at every other layer.

If several services receive the same stable identity key, they can compare it. If they receive the same email address or certificate identifier, those values can provide another link. If a payment is made inside a session that already identifies the payer, changing the payment key does not make that session anonymous.

BRC-228 illustrates a narrower option: its payment profile substitutes a fresh ephemeral sender key in payment remittance, reducing the beneficiary’s ability to link payments through the payer’s long-term identity key. It expressly does not promise anonymity; transaction inputs, change, transport, and other observations remain relevant. (raw.githubusercontent.com)

The enduring principle is contextual identity. Continuity should be available where it is useful, and separation should be available where continuity would expose more than the interaction requires.

Coordinate privately; record only what needs common evidence

A public ledger need not become the transcript of every interaction that eventually produces a transaction.

Parties can exchange terms, authenticate messages, inspect certificates, verify signatures, and agree on payment details directly. They can then record the transaction or commitment needed for their shared undertaking.

BRC-103 provides mechanisms for mutual authentication, signed messaging, and certificate exchange, while BRC-104 maps those interactions onto HTTP. Authentication does not itself encrypt arbitrary message contents. Confidentiality requires an appropriate protected transport or message-encryption mechanism; a valid signature is not a privacy boundary. (raw.githubusercontent.com)

BRC-2 supplies wallet-mediated encryption using the relevant key-derivation context. Its purpose differs from that of transaction publication: it allows information to be communicated confidentially to the intended party rather than made available to everyone who can inspect the chain. (raw.githubusercontent.com)

For the music purchase, the parties might privately exchange an entitlement, delivery instructions, or a decryption capability. The ledger may record the payment and the output relationships needed to establish the purchase. It need not contain the purchaser’s personal correspondence or every condition discussed during negotiation.

The architectural separation developed in BRC-90, and extended conceptually in the proposed BRC-186, makes this division of responsibility important. BRC-186’s private overlays can hold non-public information and release it under application-defined authorization. That is a proposed service arrangement, not a claim that every overlay is private or that every described recovery and delivery mechanism is already implemented. (raw.githubusercontent.com)

A private overlay is also not necessarily private from its operator. If the operator holds plaintext, the operator can read it. If it holds only ciphertext, its knowledge depends on where the keys reside and what other information accompanies the records.

A commitment must be described with similar care. A hash can help establish that disclosed data correspond to an earlier commitment. It does not automatically conceal predictable data. Someone trying to recover a hashed yes-or-no answer has only two possibilities to test. Publishing a salt alongside low-entropy personal data does not make exhaustive guessing disappear.

These distinctions suggest a practical design discipline: separate the information needed for public verification from the information needed only by particular participants.

Keep sensitive content off-chain where public permanence is unnecessary. Protect retained content appropriately. Where a commitment is used, specify its actual hiding assumptions. And do not confuse a permanent receipt with permanent availability of the private material to which it refers.

What selective disclosure actually does

Selective disclosure becomes valuable when a user can satisfy a legitimate request without supplying an entire dossier.

The certificate machinery implements this through encrypted fields and controlled release of the keys needed to read them.

Under BRC-52, certificate fields are encrypted independently with random field-revelation keys. The signed certificate contains the encrypted fields and identifying metadata. The signature protects the integrity of that certificate, while a keyring controls access to field plaintext. (raw.githubusercontent.com)

When the holder agrees to disclose selected fields, the wallet retrieves the corresponding field keys and encrypts them for the chosen verifier. The implementation’s master-certificate machinery performs this selective rewrapping; it does not need to reveal every field key merely because one field is requested. (raw.githubusercontent.com)

The verifier receives the certificate and a verifier-specific keyring. It checks the certificate and decrypts the fields for which it has the necessary keys. The complete signed certificate can remain available for signature verification without providing decryption access to every field. (raw.githubusercontent.com)

This creates a meaningful choice.

A service needing evidence of a professional qualification need not automatically receive an address. A seller needing an age qualification need not automatically receive an email address. A user can disclose different subsets to different parties.

But the mechanism must not be credited with properties it does not provide.

First, revealing a certified date of birth is not the same as proving an age predicate without revealing that date. An “over a specified age” assertion should be a separately defined, appropriately certified claim, or use an additional proof mechanism designed for that purpose. Selecting fields cannot transform their meaning. General credential-design guidance likewise favors abstract claims and minimizing both credential content and verifier requests. (w3.org)

Second, selective field disclosure is not automatically an unlinkable credential presentation. The BRC certificate structure includes the subject key, certifier, serial number, type, and other stable material. Reusing it can reveal that two presentations concern the same certificate or subject even when different fields are disclosed. (raw.githubusercontent.com)

Third, the certifier is not made ignorant of the evidence it checked. A certifier that verifies an address or government document may learn sensitive facts during issuance. Encrypting the resulting certificate for later selective use does not erase the issuance process.

Fourth, disclosure cannot force the recipient to forget. A verifier that legitimately receives plaintext can retain it, copy it, or improperly share it. Cryptography can restrict initial access; it cannot generally revoke another person’s knowledge.

Fifth, fields can identify someone through combination. A qualification, locality, workplace, and approximate age may together reveal much more than their individual labels suggest. Data minimization must concern the information conveyed, not merely the number of fields selected.

The user interface is therefore part of the privacy mechanism.

It should identify the actual verifier, the requested fields, the purpose, and whether the operation is private disclosure or public publication. It should make refusal understandable. It should not hide broad disclosure inside an unrelated payment approval.

The power of selective disclosure lies in giving the holder a practical decision about the next boundary crossed. Its weakness appears when that decision becomes ceremonial because every useful service demands everything.

A certificate type is not a certifier

A certificate type describes the kind of assertion being made. A certifier identifies who made it.

These are different roles, and their separation is essential to an open identity ecosystem.

Suppose a type describes a verified professional qualification. Its specification should explain the fields, their meanings, the qualification being asserted, relevant dates, validation expectations, and any renewal or revocation semantics. Several competent organizations might be able to issue certificates conforming to that specification.

The type should not quietly mean “an assertion issued by the one company whose product first used this identifier.”

BRC-103’s certificate-request structure distinguishes acceptable certifiers from requested certificate types and fields. This permits a verifier to request a kind of evidence while accepting it from more than one issuer. (raw.githubusercontent.com)

Yet multiple issuers are not automatically interchangeable.

Matching field names is not enough. One issuer may verify current control of an email account while another merely accept a user-entered string. One may perform a rigorous qualification check while another sell an attractive badge. Their outputs may look alike without carrying equivalent assurance.

An open model should therefore permit different certifiers to qualify under explicit, comparable criteria. It should not require acceptance of anyone who copies a type identifier. The proper alternative to an issuer monopoly is accountable competition, not indiscriminate trust.

For important certificate types, those criteria should address what evidence is checked, how it is bound to the subject key, how long the assertion remains useful, how errors are corrected, who can revoke it, and what privacy obligations accompany issuance.

A verifier can then explain why it accepts particular issuers and how another issuer could become acceptable. Where legal constraints limit that choice, the restriction should be accurately described as such, rather than presented as an inherent requirement of the wallet interface.

Metadata registries must preserve the same boundary. BRC-184 treats registry entries as attributed descriptions of identifiers, not grants of permission, exclusive ownership, or automatic trust. A friendly name and icon can improve a prompt; they cannot establish that an issuer deserves authority. (raw.githubusercontent.com)

The centralization risk is a feedback loop worth anticipating.

Applications accept a familiar certifier because many users already possess its certificates. Users choose it because many applications accept it. Wallets make it the default because it appears convenient. Eventually, refusal by one company can become exclusion from many otherwise independent services.

Nothing in that sequence requires a formal declaration that the company governs the ecosystem.

The answer is to preserve multiple routes: competing qualified issuers, transparent acceptance policies, user-selected trust, private certificates where appropriate, and interactions that require no certified civil identity at all.

Different applications may have legitimate reasons to require different evidence. The dangerous move is converting those local requirements into a universal credential for ordinary participation.

Discovery should serve the user’s trust

Identity discovery is useful precisely because a cryptographic key is not a memorable description of a person.

But a discovery service must not become the institution that decides who everyone is.

The proposed BRC-189 connects public attribute discovery with user-selected trust and personal contacts. Its two discovery directions answer different questions: what accepted public descriptions are associated with a known key, and which candidate keys have published assertions matching supplied attributes. Neither question requires publishing the caller’s private certificates. (raw.githubusercontent.com)

Public publication is a separate act from private disclosure.

In the referenced identity implementation, publication obtains a field keyring for the “anyone” participant and places the resulting revelation in a transaction output. The selected fields are thereby made publicly readable. The fact that the keys retain an encrypted-envelope format does not make them confidential when the receiving participant’s private key is publicly known. (raw.githubusercontent.com)

A wallet must therefore distinguish “show these fields to this counterparty” from “publish these fields for public discovery.” An account-creation screen should not turn one into the other through an inconspicuous default.

Discovery also has its own metadata costs. Asking a provider about a particular person can disclose an interest or relationship even when the result is public. A local contact may provide sufficient information without making that query.

The contact machinery offers another form of continuity: a user can maintain an encrypted personal association with a key, including the name or contextual information meaningful to that user. Such a record expresses the user’s own recognition; it should not be mislabeled as an assertion independently certified by someone else. (raw.githubusercontent.com)

Trust scores require equally careful interpretation. The referenced wallet implementation groups discovery evidence by subject and avoids repeatedly counting the same issuer as independent support. That is a local acceptance calculation—not a proof that every issuer verified every field returned for the subject. (raw.githubusercontent.com)

An employer’s attestation does not independently confirm an email address merely because both appear in the same result. Ten issuer keys under common control do not necessarily represent ten independent sources. A popular result is not necessarily the person the user intended to contact.

Discovery should preserve provenance, ambiguity, and the ability to choose.

It must also distinguish operations that a convenient interface might otherwise collapse together. Removing a certificate from local wallet use is not revoking the issuer’s assertion. Withdrawing a public revelation is not erasing its historical publication. Deleting a contact changes the user’s local associations, not another person’s key.

The identity publication implementation can spend revelation outputs as part of withdrawal, but spending them does not remove the bytes from an already published transaction. (raw.githubusercontent.com)

A truthful interface should make these consequences visible before someone mistakes a cleanup operation for the reversal of a disclosure.

“Verified” must have a stated meaning

Several different facts are easily compressed into one reassuring word.

A signature may be valid. A certificate may refer to the expected subject. Its issuer may be accepted under a policy. A transaction containing relevant evidence may be included in the chain. A revocation check may be recent enough for the decision being made.

These are not interchangeable accomplishments.

The certificate implementation explicitly distinguishes signature verification from establishing current revocation status. A correct signature does not prove that the referenced revocation output remains unspent, nor that the external fact being certified remains current. (raw.githubusercontent.com)

A system should therefore distinguish revoked, not observed revoked under a stated current check, revocation disabled, and status unavailable. It should distinguish an expired claim from an invalid signature, and a missing response from evidence that no relevant record exists.

BRC-186 makes a related point about application evidence: knowing that an output was created is different from knowing whether it remains unspent, whether a claimed successor is accepted, or whether a provider has returned a complete answer. (raw.githubusercontent.com)

These distinctions improve both privacy and freedom.

They prevent a service from requiring unnecessary additional disclosure merely to compensate for an uncertainty it has not explained. They also prevent a provider’s outage from silently becoming a judgment about a person’s legitimacy.

An application may decide that it cannot proceed without sufficiently fresh evidence. It should say that. It should not convert “our current source is unavailable” into “this person is untrustworthy.”

The wallet is a security boundary, not a certificate of virtue

A wallet stands between applications and capabilities that matter.

BRC-116 describes permission behavior intended to prevent applications from spending funds, accessing private data, interacting with protected protocols, or obtaining certificates without the appropriate authorization. Such permissions belong in a wallet-controlled boundary, not merely in an application’s promise to behave. (raw.githubusercontent.com)

But the software enforcing the boundary must itself be trustworthy.

A malicious wallet can misrepresent a request, misuse data it handles, retain unnecessary records, or transmit information elsewhere. An application interface cannot cryptographically compel hostile software to describe its own conduct honestly.

Conversely, a wallet developer does not automatically see local wallet activity. That depends on what the product executes locally, what it transmits, what services it relies on, and whether its implementation matches its claims.

Users need answers to those questions, not a choice between two exaggerations: “the vendor necessarily knows everything” and “the standard prevents the vendor from knowing anything.”

Application identity must also be authenticated by the actual wallet transport. A permission decision is ineffective if an untrusted caller can simply claim to be a different application. Permissions should have understandable scopes, useful expiration and revocation controls, and defaults that do not turn a one-time interaction into indefinite authority.

Remote storage deserves a separate assessment.

A service holding wallet records may learn transaction relationships, output information, derivation metadata, or descriptive labels without possessing a spending key. A provider that stores only a user-encrypted backup file occupies a different position from one operating a queryable wallet database.

“Non-custodial” should not be used as shorthand for “incapable of surveillance,” and “encrypted backup” should not be used as shorthand for “all live storage operations are private.”

The right response is to minimize what each service receives, make its knowledge inspectable, and preserve the user’s ability to choose a different arrangement.

Portability makes the right to leave credible

BRC-100 provides a vendor-neutral application interface. Its value is that applications can request common wallet capabilities without being permanently designed around one vendor’s private API. That is application interoperability. It does not, by itself, prove that every wallet exposes a complete migration workflow. (bsv.brc.dev)

Data portability requires additional work.

BRC-38 specifies a canonical export format for a user’s Wallet Toolbox data, including records and relationships needed beyond a simple balance display: transaction and output information, certificates, labels, baskets, proof-related state, and retained deletion markers. Its scope does not include root-key or profile material lying outside that storage schema. A BRC-38 export is therefore substantial, but not automatically the entire recovery package for every wallet or application. (raw.githubusercontent.com)

BRC-39 adds a password-protected, authenticated encrypted wrapper for that export, using Argon2id and AES-256-GCM. It protects the exported artifact; it does not supply missing records, standardize every secret-recovery process, or retroactively encrypt an operational provider’s database. A weak export password remains a weakness. (raw.githubusercontent.com)

The practical promise should be tested end to end.

Can another implementation read the export? Can it reconstruct the relevant relationships? Can the user obtain the separately required secrets and profile information? Do certificates remain usable with their field-access material? Do supported assets retain their application meaning?

A JSON file that another wallet cannot interpret is not meaningful portability merely because it is downloadable. Nor is a list of transactions enough when spending or application recovery depends on additional context.

The same concern applies to synchronization. A documented mechanism such as BRC-40 can help move wallet state between storage arrangements, but successful synchronization must preserve the relevant semantics rather than merely copy a convenient subset of rows. (raw.githubusercontent.com)

Users should be able to leave a malicious provider, but the ability must be prepared before the provider becomes hostile.

Independent exports, compatible alternatives, and tested recovery procedures convert exit from a theoretical right into a usable safeguard. Portability does not make previous spying harmless. It limits dependence and allows future reliance to end.

Changing providers while retaining the same keys also does not erase existing correlations. It preserves continuity. Where a privacy or security incident requires a different identity, that is a separate operation.

Recovery must preserve more than a secret

There are at least three different recovery problems.

The first is recovering cryptographic control: the keys or other material needed to authorize operations and decrypt information.

The second is recovering knowledge: the records needed to locate assets, reconstruct derivation contexts, understand application state, and identify what happened.

The third is recovering recognition: the process through which counterparties, certifiers, and applications accept a continuing or replacement identity.

A seed phrase may address part of the first problem while leaving the others unanswered.

For example, BRC-29 payments use sender information and derivation parameters that the recipient needs to internalize and later manage the payment. Recovery must preserve or retrieve that required context; a root key alone does not conjure an arbitrary missing derivation prefix or suffix. (raw.githubusercontent.com)

Similarly, random certificate field keys do not become reconstructible merely because the holder has recovered a root key. The associated encrypted key material and certificate records must remain available. (raw.githubusercontent.com)

This is not an argument against private derivation. It is an argument for treating the private records supporting it as part of the user’s property and recovery plan.

Different recovery mechanisms can address different failure modes. BRC-140 specifies threshold sharing; BRC-154 describes optional backup services holding individual shares, with reconstruction performed locally after enough shares are retrieved. BRC-157 specifies an entropy-rooted relationship between mnemonic and share-based recovery. These are distinct arrangements, not a license to assume that every phrase, share, or exported key has the same meaning. (raw.githubusercontent.com)

Threshold recovery also depends on meaningful independence. Placing different shares behind the same account, operator, or administrative failure domain can defeat the purpose of distributing them.

The proposed BRC-188 User Management Protocol offers another model. It documents account recovery using any two of a presentation key, password, and recovery key. Its password-plus-recovery-key path is intended to work without the old authentication backend. UMP is optional beneath BRC-100, is not Shamir sharing, and is not a complete backup of wallet transaction storage. Its security discussion also acknowledges offline password-guessing exposure when another factor is obtained. (raw.githubusercontent.com)

These mechanisms should be evaluated by what survives a real failure.

Can the account be recovered if the old vendor disappears? Can the private application records be retrieved if the primary storage provider fails? Can the user obtain necessary transaction evidence from another source? Are the instructions intelligible to someone who did not build the original system?

Recovery must also distinguish loss from compromise.

Restoring the same keys can preserve identity after losing a device. It does not exclude an adversary who copied those keys. Changing a password that wraps an unchanged root does not make previously copied roots disappear. UMP explicitly notes that old encrypted account renditions can remain relevant and that factor rotation is not root-key revocation. (raw.githubusercontent.com)

A compromised-root response may therefore require new keys, asset migration, new certificates, changed permissions, and deliberate updates to relationships. The appropriate continuity evidence depends on the incident; an old-key signature alone may be insufficient when the old key is what was compromised.

Recovery restores capability. It cannot promise to reverse information that has already escaped.

Key-linkage disclosure deserves exceptional caution

Auditability can be useful. It can also become an unusually powerful disclosure channel.

BRC-69 distinguishes revealing a specific derivation offset from revealing the root ECDH secret shared with a counterparty. The second disclosure has much broader scope: for known or subsequently obtained derivation identifiers, it can expose relationships across the same pair of identities, including future derivations while that relationship remains unchanged. It is not merely a receipt for one payment. (raw.githubusercontent.com)

Encrypting the revelation for an intended verifier, as addressed by BRC-72, protects its delivery. It does not reduce what that verifier learns or prevent subsequent misuse. (raw.githubusercontent.com)

There is also an important cryptographic qualification that should not be hidden out of loyalty to earlier explanations.

BRC-69’s text states that root-linkage revelation does not permit decryption of BRC-2 data. That assurance should not be relied upon for the documented additive child-key construction. The referenced SDK derives a BRC-2 symmetric key from ECDH between the derived child private and public keys. (raw.githubusercontent.com)

The consequence can be seen algebraically. Let the root public keys be (A=aG) and (B=bG), the root shared point be (S=abG), and the invoice-derived offset be (t). The child ECDH point is:

[ (a+t)(b+t)G = S+tA+tB+t^2G. ]

Once (S) is disclosed, someone who knows the derivation identifier can calculate (t) and the right-hand side without learning either root private key. For the documented construction, this means the corresponding derived symmetric key can be reconstructed. Available matching ciphertext or wrapped key material may consequently be decrypted. This is a mathematical consequence of the specified construction and referenced implementation, not an allegation of observed exploitation in a deployed product. (bsv.brc.dev)

A root-linkage disclosure should therefore be treated as potentially affecting confidentiality as well as public-key correlation. The exact consequences require review of the construction, available transcripts, and affected relationships. The conflicting explanatory claim deserves independent cryptographic review and corrective tests.

Nor does describing a revelation as a zero-knowledge proof resolve this issue. BRC-94’s proof concerns the correctness of a revealed shared secret without revealing the root private key. The shared secret itself is still disclosed. A proof can protect one secret while deliberately releasing another with substantial consequences. (raw.githubusercontent.com)

The practical preference should be the narrowest evidence sufficient for the purpose: a relevant receipt, signature, transaction proof, or appropriately scoped disclosure rather than an entire relationship secret.

Ordinary login or payment should not quietly acquire an exceptional audit capability. Such disclosures can affect the counterparty’s privacy too, and should never be disguised as routine connectivity.

Warning signs that should change whom users trust

Vigilance needs observable criteria. Otherwise, “choose a trustworthy provider” becomes advice that can only be followed after the damage.

The following are warning signs, not allegations against particular products. A missing feature may be an honestly disclosed limitation. Persistent concealment, misrepresentation, unjustified expansion of authority, or obstruction of departure is a different matter.

1. Requests for secrets unrelated to the service. A certifier, ordinary application, or support agent asks for root private keys, recovery passwords, or enough shares to reconstruct a key merely to verify identity or troubleshoot a payment. Recovery secrets should enter only the specifically trusted recovery environment that actually needs them.

2. Exceptional audit access presented as ordinary permission. Login, a small payment, or certificate presentation requires broad counterparty-linkage disclosure, unrestricted signing, or access to unrelated wallet history without a clear necessity.

3. Silent movement from private disclosure to public publication. A provider publishes attributes, publicly decryptable keyrings, identity associations, or sensitive transaction metadata when the user authorized only a private exchange.

4. Promises of separation followed by undisclosed correlation. A service quietly merges profiles, application activity, contact relationships, or identities after representing those contexts as separate.

5. Misleading descriptions of storage privacy. A provider claims that keeping spending keys local means it cannot inspect wallet metadata, or cites backup encryption as evidence that all live database operations are confidential.

6. Permission controls that do not control anything. Denied or revoked requests continue to succeed; grants become broader without approval; applications can impersonate another origin; or a wallet’s interface conceals what it is authorizing.

7. Exit becomes conditional on surrendering more data. Exports are incomplete, withheld, intentionally incompatible, or made dependent on unnecessary new disclosures. A user should not have to reveal a recovery secret to obtain records already belonging to them.

8. Recovery remains dependent on the institution it is meant to replace. A supposedly independent recovery process still requires permission from the old vendor, access to its exclusive endpoint, or private metadata it refuses to export.

9. A certificate type becomes a commercial franchise. Equivalent qualified issuers are excluded without a defensible assurance, operational, or legal reason, while users are pressured to buy the incumbent’s wallet, storage, or other services.

10. Certification expands beyond what was checked. A mailbox-control check is presented as comprehensive identity assurance; a collection of unrelated attestations is flattened into an unexplained “verified person”; or an attractive registry listing is treated as proof of issuer trust.

11. Revocation becomes retaliation or undisclosed leverage. An issuer threatens unrelated access to compel use of affiliated products, punish criticism, or impose conditions absent from its stated certification policy.

12. Unknown status is represented as a completed check. Stale data, missing evidence, disabled revocation, or service failure is labeled “verified,” “current,” “complete,” or “definitely revoked” without an adequate basis.

13. Nominal independence conceals a common point of control. Multiple backup services, certifiers, or storage brands are presented as independent safeguards while sharing undisclosed ownership, administrators, recovery accounts, or critical infrastructure.

14. Scrutiny is treated as disloyalty. A provider refuses to explain its data flows, obstructs independent compatibility tests, retaliates against good-faith reporting, or expects its reputation to substitute for evidence.

Credible evidence of deliberate exfiltration, unauthorized signing, or covert publication is a reason to stop entrusting new activity to the affected system and prepare a controlled departure. Less decisive failures may justify investigation and a limited remediation period, but should not justify indefinite dependence.

Departure should itself be careful. Preserve evidence without publicly exposing secrets. Use a trustworthy environment for recovery. Verify that replacement storage and software can read the necessary material before deleting the only working copy. If keys may have been compromised, distinguish moving data from replacing authority.

The user’s freedom is not improved by panic that destroys their last recoverable records.

Test continuity before a crisis

A mature ecosystem should publish evidence of portability and recovery, not merely promises about them.

One useful test changes the wallet while preserving the user’s identity and application state.

Another changes the storage provider while removing the original provider from the recovery path.

A third loses the original device and reconstructs the supported wallet state from independently retained material.

A fourth presents the same certificate type from a different appropriately qualified issuer.

A fifth checks whether a privately established contact remains usable after an unrelated certifier or discovery service disappears.

These tests should include ordinary payments, supported tokens, certificate field access, private application records, and the relevant permission and trust settings. Any excluded category should be stated plainly.

Tests involving failure should also preserve uncertainty. A disconnected source should not be mistaken for an empty account. An unavailable discovery provider should not silently create a replacement identity. Restoring an old backup should not imply that old transactions or revoked credentials have become current again.

Critically, these exercises should be performed with disposable test data before users are asked to rely on the results.

The burden cannot fall entirely on individuals. Developers should provide comprehensible exports, safe defaults, clear prompts, migration documentation, and tools that make independent recovery ordinary rather than heroic. Standards authors should distinguish required behavior from aspirations and record known implementation differences.

Freedom that can be exercised only by the original engineers is not yet broadly available freedom.

Stewardship applies to the privacy architecture too

An open protocol can still acquire closed defaults. A portable format can still be neglected by dominant products. Selective disclosure can still be undermined by collective demands for unnecessary information.

These are not reasons to dismiss the mechanisms. They are reasons to preserve the institutions and habits that make the mechanisms useful.

Wallets should compete without owning their users’ identities. Certifiers should compete without owning certificate types. Storage providers should serve continuity without controlling the only copy of it. Discovery services should supply evidence without replacing personal judgment. Recovery providers should reduce failure risk without quietly assembling a new custody monopoly.

No author, sponsor, standards body, wallet company, or certifier—including the authors of this document—deserves an exemption from these expectations.

If a privacy claim is incorrect, it should be corrected. If a reference implementation violates an intended boundary, the discrepancy should be made visible. If an institution begins demanding more authority than its function requires, participants should be able to challenge it and continue elsewhere.

Long-lived privacy also requires honesty about time. Information published today may remain available after its original purpose ends. Encrypted records may outlive the security assumptions protecting them. A future migration can improve future protection; it cannot guarantee the disappearance of old copies or knowledge already acquired.

The sound response is restraint in what is published, precision in what is claimed, independence in what can be recovered, and continuing examination of whom the system empowers.

The Metanet’s promise is not that identity abolishes privacy, or that cryptography abolishes trust. It is that people can carry useful identities, disclose only what an interaction requires, preserve their records and capabilities, and replace those who serve them without surrendering their continuity. BRC-100 and its related mechanisms can support that promise—but only when implementations, defaults, and institutions remain answerable to it. Freedom endures when recognition is not captivity, disclosure is not submission, recovery is not dependence, and the right to leave remains something a person can actually do.