x402 Stateless Settlement-Gated HTTP Protocol

Rui Da Silva (Merkle Works)

Classification

This BRC is categorized under “payments” for repository organization purposes. However, x402 defines a settlement-gated request protocol rather than a standalone payment method.

Abstract

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 the merkleworks-x402-spec repository. This document establishes scope and mandatory conformance rules. It does not redefine wire formats, header payloads, or verification procedures; those remain solely in the canonical specification.

BRC-120 is an identification and conformance designation only; it does not introduce an alternative or parallel specification.

Motivation

The x402 protocol defines a deterministic pattern for 402 Payment Required, settlement proofs on the BSV settlement layer, and request binding, with normative rules published as a frozen document so independent clients and servers interoperate without private interpretations. Under that model, verifiable settlement functions as the authorization primitive: correctness MUST NOT depend on server-maintained accounts, balances, or authorization state, and verification MUST remain stateless with respect to per-client session state as specified in spec/x402.md.

A formal BRC entry gives implementers a single stable label (BRC-120) and a clear bridge to the maintained x402 specification repository, without duplicating its protocol text.

Specification

1. Scope

This BRC standardizes the following:

1. Naming — Use of BRC-120 to refer to x402 v1.0 implementations that conform to this standard.

2. Conformance — Mandatory conditions for advertising BRC-120 compliance. An implementation MUST NOT claim BRC-120 compliance based on behavior not defined in spec/x402.md.

This BRC does not specify challenge JSON fields, proof structure, X402-Challenge / X402-Proof encodings, transaction shape beyond what the canonical spec requires, UTXO selection rules beyond the nonce UTXO and related constraints in the frozen specification, or step-by-step verification pseudocode. That material is only in spec/x402.md (see References).

2. Dependency on the canonical frozen specification

An implementation MAY claim BRC-120 compliance only if it conforms to the document titled x402: Stateless Settlement-Gated HTTP Protocol, Specification Version: 1.0, Specification Status: Frozen, published as spec/x402.md in the merkleworks-x402-spec repository (as published on its default branch). The canonical location is given in References.

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, and OPTIONAL in this BRC are to be interpreted as described in RFC 2119 and RFC 8174, in line with the canonical x402 specification.

3. Required behavior for BRC-120 compliance

Any software that claims BRC-120 compliance for a given role (for example client, gateway, origin server, or verifier) MUST implement all normative requirements that spec/x402.md assigns to that role for version 1.0, including but not limited to:

1. HTTP 402 challenge / proof / retry model — Issue, consume, and retry requests according to the challenge and proof rules and HTTP semantics defined in the frozen specification (including use of designated headers as specified there).

2. Deterministic request binding — Construct and verify proofs such that the request authorized after payment is bound to the proof and challenge exactly as required by the verification procedure in the frozen specification.

3. Canonical JSON (RFC 8785) — Where the frozen specification requires deterministic JSON serialization before hashing or comparison, implementations MUST apply RFC 8785 as specified.

4. Nonce UTXO replay protection — Honor the nonce UTXO model and replay-protection rules in the frozen specification, including any checks the spec mandates around reuse of proofs or spends.

5. Proof verification — Perform proof verification and settlement-layer checks as specified, without weakening mandatory conditions.

6. Settlement-gated execution — Execute the protected HTTP operation only after rules in the frozen specification for settlement-gated authorization are satisfied for that request.

An implementation MUST NOT represent itself as BRC-120 compliant if it diverges from any MUST-level rule in spec/x402.md v1.0 for the roles it implements.

Implementations MAY add behaviors only where the frozen specification explicitly permits extensions. Such additions MUST NOT contradict the frozen core.

4. Index of relied-upon x402 elements

The following capabilities are relied on for BRC-120; exact definitions, field names, and algorithms appear only in spec/x402.md and, where referenced there, accompanying test vectors:

Element	Role in BRC-120
402 challenge / proof / retry model	Mandatory interaction pattern for payment discovery and retries.
Deterministic request binding	Mandatory binding of proof to the secured request context.
Canonical JSON / RFC 8785	Mandatory serialization where the spec requires canonical JSON.
Nonce UTXO replay protection	Mandatory replay controls centered on the nonce UTXO.
Proof verification	Mandatory validity checks before treating a request as paid.
Settlement-gated execution	Mandatory gating of resource execution on verifiable settlement.

5. Conformance target

BRC-120 is an interoperability and labeling designation within the BRC index. BRC-120 compliance means full x402 v1.0 as frozen in spec/x402.md, not a reduced or alternate wire profile.

6. Normative precedence

If any requirement or explanation in BRC-120 conflicts with the frozen x402 v1.0 document spec/x402.md, then spec/x402.md prevails and this BRC MUST be read as aligned to that document. Supporting material in the same repository (for example docs/, test-vectors/, or process documents) MUST NOT override spec/x402.md unless the frozen specification explicitly incorporates them.

Implementations

1. Canonical rules — Implementers SHOULD read spec/x402.md first (see References); it is the frozen source of truth for x402 v1.0.

2. The merkleworks-x402-spec repository contains non-normative supporting material. Implementers MAY consult it, but it does not define BRC-120 compliance.

3. Test vectors — Deterministic vectors are published in the merkleworks-x402-spec repository (for example under test-vectors/ and in section 13 of spec/x402.md).

4. Reference implementation — An experimental reference implementation is available at https://github.com/merkleworks/x402-bsv. This implementation is non-normative and provided for engineering reference only.

5. Nature of this BRC — BRC-120 defines what “BRC-120 compliant” means by reference to the frozen x402 specification. It is not a substitute specification and does not introduce a second normative protocol document.

References

• x402 frozen normative specification: https://github.com/ruidasilva/merkleworks-x402-spec/blob/main/spec/x402.md

• merkleworks-x402-spec repository: https://github.com/ruidasilva/merkleworks-x402-spec