It is an interoperable economy of purpose-built wallets—each designed around a real person, a real job, and the right security model.
The category error
The better question is: what job is this wallet hired to do?
A Bitcoin wallet is not merely a balance and a send button.
It is a trust boundary around keys, value, permissions, evidence, recovery, and the workflows that make money useful. Change the job and the right boundary changes with it.
One network. Many experiences.
These may become separate products, companies, and customer relationships. What matters is that they can transact, verify, and hand off value without trapping the user.
For people buying, paying, and living
Money that fits ordinary life.
Security promise
Recoverable, bounded, and understandable
For people and businesses protecting larger balances
Safety measured in years.
Security promise
Minimal attack surface and deliberate movement
For shops turning payments into operations
A payment becomes a business record.
Security promise
Roles, limits, audit trails, and reconciliation
For people using BRC-100 applications online
Use an app without handing it your keys.
Security promise
Origin-aware and purpose-scoped authority
For creators and internet businesses earning at scale
Tiny earnings become a legible business.
Security promise
Team roles, payout policy, and financial visibility
Categories are a map, not a mandate. One product may serve more than one category. The point is to make the job, authority, risk, and user promise explicit—not to force artificial corporate boundaries.
A transaction is a handshake
The customer and the coffee shop should not need the same app. Each should get the experience, records, and assurance its own wallet was built to provide.
Customer wallet
Coffee shop wallet
The common contract
Interoperability is not visual sameness. It is a set of durable promises at the boundaries—so different wallets can meet without one becoming subordinate to the other.
People can pay, receive, and move funds without adopting the counterparty’s wallet or rebuilding their financial life.
Transactions travel with the evidence each participant needs to check validity and settlement using SPV.
Payment requests, receipts, refunds, references, and status use common enough semantics to survive a vendor boundary.
A wallet makes custody and permission decisions visible. Apps ask for capabilities instead of quietly inheriting every key.
BRC-100 can open the wallet-to-app boundary where it belongs without forcing a vault or a point-of-sale system into one user experience.
Recovery, export, transfer, and migration are normal product paths. Interoperability is incomplete if leaving is a crisis.
Security follows the job
Security is always safety for a person, against a threat, while completing a job. A control that protects a reserve vault can make a checkout unusable; a shortcut that makes checkout delightful can be reckless for a treasury.
Wallet
Protects against
Lost phones, casual theft, scams, and mistakes
Optimized posture
Fast approval, spending limits, strong device security, and humane recovery
Healthy tradeoff
Not the right place for life-changing reserves
Wallet
Protects against
Remote compromise, unilateral action, and long-horizon key loss
Optimized posture
Hardware isolation, multiple approvals, delays, and practiced recovery
Healthy tradeoff
Intentionally awkward for a coffee purchase
Wallet
Protects against
Staff error, internal misuse, charge confusion, and broken books
Optimized posture
Roles, tills, policies, reconciliation, and an operational audit trail
Healthy tradeoff
Not a customer’s personal identity wallet
Wallet
Protects against
Malicious origins, overbroad app access, and permission fatigue
Optimized posture
Origin isolation, purpose-scoped keys, clear approvals, and revocable access
Healthy tradeoff
Not an inventory or corporate treasury system
Wallet
Protects against
Opaque splits, team-access mistakes, and fragmented revenue
Optimized posture
Payout rules, business roles, counterparty records, and reporting
Healthy tradeoff
Not optimized for tap-to-pay at the register
Where BRC-100 fits
BRC-100 defines how compatible applications ask a wallet to act. An app can request a payment, signature, encryption operation, identity proof, or other capability while the wallet keeps private keys behind its permission boundary.
That makes BRC-100 an important part of the Metanet and online-app layer of this future. It does not mean a cold-storage vault, customer phone wallet, and merchant point-of-sale system must all expose the same screens—or even every same interface.
Credibility lives in the edge cases
An offline-friendly handoff clearly distinguishes an intent to pay from final verification and settlement.
The customer, merchant, and accountant can each obtain a useful record without sharing one database.
Recovery restores appropriate access without silently destroying the security promise or creating a permanent vendor hostage.
A credible migration path lets users recover, verify, and move what is theirs into another compatible system.
The path forward
The goal is not convergence on one product. It is convergence on the quality of the boundaries between great products.
A wallet should be excellent at a recognizable job before it tries to become a universal financial portal.
Compete on product experience. Cooperate on transactions, proofs, requests, receipts, recovery, and safe handoffs.
SPV should become invisible infrastructure: dependable enough for commerce and understandable when a person needs assurance.
Every payment joins systems with different needs. Both sides should get the evidence and workflow their own wallet promises.
Reliability, recovery, clear states, accessibility, support, and graceful failure will matter more than ideological purity.
What success looks like
A person chooses a phone wallet because it makes daily money easier. A shop chooses a merchant wallet because it makes the business run better. A creator chooses a treasury because it makes thousands of tiny earnings legible. They can all transact. None must share a vendor.
Questions worth answering
Probably not—and that is a sign of a maturing economy, not a failure. Daily spending, long-term custody, merchant operations, online application access, and creator revenue have different users, risks, workflows, and business models. Some products will span categories, but no single experience needs to be best at every job.
No. Interoperability means wallets can exchange value, evidence, and enough shared meaning for their users to transact safely. The products can remain radically different. A hardware vault should not imitate a point-of-sale system, and a merchant terminal should not become a personal identity manager.
BRC-100 is the open, vendor-neutral interface between compatible BSV wallets and applications. It is especially important for Metanet and online app experiences because apps can request payments, signatures, encryption, identity proofs, and other capabilities without receiving the user’s private keys. It is one important interoperability boundary, not a requirement that every wallet have one universal interface or user experience.
Simplified Payment Verification lets participants validate Bitcoin transactions using proofs and relevant blockchain headers rather than trusting one wallet provider’s private database. That makes it possible for two different wallet systems to reach useful assurance about the same transaction.
Yes. Categories describe jobs and security boundaries, not mandatory corporate boundaries. One provider may offer several coordinated products or modes. The important question is whether each job has clear authority, risk limits, records, recovery, and a credible path to move value elsewhere.
Our work on BRC-100, permissioned application access, identity, peer-to-peer protocols, and SPV-ready transaction formats is aimed at a future where wallet teams can specialize without rebuilding—or enclosing—the whole economy.