Simple Authenticated BSV P2PKH Payment Protocol
Relationship-derived payment addressing used across peer-payment flows.
Value exchange
Send and receive peer payments
Compose derivation data, proof-carrying transactions, wallet receipt, and HTTP payment negotiation.
Recommended sequence
Build the boundaries in order
- 01
Address the relationship
Derive a unique payment destination for a specific sender and recipient.
- 02
Carry and receive proof
Move the transaction with enough context for the receiving wallet to internalize and validate it.
- 03
Ask the wallet to act
Keep transaction construction, signing, and receipt behind the standard wallet boundary.
- 04
Monetize HTTP
Choose an authenticated or stateless HTTP-payment profile based on the service trust model.
Take the next step
Turn the map into a working plan
The working set
Standards in this path
Submitting Received Payments to a Wallet
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
Background Evaluation Extended Format (BEEF) Transactions
The core proof-carrying transaction container used by current implementations.
Paymail Receive BEEF
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.
Atomic BEEF Transactions
Adds a single subject transaction to a BEEF package for portable verification.
Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
The central application-to-wallet boundary. Start here for most Metanet apps.
HTTP Service Monetization Framework
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
x402 Stateless Settlement-Gated HTTP Protocol
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
Simple 402 Payments
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 path is guidance, not a new protocol or maturity designation. Check each BRC’s upstream status note, normative language, and implementation section before shipping.
Editorial policy →