What is BRC-100?

BRC-100 is the open, vendor-neutral BSV wallet-to-application interface. It gives applications one consistent API for asking a compatible wallet to create transactions, manage outputs, derive public keys, encrypt and sign data, work with identity certificates, authenticate users, and report network information. The wallet keeps custody of keys and mediates permissions. Read the complete specification.

No. Project Babbage’s BRC-100 is an application programming interface for BSV wallets. It is not a coin, inscription format, investment, blockchain, or consensus rule. It can help apps work with UTXOs and token protocols through actions and output baskets, but it does not itself define a token.

No. There are two unrelated specifications with the same number. This page covers BRC-100 in the BSV Bitcoin Request for Comments repository: the unified wallet-to-application interface authored by Project Babbage contributors. The similarly named BTC Ordinals protocol describes an extensible token/application system. They are not compatible or interchangeable.

It means Bitcoin Request for Comments. The BSV BRC repository is an open venue for technical specifications, formats, interfaces, and architectural guidance. A BRC number identifies a document; it does not imply a token or a Bitcoin consensus change.

The specification names Ty Everett, Tone Engel, and Brayden Langley of Project Babbage as its authors. It is published in the open BSV BRCs repository, where history, discussion, and proposed clarifications can be reviewed publicly.

It is the current interoperability contract used by maintained SDKs and wallet implementations, while the BRC repository is an informal open standards process rather than a formal standards body. The repository asks substantial behavioral revisions to use new BRCs that extend or refine existing behavior. That policy is how the core interface can remain stable for applications while the ecosystem evolves.

Without a common interface, every app must integrate every wallet separately—and can become coupled to one vendor’s key storage, transaction model, or browser extension. BRC-100 separates the application from the wallet implementation. Compatible apps can make standard requests while users keep a consistent custody and permission boundary.

Depending on the wallet and app, a user can sign in without a site-specific password, approve payments, create and receive transactions, selectively prove certified identity attributes, encrypt or sign data, manage app-specific UTXOs, and carry the same wallet capabilities between compatible applications.

It should not. Private-key operations stay behind the wallet boundary. An app requests a public key, signature, encryption/decryption operation, or transaction action; the wallet applies origin and permission rules and returns only the result. An app asking users to paste seed words is operating outside this model.

It is the compressed secp256k1 public key associated with a wallet’s everyday master private key. It can identify a party and participate in counterparty-specific derivation. It should not be treated as a universal public profile or casually exposed everywhere; BRC-42 derived keys and selective disclosure provide more private patterns.

Calls carry an originator—normally the fully qualified domain name of the requesting app. The wallet can use it to scope permissions for protocols, baskets, labels, certificates, signing, encryption, and transaction actions. The app requests; the wallet decides whether the operation is allowed and whether the user must approve it.

BRC-43 gives a derived-key operation a structured context: security level + protocol ID + key ID + counterparty. Together they stop unrelated uses from accidentally sharing keys and let wallets show meaningful permissions. BRC-100 constrains names; BRC-98 reserves p  namespaces for permission modules.

An Action is a Bitcoin transaction enriched with wallet metadata such as a human-readable description and optional labels. createAction asks the wallet to fund, construct, and usually sign/process it. signAction completes one that needs app-provided unlocking data; abortAction cancels an incomplete action; listActions retrieves history and metadata.

Baskets group wallet-managed UTXOs for later retrieval and spending. Tags categorize individual outputs. Labels categorize Actions/transactions. They are wallet metadata, not new on-chain asset types. They let an app find its state without scanning everything, while permissions can scope access to each namespace.

An app commonly uses createAction for an outgoing transaction. A receiving wallet uses internalizeAction to accept an Atomic BEEF transaction and identify outputs as wallet payments or basket insertions. BRC-29 supplies authenticated payment remittance values. Use maintained SDK types and examples rather than hand-building envelopes from memory.

BRC-52 certificates bind certified fields to a subject identity key and certifier. BRC-100 lets wallets acquire, list, prove, relinquish, and discover them. proveCertificate supports revealing selected fields while proving the hidden certificate is valid—so an app can request only the attributes it needs instead of a full identity document.

BRC-100 uses BRC-67 SPV rules and BRC-62 BEEF to carry transactions with validation context. BRC-95 Atomic BEEF identifies one subject transaction plus its dependencies. These formats support compact, independently checkable data instead of requiring blind trust in a block explorer or a full-chain download.

The Wallet Wire is the binary application-to-wallet protocol defined by the BRC-100 ABI. A substrate carries those calls. Historical substrates include HTTP, cross-document messaging, and a window wallet interface; current clients also support JSON APIs and React Native bridges. The same logical interface can work across browsers, desktop apps, mobile webviews, and services.

Use WalletClient from the maintained @bsv/sdk package. Its auto substrate can discover a compatible wallet and exposes typed BRC-100 methods. Most apps should depend on the interface instead of embedding a wallet, implementing the binary ABI directly, or touching wallet storage tables.

Create WalletClient('auto') and make a lightweight call such as getVersion(). Treat “no wallet available” as a normal onboarding state: preserve the intended destination and offer a compatible wallet or device handoff. Do not assume one browser global or hard-code a vendor-specific extension.

The BRC repository identifies BSV Desktop and BSV Browser as BSV Association reference wallet applications. It also names Babbage distributions such as Metanet Desktop / Metanet Explorer, plus Hodos Browser. Capabilities vary by release, so test the methods and transports your app actually needs.

@bsv/wallet-toolbox is for building a wallet, not merely calling one. It combines the interface with storage backends, funding/signing, network services, monitoring, key management, and permissions. App developers usually start with @bsv/sdk; wallet builders and operators may need Wallet Toolbox.

No. BRC-100 is the wallet boundary. Overlays define how app state is admitted, indexed, discovered, and synchronized. BRC-103/104 define peer mutual authentication and HTTP transport. Payment, token, messaging, and app protocols define their own semantics and can use BRC-100 methods as building blocks.

The core method contract is intended to remain compatible. New behavior can arrive through reserved namespaces, optional modules, new transports, and separate BRCs. Examples include permission namespaces for protocols, baskets, and labels; balance/time query conventions; permission governance; onboarding guidance; and action-reference or output-identity metadata.

The April 24, 2026 refresh aligned the document with interoperable SDK behavior. It clarified batching/chained-send request shapes, UTF-8 byte limits, longer transaction descriptions, Byte[]/Uint8Array BEEF compatibility, a failed action status, aggregate BEEF from listOutputs, newest-first offsets, discovery permission defaults, and block-header naming.

On June 12, 2026, the standalone TypeScript SDK and Wallet Toolbox repositories were archived as permanent redirects. Active development moved to the bsv-blockchain/ts-stack monorepo under packages/sdk and packages/wallet/wallet-toolbox, alongside shared docs, quality gates, releases, and conformance assets.

Project Babbage authored BRC-100 and continues to build products, documentation, infrastructure, and implementation support around open BSV wallet standards. But the specification is vendor-neutral: Babbage does not own the right to implement it, and an app written to the interface should not need to depend on a Project Babbage wallet.

For a spec issue, open a focused issue or pull request in the BRCs repository and link the exact section. For SDK defects, use the maintained code owner—currently ts-stack for TypeScript SDK/Wallet Toolbox. For Babbage help, use the developer docs, GitHub, Slack, or contact us.