# 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 . 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: * merkleworks-x402-spec repository: