Source-faithful catalog
The authoritative text stays upstream. Here, every proposal gets a stable route, its source snapshot, relationship signals, and a place in the larger stack.
Try a BRC number, a broader capability, or another domain.
We define a concise, transport-independent method by which applications can request the creation of Bitcoin transactions. We specify the use of BRC-8 transaction envelopes, and provide an open-ended and extensible approach to output stipulation by the requesting application. We define the formats for request, response and error messages exchanged between app
We devise a method for applications to request the encryption and decryption of data. Specifically, we define a mechanism for data encryption within the BRC-42 key derivation system, utilizing the BRC-43 protocol and key ID scheme. During encryption, the sender derives their own child private key and the child public key of the recipient using the BRC-42 pro
We define a mechanism for requesting and receiving digital signatures over the abstract communications channel first described by BRC-1. We rely on the BRC-43 invoice numbering and permission scheme on top of BRC-42 for key derivation, enabling the creation of private digital signatures that can only be verified by the counterparty. A signer derives their ow
We define a mechanism by which BRC-1 applications can denote UTXOs to be unlocked and redeemed by wallets as part of new Bitcoin transactions. We extend the message format defined by BRC-1 with information about the inputs requested by the application, including all information needed for a wallet to check the veracity of any inputs being redeemed.
The Bitcoin Wallet HTTP Interface is a standard interface that enables applications to connect with Bitcoin wallets to facilitate certain functionality. The interface provides a unified way for applications to request the creation of a Bitcoin transaction, encryption, digital signature creation, and other features provided by the wallet. By standardizing the
Cross-document messaging enables web-based applications to communicate with one another in a secure manner, without allowing the two applications to manipulate each other's DOM trees. It defines a mechanism by which messages can be sent and received, with browser-based attestation of the origin of each message. We define the framework and conventions for ope
The Window Wallet Communication Substrate is a standardized interface that enables seamless integration between web applications and browser embedded Bitcoin wallets. It serves as a unified gateway for applications to access various wallet functionalities, including the creation of Bitcoin transactions, encryption, digital signature creation, and more. By es
This document outlines the BRC-8 standard for Everett-style Transaction Envelopes. The standard defines the structure and format of the envelopes used to send Bitcoin transactions. The primary goal of this standard is to ensure interoperability between different Bitcoin wallet software and services, allowing them to exchange transaction data in a consistent
The BRC-9 specification defines a process for Simplified Payment Verification (SPV) that allows payment recipients to verify the validity of a transaction without downloading and verifying the entire blockchain. The process involves verifying the headers and proofs of a BRC-8 Transaction Envelope, ensuring that all SPV proofs link back to the genesis block a
This BRC serves as a reference point for the TSC Merkle Proof Standardized Format. It is identified as BRC-10 and is used to avoid ambiguity in referring to the TSC standard, just like other proposals like BRC-11 (which revise or extend this proposal) are referenced by their BRC numbers.
This is an argument for using block height as the standard for indexing block headers within merkle proofs. It argues for a backward compatible protocol extension in the short term and through deprecation, a long term reduction in the space cost of a usable local copy of block headers by a factor of two. The referenced specification, the "Spec": TSC Merkle p
This BRC specifies the format used for raw hex Bitcoin transactions, which are a widely-used way of representing Bitcoin transactions on the network. The specification includes details on the layout and various fields within Bitcoin transactions.
This document presents the technical standard for the TXO (Transaction Object) format, a structured representation of Bitcoin transactions that enables powerful queries, processes, and filters. The TXO format captures transaction data in a hierarchical structure, facilitating its storage in document databases (e.g., MongoDB) and enabling real-time filtering
Bitcoin uses scripts to control transactions, and three of the most common ways to represent a script are binary, hexadecimal, and ASM. This standard aims to provide a detailed description of these formats to facilitate their use in BSV transactions.
Bitcoin script is a programming language used in Bitcoin transactions to control the spending of coins. While the Bitcoin script opcodes are machine-readable, they are not easily human-readable. We define an assembly language that provides a human-readable format for expressing Bitcoin script opcodes, making it easier for developers to understand and write B
The Pay-to-Public-Key-Hash (P2PKH) output script is a commonly used script in the Bitcoin network that allows users to send funds to a specific Bitcoin address. This standard provides a detailed specification of the P2PKH output script, providing detail on the operations performed, and giving examples for serialized Bitcoin addresses.
The R-puzzle technique is a powerful cryptographic tool that can be used to create Bitcoin output scripts that can be unlocked by anyone who is able to solve for a value k, without revealing k to the world. The technique relies on the fact that in an ECDSA digital signature, the R component is computed by multiplying a generator point on the elliptic curve w
The OP_FALSE OP_RETURN script template is a method for storing data on the Bitcoin SV blockchain. It creates a non-spendable output and appends the desired data to the end of the script for storage. This standard aims to define the rules and best practices for using this script template.
In one view of Bitcoin, only spendable output scripts with satoshis attached constitute valid Bitcoin tokens, because Bitcoin tokens are UTXOs. Since traditional BRC-18 scripts are not compatible with this view, we propose a methodology for creating OP_RETURN scripts that are spendable and contain satoshis. This provides a way for software to automatically c
This document serves to clarify that there is no BRC-20 standard for tokenization on Bitcoin SV. While Ethereum has the ERC-20 standard for account-based tokens, there is no equivalent for UTXO-based systems such as Bitcoin SV. In order to avoid confusion and prevent people from conflating ERC-20 with BRC-20, it is necessary to clarify that BRC-20 does not e
Push TX is a technique that enables users to enforce and access transactional states and conditions within Bitcoin script using ECDSA signature messages. It allows for the enforcement of several transaction elements, such as the number of inputs, nSequence values, input and output values, and script conditions, as well as the ability to specify the script in
Defines the admission side of an overlay: which outputs belong to a topic.
We outline the Confederacy Host Interconnect Protocol (CHIP), a peer discovery mechanism for UTXO-based overlay networks. CHIP is an overlay network which tracks active network operators hosting specific topics, facilitating UTXO discovery, providing robust availability guarantees, thus enabling fault tolerance. This document specifies the format for CHIP to
Defines the query side of an overlay: how clients find outputs and related state.
We specify the Confederacy Lookup Availability Protocol (CLAP), a protocol for advertising the availability of BRC-24 lookup services on overlay network nodes. CLAP is an extension of BRC-23 that focuses on advertising the availability of lookup services instead of topics. By enabling the discovery of lookup services provided by various network operators, CL
BRC-26: Universal Hash Resolution Protocol Ty Everett (ty@projectbabbage.com) Abstract -------- This document describes the Universal Hash Resolution Protocol (UHRP), a standard framework for content availability advertisement implemented with a UTXO-based overlay network. UHRP enables content hosts to advertise the availability of a particular file by creat
The Direct Payment Protocol (DPP) is a comprehensive standard for invoice-based peer-to-peer payments on the Bitcoin SV network, encompassing the evolution of BIP70 through BIP270 and its related invoicing standards, including BIP271, BIP272, BIP273, BIP274, BIP275, and BIP282. The DPP harmonizes extensions to these standards, allowing for various payment op
We specify the widely-used protocols for exchanging payments between users of the Paymail system within the Bitcoin SV network. Paymail is a user-friendly alternative to traditional Bitcoin addresses, leveraging human-readable names at a domain, such as john.galt@gateway.cash. This standard aims to provide a clear and concise specification for wallet impleme
Relationship-derived payment addressing used across peer-payment flows.
Regular Bitcoin transactions do not contain all the data that is needed to verify that the signatures in the transactions are valid. To sign an input of a Bitcoin transaction, the signer needs to know the transaction ID, output index, output satoshis and the locking script of the input transaction. When sending a Bitcoin transaction to a node, only the previ
This specification defines Authrite, a system for the mutual authentication of two parties over a communications channel. It facilitates the exchange of BRC-52 identity certificates between users, allowing them to certify each other's identities and share identity information selectively. Authrite leverages the BRC-42 Identity Keys of MetaNet Users and relie
This technical standard describes a method for hierarchical key derivation called BIP32. Hierarchical key derivation enables the generation of a large number of public-private key pairs from a single master seed, and the ability to derive child keys from parent keys in a deterministic manner. BIP32 is a widely used standard in various fields such as wallets,
This document introduces a message box architecture and relay interface to enable data exchange between two parties using a BRC-31 authenticated server. This system allows for message exchange and forwarding between parties who might be offline or unable to establish a direct peer-to-peer connection. While the use of a server as a go-between for peer-to-peer
This document outlines the PeerServ Host Interconnect Protocol (PHIP), a peer discovery mechanism specifically designed for the PeerServ message relay system. Analogous to the scalability and resiliency enabled by BRC-23 CHIP (Confederacy Host Interconnect Protocol) for overlay networks, PHIP allows PeerServ instances to discover and connect with other activ
This document defines a layered key-value store standard for BSV systems that represent state as spendable PushDrop token outputs. It standardizes a shared lifecycle model and two interoperable profiles: Global KVStore : publicly discoverable, overlay-tracked, controller-bound KV tokens. Local KVStore : wallet-local, basket-backed KV persistence built entire
This document specifies the canonical portable format for representing a Bitcoin outpoint together with the minimum data required for interoperable validation and use. The format is intentionally narrow: it standardizes the identity of the output, its value, its optional locking script, and the transaction-validity payload required to verify the creating tra
This document defines a minimal extension to BRC-36 for associating a Bitcoin outpoint with a wallet basket and, optionally, with custom instructions whose meaning is defined by that basket. The purpose of this extension is to support interoperable wallet-managed output organization without standardizing wallet-internal classification systems or forcing a un
This specification defines a canonical, complete, portable file format for exporting Wallet Toolbox data for a single user as one blob. The format is intended to support: strong user data portability GDPR and similar access/export requirements wallet import and export storage-provider migration backup, archival, and forensic recovery This specification is ba
This specification defines the canonical encrypted wrapper for BRC-38 user wallet data exports. It standardizes a downloadable binary file format, conventionally named wallet.brc39 , for password-protected wallet export and import. The design is intended for strong user data portability, backups, archival export, GDPR-style data access, and migration between
This specification defines an interoperable synchronization protocol for user wallet data between wallet storage providers. It standardizes the chunked, resumable sync model implemented by Wallet Toolbox so independent storage backends can exchange wallet state without proprietary adapters. The protocol is incremental. A consumer requests successive sync chu
This standard describes PacketPay, a mechanism for facilitating micropayments using Bitcoin SV within HTTP requests. It relies on the BRC-29 payment protocol for processing payments, and BRC-31 Authrite for authenticating communications between the API provider and consumer. PacketPay enables secure, per-request monetization of APIs, allowing API providers t
The privacy-preserving key-derivation foundation beneath much of the stack.
Names security levels, protocols, key IDs, and counterparties consistently.
We define a set of reserved protocol namespaces that can be employed by clients utilizing the BRC-43 invoice numbering scheme to be set aside for administrative and internal use by the client software itself. This enables client software to manage its own internal state without the risk that application software will utilize the same internal protocols.
BRC-45: Definition of UTXOs as Bitcoin Tokens Ty Everett (ty@projectbabbage.com) Abstract: --------- This document proposes an examination of Unspent Transaction Outputs (UTXOs) as the central framework of tokenization in Bitcoin, justifying their usage based on their inherent simplicity, efficiency, and secure transfer processes. Through UTXOs, Bitcoin allo
Lets a wallet group and return application-relevant outputs as named baskets.
This BRC standard outlines the implementation and use of bare multi-signature (multi-sig) transaction output scripts within the Bitcoin SV digital asset ecosystem. By employing OP_MULTISIG opcodes directly, this approach offers simplicity and ease of implementation while providing enhanced security and access control for transactions. However, it also highli
This standard provides a script template that enables data-rich tokens on the Bitcoin SV blockchain, while still allowing for the representation of transfers of ownership. By pushing arbitrary data into stack elements and subsequently dropping them, followed by adding a simple P2PK lock, this script template allows for the creation of tokens with metadata, w
Addresses should have been a temporary measure for Bitcoin, whether the original Bitcoin SV or the forked off Bitcoin Core. Something that bridges the gap between the initial release and a user friendly next step. Unfortunately, for lack of any better idea they were adopted as a central feature and canonised alongside a limited set of standard scripts. Worse
To ensure a seamless process for submitting payments to a wallet, there must be a standardized method by which this process takes place. Wallets that implement this standard will be able to support the direct submission of transactions from applications to a user's wallet along with the associated SPV information as defined by BRC-9. The required message str
This document is a curated set of relevant and high level user experiences to aid as a reference for developers.
Defines selectively revealable identity certificates and revocation semantics.
We define methods for an application to request that a wallet create and prove BRC-52 identity certificates. We define a set of additional messages that extend the BRC-1 application-to-wallet messaging layer with this functionality. We specify the functionality to be performed by the wallet as part of these processes, including a standard methodology for wal
The core DPP (Direct Payment Protocol) has been defined by BRC-27, but it is non-functional without at least one mode to facilitate payments. We extend the core DPP by introducing the Hybrid Payment Mode. This flexible and open-ended payment mode facilitates payments with BSV as well as various token types, such as loyalty points and stable coins. The Hybrid
BRC-27 defines an abstract messaging protocol that facilitates payments on the Bitcoin SV network. This specification extends the protocol with the specifics required for a concrete HTTPS implementation that includes message size limits and HTTPS-specific implementation details.
The importance of a standard interface by which Bitcoin applications can communicate with wallets and underlying infrastructure cannot be overstated. We propose an identity interface facilitating the creation of Bitcoin transactions, the use of user-held keys for encryption and digital signatures, and the employment of identity certificates to authenticate u
The mAPI specifications have gained a certain level of traction in the Bitcoin SV ecosystem over the preceding years, while also attracting their fair share of controversy and criticism. Certain mAPI use-cases, such as those that facilitate one-on-one relationships between miners and individual customers, are not in keeping with Section 5 of the Bitcoin whit
We present a data model and JSON format for a Merkle Path which will be passed from a Transaction Lookup service to a Lite Client via web API.
Various methods exist for keeping track of systems that derive their state from the Bitcoin network. Some architectures require all parties to have awareness of all transactions to prevent divergence in their computed view of the state. This leads to the need for trust in centralized indexing systems, as it is not feasible for end-users to be aware of all tr
BRC-60: Simplifying State Machine Event Chains in Bitcoin: An Emphasis on Hash Chains over Dependent Transactions Ty Everett (ty@projectbabbage.com) Abstract -------- This document explores an alternative approach to managing long chains of events on Bitcoin's blockchain: using a single non-final transaction coupled with a hash chain, rather than creating le
We propose a binary format for Compound Merkle Paths (CMP hereon) optimized for minimal data bandwidth during transmission.
The core proof-carrying transaction container used by current implementations.
The Genealogical Identity Protocol (GIP) represents an innovative leap in identity verification within the Bitcoin ecosystem. Merging genealogical data in GEDCOM files with advanced cryptographic techniques, the GIP creates an immutable and secure identity system. This aligns seamlessly with Dan Roble's Innovation Bank proposal and integrates with global ide
This document proposes a solution for tracking transaction histories within UTXO-based overlay networks by extending the BRC-22 submission result model to identify which spent topical coins should be retained for history and by extending BRC-24 lookup behavior to return BEEF that preserves source-transaction ancestry. This allows clients to traverse the life
BRC-65 extends the functionality of BRC-56 by introducing the ability to label Bitcoin transactions when they are created using the BRC-1 Transaction Creation Request. This extension allows applications to organize and categorize transactions for different purposes. BRC-65 also introduces the capability to list labeled transactions, providing applications wi
This BRC extends BRC-56 by adding the ability to remove specific outputs from a basket and delete digital certificates that are no longer required. Applications can request that a wallet remove outputs from a basket by providing the transaction ID ( txid ) and the output index ( vout ) along with the name of the basket. Certificates can be deleted by specify
Defining Simplified Payment Verification (SPV) without external reference for sake of clarity.
This document outlines a protocol that allows an entity to publish trust anchor details, including a public key, at a location on the internet. The information is stored in the /manifest.json file of the domain under the metanet.trust key. This approach provides a user-friendly method for individuals to easily retrieve a trusted entity's public key by enteri
This BRC proposes two methods for revealing key linkages under the BRC-42 key derivation scheme and BRC-43. One method reveals the root BRC-42 shared secret between two counterparties, allowing anyone to link all interactions between them. The other method reveal only a specific link (the key offset value) between a root identity key and one of its child pub
We specify a paymail capability extension which supports the passing of BEEF Transactions between hosts. The procedure for service discovery and requesting outputs is not detailed, rather this proposal contains only a recommendation to replace BRC-12 RawTx hex data with BRC-62 BEEF hex data.
We propose a binary format for a Single Merkle Path optimized for storage in a key value database.
This BRC outlines additional security measures for the protection and controlled revelation of key linkage information as defined in BRC-69. This standard describes an approach for encrypting this sensitive data during communication, according to BRC-2. The intent is to ensure that only approved parties are capable of decrypting and accessing this informatio
This specification defines the manifest declaration format for grouped wallet permissions. It allows an application to declare, in one place, the protocol access, spending authorization, basket access, and certificate disclosure capabilities it expects to request from the user. The current interoperable manifest namespace is metanet.groupPermissions . Wallet
We propose the BSV Unified Merkle Path format in both binary and JSON encoding optimized for generation by transaction processors, and also happens to be convenient for proof validating clients. At a high level the format encodes a number of txids which all exist within one particular block, along with each of their merkle paths and the blockHeight. The bloc
This is a simple extension of the widely used BIP39 Mnemonic seed phrase scheme where 12 to 24 words are used to encode entropy which is then used to derive an extended private key for use with the BRC-32 derivation scheme. This document proposes a way to encode a single private key as a mnemonic phrase which people have become accustomed to.
GASP is designed to synchronize transaction data between two parties in a blockchain environment. It ensures the legitimacy and completeness of transaction data using a recursive reconciliation method.
This document defines a protocol for creating and verifying digital message signatures in the Bitcoin ecosystem. It leverages the BRC-42 key derivation and BRC-43 invoice numbers to facilitate privately-verifiable signatures, increasing security and privacy in Bitcoin message interactions.
This document describes a protocol for a portable message encryption and description scheme. It follows the BRC-42 key derivation and BRC-43 invoice number standards to protect the confidentiality of message content, without requiring the added complexity of agreeing on a specific BRC-43 protocol for the parties to use.
We propose a peer-to-peer token exchange protocol under which two parties can securely exchange digital tokens (assets) within Bitcoin SV's BRC-22 UTXO-based Overlay Networks.
MLD (Multicast Listener Discovery) for IPv6 provides a way for a host to indicate to an upstream router that it is interested in receiving multicast traffic from a particular group. While this is useful in some cases (such as when miners in Bitcoin want to propagate blocks and subtrees to one another efficiently), it does not solve every use-case. This docum
In BRC-22 overlay networks, various forms of state tracking for UTXOs can be incorporated. Servers can track UTXOs according to many criteria, enabling many use-cases. There is no fundamental requirement that a server relies on strictly on-chain data for these operations. In this document, we explore the use of off-chain secrets and offset values, enabling p
This document builds upon the insights of BRC-80 and proposes a scalable, efficient IPv6 multicast protocol specifically designed for the broadcast of blockchain transactions and the delivery of transaction status updates, such as merkle proofs and double-spend attempt notifications. Recognizing the limitations of existing IPv6 multicast protocols, including
The BSV network is designed to process transactions at scale, leveraging a robust, distributed system of miners, validators, and aggregators. This system balances parallel processing with sequential validation, ensuring transactions are both processed rapidly and recorded in the correct order. Below, we document the detailed processes by which BSV miners wil
The Linked Key Derivation Scheme builds on and extends the "type 42" key derivation method. This scheme allows public key derivation using only the public keys of both parties, maintaining the flexibility and unlimited key derivation of type 42. It aims to enable non-custodial wallets to derive public keys from a master public key without private key access,
Allowing humans to securely exchange public keys using web apis and an off channel sharing of TOTPs.
Sometimes, there's a need for a third party to validate the linkage and key derivation process between two transacting parties. Type-42 derivation enables the private use of child keys between the parties based on an invoice number, but doesn't allow for third-party servers to verify the linkage of the keys. Proposals like BRC-84 describe ways to enable thir
This document proposes standardized naming conventions for topic managers in BRC-22 and lookup services in BRC-24 to ensure clarity, interoperability, and uniformity across different implementations. The goal is to provide consistent and easily understandable names that facilitate efficient communication and integration between overlay network nodes and serv
This document outlines the Overlay Services Synchronization Architecture, detailing the Services Host Interconnect Protocol (SHIP) and Services Lookup Availability Protocol (SLAP). These protocols enable efficient peer discovery and data synchronization across UTXO-based overlay networks. This BRC defines the components, interactions, and responsibilities of
This BRC proposes a high-level, rough-draft standard for Web 3.0, defining the integration of blockchain technology, federated overlay networks, digital wallets, and enhanced browser functionalities to enable a decentralized and serverless web experience. This evolves the current web standards to facilitate content and applications that are fully powered by
BRC-90: Thoughts on the Mandala Network Ty Everett (ty@projectbabbage.com) In the Mandala Network, there are three primary layers: the Transaction Processors at the core, the Overlay Services in the middle, and the Transacting Parties at the edges. Each of these layers can be further subdivided, as will be explored later. Transaction Processors create blocks
The Mandala Network's architecture, with its three primary layers — Transaction Processors, Overlay Services, and Transacting Parties — forms a robust framework for managing blockchain transactions. Building upon this foundation, we delve deeper into the concepts of outputs, overlays, and scripts, exploring how they interact within the network to enable a mo
Minimalist protocol for tokenization, issuance, transfer, recovery, and redemption.
This BRC identifies and summarizes the key limitations of BRC-69 key linkage revelation. The primary issues are centered around the inability of verifiers to independently verify the accuracy and correctness of the revealed key linkage information without access to private keys. Specifically, in Method 1 , there is no way for the verifier to confirm the shar
This BRC presents a solution to the limitations identified in BRC-93 concerning Method 1 of BRC-69 key linkage revelation. The proposed method utilizes a Schnorr-based zero-knowledge proof (ZKP) scheme to enable provers to reveal a shared secret between their identity key and a counterparty's key while allowing verifiers to independently confirm its validity
Adds a single subject transaction to a BEEF package for portable verification.
The BEEF serialization format (as defined in BRC-62) is essentially two things: An array of mined transaction proof validation data (BUMPS BRC-74) An array serialized Bitcoin transactions In practical use, BEEFs are exchanged between parties to build and process new transactions as well as validate arbitrary data recorded on the blockchain. The extension pro
This BRC proposes an extensible format for including zero-knowledge proofs (ZKPs) in specific key linkage revelations as per BRC-69 Method 2. While BRC-94 addresses limitations of BRC-69 Method 1 through a Schnorr-based ZKP, there is currently no standardized method for provable specific key linkage claims in Method 2. Given the rapid evolution of ZKP techno
The BRC-43 architecture for wallet protocol permissions enables a wide range of use cases. By reserving protocol identifiers and preventing their use by applications, we ensure compatibility with future standards, supporting the future development of new protocol permission schemes.
The BRC-46 architecture for digital assets stored within wallet baskets enables a wide range of use cases. However, it lacks support for more than a rudimentary permission system. Wallets can grant applications blanket access to basketed assets, or deny access entirely, but cannot make insightful decisions based on the specific assets stored, their output sc
The central application-to-wallet boundary. Start here for most Metanet apps.
Status This document is currently aspirational rather than descriptive of the interoperable behavior implemented by bsv-blockchain/ts-sdk . Current resolver and broadcaster implementations: expect concrete host base URLs in SHIP and SLAP advertisements, use https: in production, allow plain http: only for the SDK's local preset, and do not currently negotiat
We define a comprehensive and authoritative specification of the deployment-info.json schema. It is intended to serve as a reference for developers building BSV blockchain applications that integrate with the LARS (Local Automated Runtime System) and CARS (Cloud Automated Runtime System) tooling and beyond. By following this specification, projects can ensur
The current peer mutual-authentication and certificate-exchange protocol.
Binds BRC-103 peer authentication to HTTP transport.
Abstract This document specifies an HTTP-based micropayment framework that extends BRC-103 (mutual authentication and certificate exchange) and BRC-104 (HTTP transport for BRC-103). It defines how a server can advertise payment requirements for a given HTTP request and how a client can respond with a BSV transaction fulfilling these requirements. By leveragi
This proposal introduces a standardised method of dealing with the ASM representation of Bitcoin Script across the ecosystem language libraries (Py-SDK, TS-SDK, Go-SDK, Teranode etc).
This proposal extends BRC-92 (Mandala Token Protocol) with cryptographic commitments to provide tamper-evident token amounts and SPV-friendly verification while maintaining the minimalist design philosophy. The enhancement adds a commitment hash to each token output that cryptographically binds the token amount to its transaction history, enabling lightweigh
This proposal extends the Enhanced Mandala Token Protocol (BRC-107) with identity certificate integration based on BRC-52/53. It enables tokens to enforce real-world compliance requirements, KYC/AML regulations, and identity-based access controls while preserving privacy through selective field revelation. The protocol supports regulated security tokens, acc
This work specifies a Bitcoin wallet workflow that conducts direct IP-to-IP negotiation between two identified parties and settles a payment as many independent on-chain transactions (“notes”). Identity keys are used only for ECDH and message authentication; they never appear on-chain. For each invoice and note index, a shared secret and an invoice fingerpri
A zero-friction onboarding protocol optimized for mobile-first metanet enabled user experiences. Temporary key generation enables instant access without sign-up; standardized UI components facilitate seamless export of keys and cross-app communication while preserving usability across devices. Secondly it mandates clear contextual communication of the benefi
The BRC-65 and BRC-100 label system enables applications to organize and query actions. However, labels are also used in permission checks (e.g. for listActions ), which limits extensibility for module-defined labeling and querying schemes. This proposal reserves a label prefix to allow wallets to delegate label permissioning and label-specific behavior to i
This specification defines a backwards-compatible extension to BRC-100 that allows applications to query a basket's balance using a balance prefix in listOutputs . The wallet returns no outputs and re-purposes totalOutputs to report the sum of satoshis contained in all outputs in the specified basket.
Merkle Proof Token Feb 4, 2026 Introduction by Metro Gnome The simple idea There needs to be a token that lives within the native Bitcoin architecture, enabling all the advantages SPV, while removing all the overhead of managing the token itself. Every token set begins with a genesis mint transaction. Once mined into a block, this becomes the immutable ancho
This specification defines a backwards-compatible extension to BRC-100 that allows applications to filter listActions results by wallet-tracked action timestamps using reserved query labels. The response format remains unchanged.
BRC-115 defines a deterministic, SPV-verifiable framework for identity-linked token transfers on Bitcoin SV. It specifies how wallets verify compliance requirements using BRC-0042 key derivation, BRC-0107 commitments, and BRC-0108 identity bindings — without relying on overlay networks or external validators. This standard ensures identity-restricted token t
This document fully specifies how BRC-100 wallets handle application permission requests. Its goals are to: Define, without ambiguity, how permissions are declared, requested, and evaluated Specify full permission lifecycle behavior: grant, deny, renew, revoke, and persistence Distinguish group permissions from counterparty trust (PACT) and define how both a
This BRC defines a mechanism for minting BSV-21 tokens via Proof-of-Work where the hash preimage includes an indexing work commitment — a merkle root of verifiable overlay network activity. The token supply is locked in an sCrypt smart contract at deployment. The contract verifies the PoW solution on-chain and permanently records the work commitment, while a
Abstract This document specifies an alternative transport mechanism for the x-bsv-payment data defined in BRC-105. When a payment transaction encoded in BEEF or Atomic BEEF format exceeds practical HTTP header size limits, the client transmits the payment as a named part within a multipart/form-data request body instead of an HTTP header value. The existing
We define the SubTree Unified Merkle Path (STUMP) format for encoding merkle paths within a subtree of a block, rather than across an entire block. A STUMP adapts the binary encoding specified in BRC-74 (BSV Unified Merkle Path / BUMP) for subtree scope, replacing the block height with a single-byte tree height header and an optional trailing block hash. The
This standard assigns a Bitcoin Request for Comments (BRC) designation to the x402 stateless settlement-gated HTTP protocol so that it can be indexed, cited, and implemented under a stable identifier ( BRC-120 ). It defines BRC-120 compliance : implementations that claim this designation MUST satisfy the frozen x402 version 1.0 specification maintained in th
This BRC specifies a lightweight protocol for monetizing HTTP resources using the 402 Payment Required status code and a set of custom HTTP headers. A server advertises a price and its identity key in the 402 response. A client constructs a BRC-29 payment transaction, encodes it in BRC-95 BEEF format, and retransmits the original request with payment headers
This document specifies the Auditable Real-time Inference Architecture (ARIA) protocol, a BSV application-layer standard for cryptographic accountability of AI inference systems operating in production. ARIA enables independent, post-hoc verification of which AI model produced which output at what time — without requiring access to the operator's systems or
We define a governance framework for BRC-99 basket permission schemes. BRC-99 reserves basket identifiers beginning with p for future permission schemes and establishes the format p , but defines no process for registering scheme IDs, no taxonomy for classifying schemes, and no consolidated reference for the basket name reservations scattered across multiple
This BRC specifies the wire format for transporting BSV transactions over IPv6 multicast and TCP/UDP unicast. The format extends the legacy BRC-12 frame with additional fields for flow identification, sequence tracking, and subtree identification. All fields are 8-byte aligned for efficient memory access on 64-bit architectures. The frame is transport-agnost
This BRC defines the peerpay URI scheme, a compact, human-shareable encoding for initiating a BRC-29 peer-to-peer payment. The URI encodes the recipient's identity key (a DER-encoded compressed secp256k1 public key) and an optional satoshi amount, enabling wallets, QR codes, NFC tags, and clickable links to trigger BRC-29 payments without requiring a Paymail
This BRC specifies the NACK-based retransmission and endpoint discovery protocol for the BSV multicast transaction distribution pipeline. It defines five UDP datagram formats — ADVERT, NACK, MISS, ACK, and THROTTLED — along with tier/preference-based endpoint selection, an escalation state machine, and configurable retransmit modes. The protocol operates on
This BRC specifies a periodic multicast announcement protocol that maps BRC-124 SubtreeID values to stable 128-bit group identifiers. Senders broadcast compact 64-byte datagrams on a reserved control-plane multicast group, allowing listeners to dynamically learn which subtree IDs belong to which groups and filter incoming transaction traffic accordingly — wi
This BRC specifies a payload variant for the BRC-124 multicast frame format in which the transaction payload uses the BRC-30 Extended Format (EF) instead of the BRC-12 raw transaction format. The 92-byte BRC-124 header is unchanged; the payload is self-identifying via the BRC-30 EF marker. This enables multicast receivers and broadcast services to fully vali
This BRC specifies the IPv6 multicast group address scheme for the BSV transaction sharding pipeline. It defines how the 16-bit shard index space is allocated across data-plane shard groups and control-plane service groups, how addresses are derived from the IANA Bitcoin multicast allocation, and the canonical addresses for beacon discovery, subtree announce
This BRC specifies a fragmentation extension to the BRC-124 Multicast Transaction Frame Format. When a BSV transaction payload exceeds the path MTU available on a multicast fabric, the proxy decomposes the payload into a sequence of fixed-size fragment datagrams. Listeners reassemble the fragments and verify the reconstructed payload against the transaction
This BRC specifies the wire format for distributing block-level metadata over the IPv6 multicast fabric. A new frame version ( 0x04 ) reuses the BRC-124 92-byte header layout and carries either a block announcement (block header + coinbase TxID + subtree hashes) or a coinbase transaction, delivered to all subscribers via a dedicated control-plane multicast g
This BRC defines frame version 0x05 for distributing complete Merkle subtree contents — transaction hashes and optional per-transaction metadata — over the IPv6 multicast fabric. Subtree data frames are delivered to all subscribers via the dedicated GroupSubtreeDataAnnounce multicast group ( FF0X::B:FFFB ), independently of the per-shard groups used for indi
This BRC defines the policy and wire mechanism for distributing coinbase transactions over the IPv6 multicast fabric. Coinbase transactions are carried as a dedicated message type within BRC-131 block control frames and delivered to all subscribers via the control-plane multicast group, independently of the shard groups used for ordinary transaction distribu
This BRC defines a new frame version ( 0x06 ) for distributing chained anchor transactions over the IPv6 multicast fabric. An anchor transaction is the root (first) transaction in a chain of dependent transactions. Because all subsequent transactions in the chain reference the anchor as an input, every subscriber must receive it regardless of which shard its
This BRC specifies a lightweight wire format for distributing standalone 80-byte BSV block headers over IPv6 multicast and unicast transport. BRC-135 frames are produced by splitting the block header from a BRC-131 BlockAnnounce payload and wrapping it in a minimal 172-byte frame. The format reuses the 92-byte BRC-124 header layout, ensuring compatibility wi
Adds block-anchored comparison points for overlay topic completeness.
This document specifies a standardized sign-in experience for applications built on the BRC-100 wallet-to-application interface. It defines how an application SHOULD greet an arriving user with a single, coherent login surface organized into four named buckets — Magic Link , Social Login , Web3 Login (multi-chain wallets via WalletConnect plus BSV wallets su
This standard defines a lightweight mechanism for a server to authenticate that a request was made by the holder of a wallet identity key — login being the most common example, but any action applies — in a single request, without a prior challenge round-trip and without a full mutual-authentication session. The verifier first makes its identity public key a
This BRC specifies the shard manifest announcement protocol for the BSV multicast transaction distribution pipeline. It defines a single UDP datagram format — ShardManifest ( MsgType 0x40 ) — by which any participant periodically declares its shard_bits configuration and the set of shard groups it has joined. Manifests are emitted directly to the control-pla
This standard defines a method for splitting a secp256k1 private key into m shares such that any n of those shares (where 2 ≤ n ≤ m ) can reconstruct the original key, while any fewer than n shares reveal nothing about it. The scheme is an application of Shamir's Secret Sharing over the secp256k1 prime field, augmented with a cryptographically secure, non-de
This standard defines a payload-agnostic, one-directional optical transport that carries an arbitrary byte string across an air gap as a sequence of QR codes. Each QR decodes to a single US-ASCII string beginning with the fixed prefix air-gap: , followed by unpadded URL-safe base64 of a versioned binary header and one fixed-size block. Parts are produced by
This BRC specifies a coalescing extension to the BRC-124 and BRC-128 Multicast Transaction Frame Formats. A _bundle_ packs many small BSV transactions — standard (BRC-12 raw) or Extended Format (BRC-30 EF) — that share one shard group and subtree into a single datagram, so a payload that would otherwise cross a multicast fabric as N small packets crosses it
This BRC specifies the push wire form of a subtree — an ordered list of transaction node hashes plus the merkle root that identifies it — for delivery and ingest over a byte stream. A subtree names its member transactions by hash; a receiver reconstructs the subtree and verifies it against the carried root. All frame integers are fixed-width big-endian; ther
This BRC specifies the push wire form of a block — the 80-byte block header, block-level counts, the ordered list of subtree roots the block references, the full coinbase transaction, the block height, and the coinbase merkle path — for delivery and ingest over a byte stream. It carries everything a receiver needs to assemble and validate the block without a
This BRC specifies a registry-free typed content anchor : a deterministic scheme for committing to typed content with a single 32-byte anchor and no central registry. An anchor is SHA-256(INKAN_DOMAIN u8(len(kind)) kind data) : a fixed domain string separates these digests from every other SHA-256 usage, a one-byte length prefix makes the kind / data boundar
Profiles 1Sat assets for standard output baskets and wallet interaction.
This BRC extends the IPv6 multicast group address scheme of BRC-129 by partitioning the 16-bit shard-index space into independent object planes , each identified by a 4-bit domain selector in the high nibble of the index. The existing transaction plane (raw and Extended Format transactions) is retained unchanged as domain 0x0 ; a new BEEF object plane is all
This BRC specifies the three wire forms of the BRC-148 BEEF object plane: the multicast object frame (FrameVer 0x09 , assigned here), which carries one BEEF-family transaction object on the plane's domain-tagged shard groups; the submission record , the unicast envelope a publisher sends to operator ingress naming one object to one or more overlay topics; an
This BRC defines the provenance remittance carried in BRC-37 customInstructions for outputs in the companion basket profile 1sat (BRC-147). It specifies an offline-verifiable package that binds a current 1-sat outpoint ( tip ) to a 1Sat Ordinals origin (BRC-159), using BEEF (or AtomicBEEF when it still covers the hop), BRC-159 sat ordering on every path hop
1. Concentration of Financial, Identity and Application Power BRC-100 does far more than standardize the sending of payments. Its interface encompasses transaction creation, transaction and output listing, output baskets, master and derived public keys, encryption, signatures, identity certificates, identity discovery and two forms of key-linkage revelation.
Purpose of This Paper BRC-100 applications may eventually support ordinary BSV, tokens, identity certificates, social activity, AI-agent payments and regulated financial assets inside one interoperable wallet environment. That versatility creates a problem developers may overlook: an application can cautiously avoid requesting a user’s root identity key or i
This specification defines a backwards-compatible extension to BRC-100 that exposes each action’s wallet reference as a synthetic label on listActions results. No new request or response fields are introduced, and the label is not persisted as ordinary action metadata.
This BRC defines an HTTP backup service profile for optional recovery of BRC-140 key shares. A backup service stores at most one BRC-140 share per authenticated account and releases it only after authentication. Wallets may enroll a list of independent service URLs, deposit distinct shares across them under a threshold scheme, and reconstruct the key locally
This standard specifies how a wallet discovers unsolicited incoming payments to addresses it has previously handed out, without cooperation from the sender and without scanning an unbounded derivation space. It defines a tracked list of explicitly handed-out receive addresses, a discovery procedure that internalizes each new deposit exactly once (SPV verific
Withdrawal notice This standard has been withdrawn and its normative content removed. It defined an optional latched transfer profile (v3 provenance, O(1) verification) for 1Sat Ordinals tips held in basket 1sat . The author withdrew it because HandCash is not shipping the hardened Commit/Settle path that made the profile distinct; soft-latch tip naming alon
This standard defines a unified backup and recovery scheme in which entropy — not a private key and not a mnemonic phrase — is the fundamental object being backed up. A 32-byte entropy value is represented as a secp256k1 private key so that it can be split into BRC-140 backup shares, and simultaneously encoded as a BIP-39 mnemonic sentence so that it can be
Scopes a BEEF proof package to one transaction output.
Defines a 1-satoshi token’s stable origin and transfer rule.
Defines the inscription envelope carried by 1Sat assets.
This document specifies the legacy JSON wire encoding of BSV-21 fungible tokens: an ord inscription with content type application/bsv-20 . Token balances live in UTXOs. Each token is identified by the outpoint of its deploy output. Two supply models are supported: Fixed supply — the entire supply is created in one deploy output. Auth (authority) — deploy cre
BSV-21 (binary) is a fungible token protocol for Bitcoin SV. Balances live in UTXOs. Each token is identified by the outpoint of its deploy output. Token data is a fixed script prefix of data pushes — readable and constructible in Bitcoin script without parsing JSON. Two supply models: Fixed supply — the entire supply is created in one deploy output. Authori
This BRC defines the application basket profile for BRC-161 BSV-21 fungible value outputs under BRC-46 / BRC-100. It reserves the basket name bsv21 , specifies eligibility, documents tags for listOutputs filters, BRC-37 customInstructions for load-bearing token fields and derivation , and describes normative hold / list / transfer / import flows. It does not
This specification defines a tag convention for BRC-100: an output tag prefix id: that carries a stable list key for a held output. Callers use it with ordinary listOutputs tag filters. It does not change the BRC-100 request or response shape, and it does not require special wallet storage behavior beyond normal tags.
This BRC defines the P1Sat basket permission scheme for BRC-100 wallets: scheme id 1sat under BRC-99 / BRC-116. Storage of collectables remains the plain basket 1sat (BRC-147). Applications request view access with a BRC-99 basket p 1sat (scope names the permission axis ; filter values ride ordinary tags ). Applications request spend authorization by labelin
Abstract This document specifies an ecosystem-independent, publicly-verifiable profile for HTTP 402 Payment Required settlement on BSV, using plain P2PKH payments to a per-invoice address . Two properties distinguish it from the other BSV 402 specifications: No client wallet ecosystem is required. A payer needs only the ability to construct, sign and hex-enc
This document defines the Chunked, Hashed, Interleaved Resolution Protocol (CHIRP), an immutable Merkle-object layer above the Universal Hash Resolution Protocol (UHRP) defined by BRC-26. UHRP identifies and discovers a single byte string by its SHA-256 hash. CHIRP identifies an ordered byte stream by a small root node that commits to hashed data chunks and,
This document specifies time allocation records : a per-week, chain-anchored commitment by a BRC-169 handle to how its holder spent the 168 hours of that week, together with a disclosure mechanism that reveals chosen hours to chosen handles and nothing to anybody else. A week holds 168 hours and no more. That bound is the whole contribution. An invoice can c
This document specifies a universal addressing scheme for the Metanet, in which every person, organisation, machine, and agent is reachable by a human-readable handle of the form @handle@ecosystem , regardless of which wallet ecosystem they belong to. Name collisions are avoided without any central registry through domain separation. Every ecosystem is an in
This document specifies the Locked Content Header (LCH), a BSV-native container and licensing protocol for encrypted digital content. An LCH package identifies encrypted bytes, their media type and encryption method, the original rights holders, one or more ways to acquire licensed use, and the evidence needed to enforce or later demonstrate the resulting ag
This standard defines how a covenant carries mutable state inside its own locking script, as a run of fixed-width data pushes, such that the state can be located, read and rewritten at constant byte offsets — by the covenant itself, and by any third party holding only the script. The layout is self-describing : for every field, the single-byte push opcode th
An agent that spends on Bitcoin is normally given a wallet, which is to say a key — and a key is unbounded capability: it signs anything, for whoever holds it. Funding it lightly bounds the amount at risk without bounding the behaviour. This standard defines a battery : a covenant that carries its own fuel, pays each step's fee from the value it already hold
Bitcoin Script is a stack machine with no names, no types and no structure a reader can hold. It is also, almost exactly, the machine that sits underneath every infix expression evaluator written for an 8-bit microcomputer: v = v + f/m - v d becomes the same sequence of stack operations in either. This standard defines Bitcoin BASIC , a BASIC dialect in one-
Uniqueness is not free on Bitcoin: script validates transactions, not protocol semantics, so nothing inherently stops two parties from each broadcasting a valid claim to the same name. This document specifies resolution for names whose uniqueness is instead settled in script , where a duplicate claim is an invalid transaction rather than a dispute to be arbi
This BRC defines an offline-verifiable packet that proves one or more transaction outputs are valid BRC-161 / BRC-162 BSV-21 tokens. The packet is a BRC-62 BEEF. Delivery is transaction-level (BRC-95 Atomic BEEF encoding) when proving outputs of one transaction, or BRC-158 Outpoint BEEF when proving a single outpoint. Completeness and validation are this pro
This specification defines the BRC-111 module label p nosend expiry , which asks a supporting wallet to create a BRC-100 noSend action that can be revoked after a deadline. The wallet first broadcasts a funding transaction containing one dedicated wallet-controlled output. The protected noSend action spends that output, but the wallet never broadcasts the pr
This document describes access gates : conditions attached to a room, evaluated by a client against verifiable facts about a reader, that decide whether the room's contents are rendered to them. Five gate types are described — holding , vouch , renounce , quorum and timelock — together with a ban , which appears in no manifest and applies to every room, an o
This document specifies scores : inscribed, immutable rules from which a collectible's appearance is derived rather than stored, so that the same object is a different object at a different block height and in different hands. Derivation is the chain's own primitive and this document adds nothing to it. A public key is derived from a private key, an address
This document specifies a slash-command grammar for conversational Metanet clients, and a global set of command verbs that MUST behave identically in every conforming client regardless of ecosystem. Commands are the chat-native surface over the addressing, payment, messaging, reachability, and delegation mechanics of BRC-169. /pay @brandon@handcash $2.18 per
This BRC defines the liveness contract for wallet requests that require user permission. When an application sends a valid wallet request and the wallet requires user consent before responding, the request is allowed to remain pending until the user grants or denies the request. Application developers should treat such pending requests as normal wallet behav
This proposal defines a transaction format and a self-contained certificate for anchoring a signed hash to the Bitcoin blockchain. A signer proves they signed a specific hash; the on-chain anchor fixes that proof in time at the block in which it is mined. The notarizing service never receives the original document and never handles any client private key. Ce
Block Media Format (BMF) is an open format for composable, on-chain-native audio/video . Instead of one monolithic encoded file, a "video" is expressed as a small timing manifest that references independently-owned media components — each of which can be minted once on-chain, provenanced, and reused many times. BMF defines two file types: .bmf (the manifest
TKQR1 is a text framing that carries an arbitrary byte string across an optical air gap as a sequence of QR codes ("animated QR"), then reassembles it on the far side with integrity and set-consistency checks. Each frame is a single line of US-ASCII: a fixed prefix, a 64-bit truncated SHA-256 tag of the whole payload, a zero-based sequence number, a frame to
This BRC specifies a class of self-replicating covenant tokens whose spending rules are enforced by miners at consensus, not by any platform. Using OP_PUSH_TX transaction introspection, each token's locking script forces the transaction that spends it to (a) re-create the token for its new holder and (b) pay fixed royalty/creator outputs to immutable address
This BRC specifies a protocol for onboarding a person who has no wallet and no coins directly into ownership of a real on-chain asset — by clicking a link. A publisher pre-funds a batch of voucher outputs ; each voucher becomes a claim link. A recipient claims by having the voucher fund an on-chain acquisition (e.g. a covenant-token mint under BRC-226 1 ) wh
This BRC specifies a sender-side profile of BRC-29. It produces P2PKH payments that a recipient can internalize with existing BRC-100 wallets, while keeping the sender's long-term identity key out of the remittance. The sender generates a fresh ephemeral secp256k1 key pair per payment, derives the beneficiary outputs with BRC-42 as if that ephemeral public k
This proposal defines ecpm , a BRC-98 permission-module scheme for applying a wallet-derived secp256k1 scalar to an arbitrary caller-supplied curve point, or removing that scalar by applying its modular inverse. The operation is carried over the existing BRC-100 getPublicKey method. Inside the reserved p ecpm namespace, a supporting wallet interprets the met
This document specifies how content is encrypted once, published where anyone can fetch it, and opened only by parties who satisfy a stated condition. Four properties follow, and each is unavailable to a paywall that decides what to render. Restricted content is actually restricted. Not hidden by a convention that anybody who reads the underlying record can