BRC-100 is a proposed standard (likely in draft status, based on the GitHub repository context) for a unified, vendor-neutral, unchanging, and open wallet-to-application interface in the Bitcoin SV (BSV) ecosystem. It defines a standardized API for communication between wallets and applications, emphasizing security, scalability, decentralization, and trustlessness. The goal is to enable seamless integration across different wallet vendors and applications, abstracting underlying implementations while supporting comprehensive functionalities like transaction management, identity handling, encryption, and digital signatures.
The document does not explicitly list authors in the available excerpts, but it is part of the Bitcoin Request for Comments (BRC) repository maintained by the bitcoin-sv organization on GitHub, which encourages community contributions.
BRC-100 outlines a wallet interface that standardizes methods and protocols for BSV wallets. It builds on foundational BRC standards to ensure secure key handling, transaction processing, and data management. Key principles include treating UTXOs as base token units (per BRC-45), using reserved protocol spaces for internal operations, and promoting vendor-neutrality to allow applications to interact with any compliant wallet without custom integrations.
The motivation is to address fragmentation in the BSV ecosystem by providing a consistent, open API that fosters interoperability. It aims to:
- Enable applications to work with wallets from any vendor.
- Enhance security and privacy through minimal exposure of sensitive data.
- Support broad functionalities while adhering to Bitcoin's original vision of peer-to-peer electronic cash.
- Leverage UTXOs for scalable, verifiable transactions without intermediaries, improving decentralization and trustlessness.
This standard draws from Bitcoin's core design, using UTXOs as discrete, transferable tokens that can be independently verified.
The specification integrates multiple BRC standards and defines a high-level API structure. Key technical details include:
-
Cryptographic Foundations:
- Blockchain: BSV.
- Elliptic Curve: secp256k1.
- Public Keys: Compressed, DER-formatted.
- Key Derivation: BKDS (likely a BSV-specific key derivation scheme).
- Security Levels, Protocol IDs, Key IDs, and Counterparties: Defined in BRC-43.
- Reserved Protocols: BRC-44 is reserved for internal wallet use, not exposed to third-party apps.
-
Transaction and Output Management:
- Labels and Tags: Transactions can have labels for categorization/filtering; outputs can have tags.
- SPV Validation: Follows BRC-67 rules.
- Transaction Representation: Uses BEEF format from BRC-62.
- UTXOs as Tokens: Per BRC-45, UTXOs are treated as base tokenization units, manageable in custom "baskets."
-
Encryption and Security Operations:
- Encryption/Decryption: Methods from BRC-2 (e.g., AES-GCM with derived symmetric keys).
- Digital Signatures: Methods from BRC-3.
- HMACs: BRC-56, using symmetric keys derived as in BRC-2.
- Digital Certificates: Structure and field encryption from BRC-52.
- Payment Internalization: Key derivation for incoming payments via BRC-29.
- Key Linkage Revelation: Methods from BRC-69, with protection per BRC-72.
-
API Methods and Structure:
- Methods are grouped into categories (e.g., Creation).
- Example Method:
createAction– Creates a new "Action" (a Bitcoin transaction with metadata, labels, and optional categorization). It can fully construct and sign the transaction or return a "signableTransaction" reference for deferred signing/processing. - Supports operations like transaction creation, signing, broadcasting, identity management, encryption, and signatures.
- Emphasizes modularity, with UTXOs enabling direct sender-to-recipient transfers.
-
Examples:
- No specific code examples in excerpts, but practical use cases include creating labeled transactions, managing UTXO baskets, and secure key revelations for audits.
The interface is designed to be future-proof, combining these elements into a robust architecture for digital wallets.
The standard prioritizes scalability through unbounded on-chain processing, decentralization via verifiable UTXOs, and security via established cryptographic protocols. It avoids reliance on second-layer solutions, aligning with BSV's focus on large blocks (e.g., gigabyte-level blocks mined in 2021).
BRC-100 builds on existing BRCs and Bitcoin protocol elements, ensuring compatibility with legacy systems. It abstracts implementations, allowing integration without disrupting current wallets or apps.
No specific code is detailed, but the BSV Wallet Toolbox (a related GitHub repo) provides tools for building BRC-100 compliant wallets, including storage and signer components. It's documented with code annotations for developers.
- Core integrations: BRC-2 (encryption), BRC-3 (signatures), BRC-29 (payment key derivation), BRC-43 (security/protocol elements), BRC-44 (internal protocols), BRC-45 (UTXOs as tokens), BRC-52 (certificates), BRC-56 (HMACs), BRC-62 (BEEF), BRC-67 (SPV), BRC-69 (key linkages), BRC-72 (linkage protection).
- Broader context: Part of the BRC repository for Bitcoin ecosystem proposals, with links to related standards like BRC-45 for tokenization.
This summary is compiled from available snippets; the full document may contain additional details.
BRC-100 embodies object-oriented programming (OOP) principles in its API design, treating the wallet as a central "object" with encapsulated state and behaviors:
- Encapsulation: Sensitive data (e.g., keys, UTXOs) is hidden behind methods like
createAction, preventing direct access and exposing only necessary interfaces. This aligns with OOP's data hiding to enhance security and modularity. - Abstraction: The interface abstracts wallet implementations, allowing applications to interact via standardized methods without knowing internal details (e.g., key derivation or signing logic). This promotes vendor-neutrality, similar to abstract classes or interfaces in OOP languages.
- Inheritance/Composition: It composes functionalities from other BRCs (e.g., reusing BRC-2 for encryption as a "composed" module), akin to inheritance or dependency injection. Methods like
createActionbuild on lower-level primitives, creating hierarchical structures. - Polymorphism: Different wallet vendors can implement the same interface methods variably (e.g., custom signing processes), but applications interact uniformly, enabling polymorphic behavior.
Overall, it encourages designing wallets as reusable, modular objects in software systems.
BRC-100 applies systems thinking by viewing the BSV ecosystem as an interconnected whole rather than isolated components:
- Holistic Interoperability: It standardizes interfaces to enable emergent behaviors, like seamless app-wallet interactions, reducing silos and fostering ecosystem-wide scalability (e.g., handling gigabyte blocks without intermediaries).
- Feedback Loops and Emergence: By integrating UTXOs as tokens and SPV validation, it creates self-verifying loops for trustlessness. Revealing key linkages (BRC-69/72) supports audit trails, allowing the system to adapt and self-correct through transparency.
- Modularity and Resilience: The standard decomposes the wallet system into reusable subsystems (e.g., encryption, signing) via referenced BRCs, making it resilient to changes—one module can evolve without breaking the whole.
- Scalability as a System Property: Emphasizes unbounded scaling and decentralization as outcomes of system design, not add-ons, aligning with systems thinking's focus on long-term dynamics and avoiding bottlenecks.
- Boundaries and Interactions: Reserves internal protocols (BRC-44) to define clear system boundaries, preventing external interference while enabling controlled interactions.
This approach treats wallets and apps as subsystems in a larger, adaptive BSV network, prioritizing sustainability and collective efficiency.