Contributed Analysis / Developer Standards & Infrastructure

BRCs have become increasingly visible across BSV Blockchain development, particularly around wallets, payments, identity, transaction proofs, overlays, application permissions, and other forms of interoperability. Yet what BRC represents can be surprisingly easy to overlook.

BRC stands for Bitcoin Request for Comments. It is an open process for proposing, discussing, and documenting technical standards used across the BSV Blockchain application ecosystem.

At first glance, that may sound much like BTC’s Bitcoin Improvement Proposals, or BIPs, or Bitcoin Cash’s Cash Improvement Proposals, or CHIPs. There is an important difference in how these systems have developed, however, and it helps explain why current BRC activity often looks quite different.

BIP, CHIP, and BRC

Bitcoin’s BIP process dates to 2011 and covers a broad range of proposals. Some concern consensus or network behavior, while others establish application-level conventions. Familiar standards in areas such as hierarchical deterministic wallets also emerged through the BIP process. Bitcoin Cash later developed the CHIP process for coordinating improvements across its own protocol and ecosystem.

Historically, however, these proposal systems have not necessarily been experienced in the same way.

For many non-developers who followed Bitcoin through its earlier years, BIPs became particularly visible during debates over Bitcoin itself: how it should scale, which rules should change, and what direction the protocol should take. BIPs were never limited to such questions, but some of the most prominent public discussions around them involved proposed changes to the base protocol. For those who followed debates around preserving the original protocol, that created a particularly strong association between technical proposals and the larger question of what Bitcoin itself should become.

BRCs became visible in a different setting on BSV Blockchain. Protocol stability was already an explicit principle, commonly expressed through the idea of the base protocol being “set in stone.” A new BRC was therefore not naturally understood as another proposal to redesign Bitcoin. The less obvious question, particularly outside the developer community, was what these proposals were actually standardizing.

The BRC repository developed with its earliest numbered specifications appearing in 2023. Its stated objective includes incremental improvement within the bounds of the Bitcoin protocol. Much of the BRC work now appearing around BSV Blockchain reflects exactly that position: rather than proposing changes to the underlying rules of the blockchain, it defines common ways for independently developed software to work on top of those rules.

BRC-100, for example, establishes an interface between applications and wallets. Other BRCs address transaction proofs, key derivation, identity, HTTP payments, overlay networks, wallet permissions, account recovery, and communication between applications and wallet infrastructure. More recent proposals have extended into areas such as spending controls for autonomous agents, wallet discovery, and recovery of an account when its original authentication provider is no longer available.

BIPs, CHIPs, and BRCs can therefore be placed in the same broad category of open technical proposal processes, but they are not simply parallel systems with different names. Their histories, scope, and the environments in which their communities encountered them have shaped different expectations around what a new proposal means.

In much of the current BRC work, development is taking place above the stable protocol: in what can be built and how independently developed systems can interoperate, rather than in changing the base transaction-validation rules themselves.

Not a Single Development Group

The growing number of BRCs can also give the impression that they are components of one centrally designed development program. They are not.

The repository is open to proposals from different developers and teams. Some names recur because related standards naturally develop around people already working in a particular architectural area. Ty Everett and contributors associated with Project Babbage, for example, have played a substantial role in wallet and application interoperability standards, while other proposals have come from independent developers and other teams.

The numbering does not indicate a technical family or level of importance either. Under the current repository process, proposals take available BRC numbers, so two neighboring numbers may describe largely unrelated technologies.

That matters when following BRC activity from outside the developer community. The number identifies a specification within the repository; it does not tell the reader whether that specification belongs to a larger technical family, how important it will become, or how widely it will eventually be implemented.

A BRC Is Not an Eternal Standard

A BRC becoming a documented proposal or standard does not make it an eternal part of BSV Blockchain.

Some BRCs may gain implementations across multiple wallets and applications and become increasingly important over time. Others may be revised, superseded as better approaches emerge, or receive limited adoption and eventually fade from practical use. That is not necessarily a weakness of the process.

The base protocol and the standards built above it occupy different positions. Stability at the protocol level does not require every application convention developed above that protocol to become permanent.

A BRC can therefore provide a common reference for developers without becoming an immutable rule of the blockchain itself. Its practical significance ultimately depends on implementation, interoperability, and continued usefulness.

This distinction is important because “set in stone” can otherwise be misunderstood as meaning that everything associated with BSV Blockchain should become fixed. The principle applies to the underlying protocol. Standards developed above it can continue to compete, improve, and sometimes disappear.

The Ordinals Naming Confusion

There is also another source of confusion around the name itself.

BTC Ordinals projects adopted names such as BRC-20 and later other BRC-numbered specifications. That naming system is separate from the Bitcoin Request for Comments repository used across BSV Blockchain development, and the two can even produce identical numbers for unrelated specifications.

A BRC-100 associated with Ordinals, for example, is not the BRC-100 wallet-to-application interface used in the BSV Blockchain ecosystem.

BRC should therefore not be understood as a generic standards layer shared by BTC, Bitcoin Cash, and BSV Blockchain. BTC primarily uses BIPs, Bitcoin Cash uses CHIPs, while the Bitcoin Request for Comments repository discussed here has developed around BSV Blockchain applications and infrastructure.

The shared acronym is a naming collision, not evidence of a common standards process.

Stable Below, Evolving Above

The more interesting part of the BRC story may be what it shows about protocol stability.

A stable base protocol does not imply that functionality above it becomes fixed. Wallet architecture can improve, payment standards can evolve, applications can gain new interfaces, and identity systems, overlays, storage mechanisms, and autonomous software can develop new capabilities. Some standards may become widely adopted, while others may eventually give way to better approaches.

None of those developments inherently requires changing the fundamental rules of the blockchain.

This separates two forms of technical evolution that are sometimes treated as the same thing: changing the infrastructure itself and developing standards for using that infrastructure.

The recent growth of BRC activity provides a practical example of the latter. The base layer can remain stable while the standards connecting wallets, applications, and services continue to develop around it, and those standards themselves do not all need to last forever.

That may ultimately be one of the more important consequences of a stable protocol. Developers do not have to choose between stability and innovation if the two occur at different layers.

A fixed protocol does not mean fixed functionality.

It can mean a stable foundation on which everything above it remains free to evolve.