README
A repository for submitting, discussing, sharing, and indexing technical proposals for use across the Bitcoin ecosystem. Data models, user interfaces, script templates, encoding formats, communication protocols, and constructive critique of existing industry practice are all welcome. The goal is to provide a platform for sharing ideas without any bureaucratic overhead.
Contributing
Contributions from all builders are welcome and encouraged. To propose a new BRC, fork the repo and create a new markdown file using EXAMPLE.md as the template. The common structure is outlined below, which is a guideline to aid you rather than a strict requirement. Once your proposal is ready to share, submit a pull request so that others can review and discuss it.
To participate in discussions about existing proposals, simply open an issue and link back to the BRC file in question.
Iterative improvement
We believe in encouraging discussion and iterative improvement of proposals, resulting in incremental improvement within the bounds of the Bitcoin protocol. We welcome suggestions for improvement and are committed to working with contributors to improve proposals and ensure that they align with our guidelines.
Note that substantial revisions to standards (beyond fixing typos, adding context or wording) should go into a new standard that extends or revises the old one, so as not to disrupt existing implementations.
We look forward to your contributions and helping to create a world where transactions are seamlessly formed, and applications interact with each other with ease.
Read more about areas of interest on OpenStandards.cash
Current implementation map
The standards in this repository are vendor-neutral. Current BSV Association reference implementations include:
@bsv/sdkfor TypeScript SDK primitives, transactions, identities, overlays, storage, and the BRC-100WalletClientinterface.@bsv/wallet-toolboxfor BRC-100 wallet storage, services, signing, monitoring, and wallet implementation tooling.BSV Desktop and BSV Browser as BSV Association reference wallet/browser applications for the BRC-100 interface.
Overlay service implementations in
bsv-blockchain/overlay-services,bsv-blockchain/overlay-express, and related overlay example repositories.
Vendor distributions can implement the same standards with their own branding and hosted service defaults. Examples include Babbage's Metanet Desktop / Metanet Explorer as well as the Hudos Browser built by Matt Archbold.
Structure
The BRCs repository is organized into directories, each representing a different category of proposal. Categories may include, but are not limited to:
Transaction Templates
Bitcoin Script Templates
Communication Protocols
Each proposal should be written as a markdown file and should loosely adhere to the following:
Title: A descriptive title for the standard being defined.
Author(s): Who wrote the standard and where did it come from? How can they be reached?
Abstract: A brief description of the proposed standard or template.
Motivation: The reasoning behind the proposal and why it is needed.
Specification: A detailed technical specification of the proposal.
Implementations: Information on how the proposal has been or can be implemented.
References: Any relevant literature or external resources related to the proposal.
Note that additional relevant content, identifiers or other information may be added to the document. Documents that already existed before the repository may not follow these requirements.
Things that help depict and understand the document, such as media, may also be added in a media subdirectory where appropriate.
Refer to the Banana-Powered Bitcoin Wallet Control Protocol for a fun example template you can copy when proposing your own standards.
Interpreting the Repository
This repository contains both active interoperability specifications and historical design context.
Use the directory README files and in-spec status notes to determine which documents currently define interoperable behavior in a given area. Where a newer BRC narrows, extends, or authoritatively re-specifies behavior, implementers should follow the newer normative document rather than inferring precedence from chronology alone.
Standards
21
82
License
Everything in this repository is subject to the Open BSV License.
Terms and Conditions
Last updated