BRC-100: A Standard Interface Between Wallets and Applications

BRC-100 in One Sentence

BRC-100 is an interface standard in the BSV ecosystem that describes how applications communicate with wallets.

If a wallet is responsible for keys, UTXOs, and signatures, and an application is responsible for business intent, then BRC-100 focuses on the bridge between them: how an application can safely and consistently tell a wallet, “I want to do this,” and how the wallet should return the result.

It is not a token protocol, nor is it an on-chain consensus rule. It sits at the interface layer between applications and wallets.

Understanding this distinction helps developers separate business logic from key control and build safer, more interoperable BSV applications.

Why Wallets and Applications Need a Standard Interface

Without a common interface, each wallet may expose a different way to interact with it:

• One wallet uses one method to create a transaction.
• Another wallet uses a different method to sign.
• Some wallets return a raw transaction.
• Some wallets only return a txid.
• Some wallets may even require the application to handle private keys directly.

This creates two obvious problems.

First, application development becomes more complex. Developers have to adapt to different wallet interfaces and repeatedly handle details such as transaction creation, signing, change, and authorization.

Second, users can become locked into a small number of wallets. If an application only supports a specific wallet, the cost of switching or choosing another wallet increases.

The purpose of interface standards such as BRC-100 is to establish a common language between applications and wallets: the application makes a request, the wallet understands it, and the wallet returns a standardized result.

Applications Should Not Manage User Private Keys Directly

An important security intuition behind BRC-100 is that applications should not directly manage users’ private keys.

An application may want a user to perform many different actions, such as:

• Making a payment.
• Publishing OP_RETURN data.
• Creating a token-related transaction.
• Signing a credential.
• Authorizing an identity operation.

The most dangerous approach is to ask users to enter their private keys or seed phrases into the application. If the application has a vulnerability, is attacked, or is maliciously modified, the user’s assets and identity may be exposed.

A more reasonable model is:

In this flow, the application expresses business intent, while the wallet retains control over the keys. The user confirms the action through the wallet, and the application receives only the transaction or signed result—not the private key itself.

What BRC-100 Mainly Covers

BRC-100 is concerned with the interaction between wallets and applications, not the on-chain transaction itself.

It addresses questions such as:

• How an application connects to a wallet.
• How an application requests transaction creation.
• How an application requests signing.
• How a wallet returns a transaction or result.
• How the user authorizes an action.
• How an application obtains available outputs or wallet capabilities.
• How a wallet satisfies application requirements without exposing private keys.

For beginners, BRC-100 can be understood as a standard interface approach for BSV applications calling wallets. It helps applications request wallet operations in a unified way, instead of requiring every project to implement wallet interaction logic from scratch.

The Relationship Between BRC-100 and WalletClient

In the BSV TypeScript SDK, you will see concepts such as WalletClient.

WalletClient reflects the same idea: applications operate through a wallet interface. The application does not need to select UTXOs from scratch, calculate change, or sign every input by itself. Instead, it sends a request to the wallet, and the wallet handles the transaction-related details.

For example, an application can ask the wallet to create an action. The wallet can be responsible for:

• Input selection.
• Output construction.
• Fees.
• Change.
• User authorization.
• Signing.
• Returning transaction-related results.

This approach lowers the barrier for beginners creating their first transaction. It also more closely matches real application architecture: the application handles business logic, while the wallet handles keys and transaction execution.

BRC-100 and Non-Custodial Applications

A BRC-100-style interface is well suited to non-custodial applications.

“Non-custodial” means the application does not hold private keys on behalf of users. The user’s wallet is responsible for signing, while the application only initiates requests and processes returned results.

This architecture has several benefits:

• The application’s security burden is reduced.
• Users retain stronger control over keys and assets.
• The wallet can manage authorization in a unified way.
• Multiple applications can reuse the same wallet.
• Interoperability between applications becomes easier.

However, this model also places demands on wallet user experience. If a wallet frequently shows pop-ups, or presents too many transaction details that users cannot easily understand, the user experience may suffer. A standard interface solves the communication problem between applications and wallets, but clear authorization screens and interaction design still need careful implementation by wallet developers.

The Relationship Between BRC-100 and On-Chain Transactions

BRC-100 itself is not an on-chain transaction format. It is only an interface convention between applications and wallets.

What is actually written to the blockchain is still a BSV transaction. A transaction contains elements such as inputs, outputs, locking scripts, unlocking scripts, fees, and signatures.

BRC-100 can help applications ask wallets to create these transactions, but it does not change the underlying transaction rules. In other words, using a BRC-100-style interface does not mean developers can ignore the BSV transaction structure entirely.

Wallet interfaces can simplify the development process, but understanding how transactions are constructed, signed, broadcast, and verified remains a foundation for building reliable BSV applications.

A Typical BRC-100-Style Interaction Flow

A BRC-100-style interaction between an application and a wallet can be understood as the following steps:

1. The user opens a BSV application.
2. The application detects or connects to a wallet.
3. The application constructs a request, such as publishing data on-chain.
4. The wallet displays the request content.
5. The user confirms it.
6. The wallet selects UTXOs, creates the transaction, and signs it.
7. The wallet returns the transaction result.
8. The application records the txid and continues handling broadcast status, confirmations, or SPV proofs.

This flow separates three responsibilities:

• User authorization is presented and confirmed by the wallet.
• Key control remains on the wallet side.
• Business logic is handled by the application.

This division of responsibilities helps applications remain non-custodial while allowing the wallet to serve as the user’s unified entry point for key management and authorization.

Why BSV Applications Need This Type of Standard

The BSV ecosystem is aimed at a wide range of data applications, micropayment applications, token applications, and enterprise applications. If every application required users to import private keys, it would be difficult for the ecosystem to develop healthy user experiences and clear security boundaries.

A standardized wallet interface can provide several practical benefits:

• Applications become easier to develop.
• Wallets can more easily support multiple applications.
• Users do not need to repeatedly expose sensitive keys across different applications.
• Permission and authorization experiences become more consistent.
• Future integration with components such as SPV, BEEF, BUMP, and Overlay becomes easier.

In this sense, BRC-100 can be viewed as one of the foundations for the BSV application ecosystem to move from “each project assembling its own wallet logic” toward a clearer division of responsibilities between wallets and applications.

Common Misunderstandings for Beginners

When learning BRC-100, it is especially important to avoid the following misunderstandings:

• BRC-100 is not a token protocol.
• BRC-100 is not an on-chain consensus rule.
• BRC-100 does not custody private keys for you.
• An application requesting wallet operations does not mean the application receives the user’s private key.
• Wallet interfaces can simplify development, but they do not replace the need to understand transaction structure.
• After a wallet returns a txid, the application still needs to handle broadcast status, confirmations, and proofs.

Summary

The core value of BRC-100 is that it provides a standardized way for BSV applications and wallets to interact.

Applications do not need to manage private keys directly, nor do they need to adapt a separate transaction and signing flow for every wallet. Wallets, in turn, can respond to payment, data publishing, signing, or authorization requests while retaining control over keys.

For developers, understanding BRC-100 helps establish the right BSV application architecture: the application expresses intent, the wallet handles authorization and signing, and the on-chain layer continues to follow BSV transaction rules.

References

• Wallet Toolbox docs: https://bsv-blockchain.github.io/wallet-toolbox/
• Wallet reference: https://bsv-blockchain.github.io/ts-sdk/reference/wallet/
• BRCs repository: https://github.com/bitcoin-sv/BRCs