Wallets & Identity

Losing access to a wallet service does not necessarily have to mean losing the account that was used through it.

A newly proposed BRC attempts to document an account-recovery model already used across several BSV wallet implementations so that other compatible software can discover, recover and continue the same account.

Proposed BRC-188, User Management Protocol, or UMP, was opened by Ty Everett on September 27.

The specification remains under review.

Its significance is therefore not a new wallet release or a newly deployed recovery service. The proposal is documenting an existing account architecture in enough detail that it can become interoperable beyond the implementations that originally used it.

Three factors, any two for recovery

UMP organizes account recovery around three factors:

• a presentation key
• a password
• a recovery key

Any two of the three can reconstruct the account’s underlying root key material.

For ordinary use, a Wallet Authentication Backend, or WAB, may provide the presentation key after authenticating the user through some external method.

The user supplies the password locally.

Together, those two factors can recover the account.

But that is not the only path.

If the presentation service is unavailable, the user can instead combine the password with the independently retained recovery key.

If the password is forgotten, the presentation key and recovery key form the third possible recovery combination.

The model is therefore designed so that losing any one factor does not automatically destroy access to the account.

The authentication provider does not have to remain indispensable

The vendor-independent recovery path is particularly important.

A Wallet Authentication Backend may help make everyday login convenient by connecting an external authentication method with the presentation key.

But proposed BRC-188 does not make that backend the permanent custodian of the account.

The specification explicitly describes recovery without the original WAB.

A compatible client can take the user’s recovery key, derive its discovery hash, locate the corresponding UMP account descriptor, ask for the password locally and reconstruct the account’s root keys.

The old authentication provider does not have to approve that recovery.

A replacement wallet could then establish a new presentation key with another backend and update the account descriptor while preserving the underlying account roots.

That means the service helping someone authenticate can change without necessarily forcing the user to create an entirely new cryptographic identity.

Recovery factors can change while the account stays the same

The account itself is represented through an on-chain descriptor.

That descriptor contains encrypted material needed to recover the account roots, discovery hashes for the relevant factors and the cryptographic information needed to authenticate and update the descriptor.

When a factor changes, the existing descriptor is normally spent and replaced by a successor.

A password can be changed.

A lost recovery key can be replaced.

A presentation key associated with an authentication provider can be rotated.

But the root primary and privileged keys can remain unchanged.

That is important because those roots are what sit beneath the wallet’s continuing identities and derived keys.

The recovery mechanism is therefore not simply creating a new wallet after something goes wrong.

It is intended to preserve continuity of the existing account while allowing the mechanisms used to reach that account to evolve.

Two-of-three does not mean multisig

The specification also makes an important technical distinction.

UMP’s two-of-three recovery model is not a Bitcoin multisignature arrangement and it is not Shamir Secret Sharing.

There are not three independent signing keys where two signatures are required to spend an output.

Instead, combinations of the three recovery factors are used cryptographically to decrypt the underlying account-root material.

The account descriptor itself uses a derived signing key.

That distinction matters because the recovery policy exists in the wallet architecture rather than as a two-of-three consensus rule enforced by the locking script.

The account can be discovered independently

For recovery to work across implementations, another wallet also needs to know where to find the account descriptor.

Proposed BRC-188 therefore documents the overlay topic and lookup behavior used by UMP, including tm_users for account records and ls_users for discovery.

The presentation and recovery factors each have discovery hashes associated with them.

A compatible recovery client can use the appropriate hash to locate the account record and then validate the transaction evidence and account lineage before attempting recovery.

The proposal goes into considerable detail about how successive versions of an account are connected, how conflicting or stale records should be handled and how existing legacy account formats must remain recoverable.

That historical compatibility is part of the reason for documenting UMP now.

A recovery standard is much less useful if a new implementation understands only newly created accounts while older users remain tied to the software that originally created theirs.

Existing implementations become reference evidence

The proposal identifies Wallet Toolbox, Metanet Client Desktop and Metanet Explorer as existing implementations of the account model.

That gives BRC-188 a somewhat different character from a purely prospective specification.

The goal is partly to describe what is already deployed closely enough that another implementation can reproduce the same account behavior.

The pull request includes compatibility requirements for older PBKDF2-based accounts as well as the newer account format using explicit password-derivation metadata.

It also includes test vectors and recovery cases intended to make independent implementations checkable against the same cryptographic behavior.

The proposal itself is still open, so those requirements remain subject to review and change.

Account recovery is not a complete wallet backup

There is also an important boundary.

Recovering the UMP account roots does not automatically recreate every record previously held by the wallet.

Wallet transaction history, metadata, proofs, labels, baskets and other stored wallet state may exist in a separate storage system.

If that storage disappears and no backup exists, recovering the account keys does not magically restore those missing records.

BRC-188 says this explicitly.

Vendor-independent recovery still needs the account descriptor and transaction evidence, and broader wallet state may require compatible storage or an independent wallet backup.

That distinction prevents “account recovery” from being mistaken for “complete restoration of everything the wallet ever knew.”

Preserving the account beyond one implementation

The larger value of proposed BRC-188 is therefore not merely a better password-reset system.

It addresses a deeper portability question.

If a user’s identity and application relationships depend on wallet-held root keys, those roots should not necessarily become unusable because one wallet application, authentication provider or service disappears.

A standardized account format can allow another implementation to understand the same recovery material, locate the same account descriptor and reconstruct the same underlying cryptographic roots.

That makes the wallet provider replaceable while preserving more of the user’s continuity.

The proposal remains open, and documenting an existing mechanism does not by itself guarantee that independent wallets will implement it correctly or provide complete migration between services.

But it moves an important part of account recovery out of implementation-specific knowledge and into an inspectable specification.

For user-controlled infrastructure, that is a meaningful distinction:

the software providing access to an account can change without necessarily requiring the account itself to change with it.

Source: Proposed BRC-188 — User Management Protocol

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 — September 28, 2026