BRC-166 Proposal Defines P2PKH HTTP 402 Payments for Machine-Payable Services

Payment Standards Watch / Payments Infrastructure

In Brief

Developer Andy Rowe has submitted BRC-166, a proposed HTTP 402 payment profile that allows software and AI agents to pay for online services using ordinary P2PKH transactions on BSV Blockchain. The proposal is designed for lightweight machine payments without requiring a BRC-100 wallet, identity key or BEEF transaction format, while allowing settlement to be independently verified from public blockchain data.

News Report

A new Bitcoin Request for Comments proposal seeks to standardize a lightweight way for software, APIs and AI agents to pay for online services directly through HTTP using ordinary BSV Blockchain transactions.

Developer Andy Rowe submitted BRC-166: P2PKH Payments for HTTP 402 to the BSV Blockchain BRC repository in Pull Request #231. The proposal defines an HTTP 402 settlement profile using a unique P2PKH payment address for each invoice.

Under the proposed model, a client requesting a paid resource receives an HTTP 402 Payment Required response containing the information needed to make the payment. The payer constructs and signs a normal BSV transaction to the specified address and supplies the completed transaction with the payment request.

The deliberately minimal design is one of BRC-166’s main distinctions.

The specification says a payer does not need a BRC-100 wallet, BRC-42 key derivation, an identity key or BEEF serialization. A client needs only control of BSV tokens and the ability to construct and sign the required raw transaction.

That makes the profile potentially useful for lightweight software clients and autonomous agents that need to purchase an API call or another online service without first creating an account or implementing a larger wallet architecture.

A second design objective is publicly verifiable settlement.

Because an invoice specifies a P2PKH destination and the completed payment is recorded as an ordinary blockchain transaction, the proposal says a third party can independently verify that the required output was paid by examining public chain data. Verification therefore does not have to depend solely on a private invoice database maintained by the service provider.

BRC-166 uses the exact payment scheme defined by the broader x402 Foundation protocol as its HTTP payment envelope. The x402 specification is designed to let servers advertise payment requirements in response to an HTTP request and let clients return a corresponding payment payload before receiving the requested resource. (GitHub)

The BSV Blockchain ecosystem already has other approaches to HTTP 402 payments.

BRC-121, for example, supports simple HTTP 402 payments using BRC-29 payment derivation and BEEF-encoded transactions through a BRC-100-compatible wallet. BSV Association’s 402 browser-extension implementation demonstrates that model by detecting a payment-required response, connecting to an available BRC-100 wallet, constructing the transaction and automatically retrying the request with the payment attached. (GitHub)

BRC-120 separately provides a BRC designation for another stateless settlement-gated HTTP protocol, with deterministic request binding, replay protection and its own frozen specification. (GitHub)

BRC-166 is not presented as replacing those approaches. Instead, it proposes a simpler settlement profile for cases where a payer or service does not require the wider BRC-100 wallet environment.

The proposal is also closely related to ongoing work to add BSV support to the x402 Foundation’s main protocol repository.

Pull Request #2890 currently proposes a BSV implementation of x402’s exact payment scheme using BRC-29 payments, BRC-42-derived destinations and BRC-100 wallets. That approach provides fresh derived payment destinations and a richer wallet model, but its current design means the recipient’s wallet participates in destination verification and settlement. The pull request remains open and has not yet been merged upstream. (GitHub)

Rowe describes BRC-166 and that proposed x402 implementation as complementary. In practical terms, the broader HTTP payment framework could support a wallet-oriented BSV mode using BRC-29/BRC-42 as well as a simpler mode based on conventional P2PKH addresses and raw transactions.

The proposed BRC is also backed by working software rather than being only a theoretical specification.

Rowe says the payment model has a live BSV mainnet reference implementation at bsv.cx, the machine-payable API service previously launched for pay-per-call access without conventional account creation. The implementation has now been positioned around the proposed BRC-166 specification, while free test endpoints remain available so software agents can check connectivity before attempting a paid request.

The BRC repository itself is designed as an open venue for submitting, discussing and iteratively improving technical proposals. A pull request therefore represents a proposal for review rather than an approved standard. (GitHub)

BRC-166 remains open at that stage.

BSV TIMES Read

The useful idea behind BRC-166 is its reduction of a machine purchase to a very small sequence:

request → price → payment → service.

Most online APIs were designed around a human or organization first establishing an account, receiving credentials and arranging a billing relationship. Autonomous software does not necessarily need that process for every small service it consumes.

HTTP 402 provides a way for payment requirements to become part of the request itself, while BSV Blockchain can provide the settlement underneath it.

BRC-166 is particularly interesting because it asks how little infrastructure the payer actually needs. Instead of requiring every machine to adopt the complete wallet and identity stack, the proposed profile allows a client capable of constructing an ordinary Bitcoin transaction to participate, with the resulting payment independently checkable on-chain.

The more sophisticated BRC-29/BRC-42 approach and the simpler P2PKH approach may ultimately serve different needs. If interoperable standards allow software to choose between them, machine payments become less about one particular application and more about creating a common payment capability that many services and agents can use.

BRC-166 has not reached that point yet. It remains a proposal under review. But moving an already functioning mainnet payment pattern into an open technical specification is a meaningful step toward making machine-payable services reproducible beyond a single implementation.