Wallets & Identity

A common wallet interface solves only part of the interoperability problem.

Even if several wallets support the same BRC-100 methods, an application still needs to answer another question:

Which wallet should it connect to?

Proposed BRC-185 attempts to standardize that layer.

The draft, authored by Ty Everett and Deggen, defines a model for discovering available wallet environments, presenting them neutrally to an application or user, remembering a selection, switching between wallets safely, and connecting applications with wallets running on another device.

The proposal remains under standards and security review.

It is not yet an implemented protocol, BRC-100 itself remains unchanged, and no deployed compatibility or completed security audit is claimed.

A wallet can appear through several different paths

BRC-100 defines what an application can ask a compatible wallet to do.

That includes all 28 WalletInterface methods covering transactions, keys, encryption, certificates, signatures and related wallet functions.

But applications can encounter those wallets through very different technical environments.

One wallet may expose a local HTTP interface.

Another may inject a provider into a browser environment.

A wallet may live inside a native application.

Or the wallet may be running on a phone while the application is open on a desktop computer.

BRC-185 uses the term wallet substrate for these different connection environments.

The proposal does not try to make every wallet use one transport.

Instead, it attempts to give applications a standard way to discover which compatible substrates are available and then establish one stable wallet connection.

Discovery should not silently favor one wallet

Multiple wallet implementations create a user-choice problem.

If an application simply connects to whichever wallet happens to answer first, listen on a fixed port or register itself most aggressively, the technical discovery mechanism can effectively choose the user’s wallet for them.

The draft tries to avoid that.

It defines provider discovery across available substrates while keeping wallet selection under application or user control.

An application may use its own selection policy where appropriate, or present a neutral chooser when several wallets are available.

Once selected, that choice can be remembered for later sessions.

The goal is to make multiple-wallet environments predictable rather than turning every application into a collection of wallet-specific connection rules.

Localhost wallets also need coordination

Desktop wallet communication introduces a more mundane problem: ports.

Existing BRC wallet communication standards use local HTTP services, but multiple installed wallets can compete for the same conventional localhost address.

BRC-185 proposes ordered localhost allocation so several compatible wallet services can coexist without each vendor permanently claiming the same endpoint.

Applications can probe for available services, inspect signed descriptors describing the wallet instance and its endpoints, and then bind the application connection to the selected wallet.

The proposal makes that binding immutable for the lifetime of the connection.

Changing wallets therefore becomes an explicit operation rather than allowing a running application session to drift unexpectedly from one wallet to another.

Desktop applications could pair with a phone wallet

The proposal also addresses a more visible use case: an application running on one device while the user’s wallet remains on another.

For desktop-to-phone connections, BRC-185 defines a QR-based pairing flow.

The desktop application can display connection information that the mobile wallet scans.

After the devices establish the proposed encrypted channel, a confirmation step allows the user to verify that the two sides are participating in the same connection before wallet requests are carried across it.

The connection is intended to carry the complete BRC-100 interface.

That means the phone does not need a separate reduced protocol merely because the application is on a desktop.

From the application’s perspective, the wallet can continue providing the same standardized transaction, signing, encryption, identity and certificate functions it would provide locally.

The transport changes.

The wallet interface does not.

Same-phone applications get a different path

A second flow covers the case where both the application and wallet are on the same mobile device.

Instead of scanning a QR code from another screen, the application can open the wallet through a registered link containing the pairing request.

The wallet establishes the connection and then returns control to the originating application through a defined return link.

That creates a mobile equivalent of wallet selection without requiring every application and wallet vendor to invent a different handoff convention.

The proposal also defines lifecycle and replay protections around these mobile connections so that old pairing material cannot simply be reused as though it were a new session.

Encryption belongs to the connection, not the relay

For remote phone connections, an intermediate relay may be needed to move messages between devices that cannot directly reach one another.

The draft treats that relay as a carrier of ciphertext rather than as a trusted wallet endpoint.

The application and wallet establish the encrypted relationship, while the relay forwards encrypted records between them.

That distinction is important.

A relay may still observe metadata such as connection timing and traffic volume, but it should not need access to the BRC-100 request and response contents being transported.

The proposal includes deterministic fixtures for connection descriptors, confirmation codes and request framing to make independent implementations testable against the same format.

Those fixtures are only an early step.

The pull request explicitly states that complete interoperability testing and independent security review remain required before the design should be treated as release-ready.

Wallet choice becomes part of interoperability

BRC-100 has always been intended as a vendor-neutral interface.

In principle, an application should be able to request the same wallet capability from different conforming implementations rather than being built around one vendor’s private API.

BRC-185 tackles a layer that becomes important once that idea succeeds.

If users can genuinely have several compatible wallets, applications need a standard way to discover them.

If a wallet can live on a phone while the application runs on a desktop, they need a standard way to connect.

If users change wallets, applications need to remember preferences without locking themselves permanently to one implementation.

And if several connection technologies coexist, wallet choice should not become an accidental consequence of whichever transport happened to answer first.

The proposal keeps those concerns outside the core BRC-100 method set.

BRC-100 continues to define what the wallet can do.

Proposed BRC-185 attempts to define more consistently how an application finds the wallet the user wants to do it with.

That is still draft work, and its security model and interoperability claims remain to be tested.

But as BSV wallet implementations diversify across browsers, desktop software, mobile applications and remote services, discovery and connection are becoming infrastructure problems of their own.

Source: Proposed BRC-185 — GitHub pull request

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 26, 2026