x402 gets a rulebook: XPs, three principles, 343 open PRs

x402 is about to get a constitution. PR #3801 proposes three design principles and a formal proposal process, XPs, copied closely from MCP's SEPs. We read it against the 343 open pull requests in the repo and counted which ones the new rules would catch, which they would wave through, and how many already carry the prototype the process demands.

Most of what we write about x402 is a spec audit: a scheme, an extension, a rail. This one audits the rulebook instead. If it lands, it decides which of the proposals we have been tracking become protocol and which stay forks.

The PR was opened on 2026-10-14 by Erik Reppel. It adds one file, specs/xps/README.md (189 lines), at head db2f397. As of 2026-10-23 it is open, unmerged and has no formal review. Its own status line says "Draft for TSC discussion". It is not ratified. Everything below describes a proposal.

How it got here

The PR answers x402-foundation/tsc#9, an agenda item from August. The first draft there came from Tim (who comments as timaxorum). It proposed seven principles and a two-tier structure: principles on top, testable requirements beneath them in working-group trackers, each requirement citing its parent principle.

The seven were: minimal core with a lawful floor, carry little and anchor everything, one substrate with many profiles, no raw personal data in the core, no hidden role transitions, built for machine scale, and honest absence. The last one reads: "A check that did not happen must never present as one that passed."

Reactions split on structure. One commenter wanted to cut the seven to four and rename them "proposal evaluation principles". Another wanted security made explicit and machine-scale throughput added. On 2026-09-16 Erik Reppel disagreed with the mechanism. Backlinking every requirement to a principle is rigid, he argued, and the bleeding edge needs malleability. His alternative: fewer principles, each taking a clear stance, owned by the TSC, plus a proposal process. Working groups may adopt stricter rules for themselves.

PR #3801 is that alternative written down. It is the second design for the same problem, not a consensus text.

What the PR actually specifies

Three principles, each of the form "X over Y":

• Simplicity over completeness. "Complexity that enters the core almost never leaves."
• Demonstrated need over anticipated need. A normative requirement must trace to "a real implementation, deployed or committed, that cannot work without it."
• Present law over predicted law. x402 "exposes the facts an obligation depends on; it does not decide what those facts mean or whose rules apply."

New principles are added through a Process XP. A good one states a stance, names the cost it accepts, and is short enough to cite in review.

The process has four XP types: Standards Track (types, facilitator interface, required behavior), Extensions Track (a new or changed scheme, transport or extension), Process, and Informational. Extensions Track is "the default home for new ideas". A pattern can graduate to Standards Track once it has proven itself across implementations.

You write an XP for a core spec change, a new scheme, transport or extension, a breaking change, a governance change, or a contested topic. You do not write one for bug fixes, typos, documentation clarifications, examples, or "a new network implementation of an existing scheme that follows the scheme's template without changing behavior". That last carve-out matters later.

The lifecycle: discuss in a working group or issue, open a PR with the XP file, find a sponsor (a TSC member, a maintainer, or someone the TSC assigns), then draft, in-review, and a TSC decision of accepted or rejected. After acceptance comes implementation and tests, then final. An XP with no sponsor after six months is marked dormant, which "is not a rejection". The TSC reviews in-review XPs every two weeks.

Two gates carry the weight. A runnable prototype is required before acceptance: an SDK branch, a standalone proof of concept, integration tests or a reference client, server or facilitator. "Pseudocode, design documents alone and 'trust me, it works' don't count." And a Standards Track XP that changes observable behavior cannot reach final until conformance tests are merged. They must cover every MUST/MUST NOT and SHOULD/SHOULD NOT in the Specification section, or record why one is excluded, and they must pass against the reference implementation.

Transition rules: early-stage proposals (an idea, an issue, an early draft spec) move into the XP process and need a sponsor. Proposals close to merge or a TSC decision are grandfathered under specs/CONTRIBUTING.md. The TSC decides borderline cases.

How close it is to MCP

The PR says it is modeled on MCP. We read both SEP guidelines and design principles to see what was kept and what was dropped.

The process is near-verbatim. Same four types, same eight statuses, same six-month dormancy, same two-week review, same prototype list, same eight-section document format, same "sponsor owns the status" rule. The workflow diagram is near-identical.

Four differences are worth noting.

First, principles. MCP lists eight: convergence over choice, composability over specificity, interoperability over optimization, stability over velocity, capability over compensation, demonstration over deliberation, pragmatism over purity, standardization over innovation. x402 starts with three. Only one has a clear MCP counterpart: demonstrated need over anticipated need echoes demonstration over deliberation. Present law over predicted law has no MCP analogue. It fits the tax, identity and card working groups the draft names.

Second, sponsors. In MCP a sponsor is a Core Maintainer or Maintainer. In the x402 draft it can also be "people the TSC assigns". That widens the pool, and it matters for outside authors, as we show below.

Third, conformance. MCP requires a conformance scenario in a dedicated repository, tagged with the SEP number, plus a structured traceability file mapping each MUST and SHOULD to a check or a documented exclusion. The x402 draft keeps the coverage rule but names no repository, no file format and no CI contract.

Fourth, finalization. MCP says SDK implementations are not required for a SEP to become final. The x402 draft says the reference implementation lands and the spec changes merge. It does not say whether the SDKs must follow.

The census: what 343 open PRs look like under these rules

The process only matters if it changes outcomes. So we pulled every open pull request in x402-foundation/x402 on 2026-10-23 with its file list and classified each by path. We did not read 343 diffs. The classification is a heuristic, and we state its limits below.

// open PRs: 343
// touch specs/ (excluding specs/xps and CONTRIBUTING): 129
standards        12   // edits x402-specification-v2.md or transports-v2/
ext-new          35   // adds a file under specs/extensions/
scheme-new        9   // adds a scheme dir beyond exact/upto/auth-capture/batch-settlement
network-binding  20   // adds scheme_exact_<net>.md only
scheme-amend     44   // edits existing scheme specs
ext-amend        9   // edits existing extension specs

Of 343 open PRs, 129 touch the spec tree. That is 38 percent. Over the last 91 days (merged since 2026-07-24) the repo merged 303 PRs, and 40 of them touched specs/. So the open queue is far more spec-heavy than what ships. Many of the merged spec touches were fixes: stale API names, broken links, wire-format corrections.

Under the XP rules, the first three rows, 56 PRs, are XP-shaped: they change the core, or add an extension or a scheme. Twelve of those 56 are more than 180 days old. We cannot map age to the dormancy clock, because that clock starts at the sponsor stage, but it shows how long such proposals already wait with no process at all.

Now the prototype gate. For each of the 56 we checked whether the diff contains any file outside specs/, docs/ and markdown: SDK code, tests, contracts, e2e. Ten do. The other 46 are prose. Three of the 46 ship JSON test vectors inside specs/ (#3220, #3298, #3783), which is a weaker kind of prototype but not nothing. That leaves 43 spec-only proposals with no runnable artifact in the diff.

The limits are real. A PR body can link a prototype in another repository, and we did not follow links. The twelve "standards" PRs include small fixes the XP process would not require, such as converting pseudo-headings to markdown headings (#3863). And the boundaries between classes are judgment calls. Treat 43 as an upper bound on "no prototype in the PR", not a count of unprototyped ideas.

The conformance side is thinner still. Searching the file tree of main for any path containing "conformance" or "vectors" returns nothing. Eleven open PRs add such files, among them a conformance runner (#2776) and a test suite pinning the v2 spec's obligations (#3549). The draft requires coverage of every MUST and SHOULD, but today no merged artifact exists that a Standards Track XP could extend.

The carve-out is drawn on paths, the risk is in behavior

The sharpest question is the carve-out for "a new network implementation of an existing scheme that follows the scheme's template without changing behavior". Twenty open PRs look like that by path: they add one scheme_exact_<net>.md and nothing else in the spec tree. They would take a normal PR.

One of them is the Nano scheme, #3432. We audited it in our Nano post. Its signed object is a ledger block that never expires, and one account can have exactly one payment in flight. Those are behavior changes by any reading. EIP-3009 authorizations expire and commute. The same file path would let that through as "just a binding".

Our Sui audit found the same pattern from another angle: an effects-only binding has no object versions to protect a payment from replay, so protection moves into facilitator dedup state that the spec text barely mentions. That PR (#3081) edits an existing file, so even the path test misses it.

This is not an argument against the carve-out. Forcing an XP on every chain would bury the process. It is an argument that "without changing behavior" needs a checklist, and the Nano and Sui audits suggest what is on it: does the signed object expire, do two payments from one account commute, what does the facilitator learn at verify versus settle, what is the failure mode between the two. Our fifteen-chain survey covers the bindings that exist today.

A first real test: an outside author asks the sponsor question

The PR has six comments. Two are bots. Four are from one author, ruiruii, between 2026-10-18 and 2026-10-20, and they are the best evidence that the draft is already read as operative.

That author is reworking a core-spec issue (#3772) and an open spec PR (#3776) to fit the XP form. They self-check against all three principles. They argue the change is Standards Track, not Extensions Track, on one test: an extension is something an implementer can decline, and this one cannot be declined. They assemble conformance material ahead of time, including negative vectors derived from two real implementation bugs. And they ask the question the draft leaves open: for an author who is neither a TSC member nor a maintainer, is there an artifact a sponsor needs that is not in the list?

We do not have an answer, and the draft does not give one either. Sponsors may be "people the TSC assigns", but there is no stated route by which an outsider gets one assigned. The six-month dormancy clock starts ticking at that stage.

Our recovery extension audit is a case in point. That proposal (#3848) adds a new extension file, so it is Extensions Track by the draft's own rule, and its diff contains no code. When we audited it we built the harness ourselves: an Express handler-before-settle order test and a payment-identifier replay run. Under the XP rules, a harness like that is exactly the prototype that would move such a proposal from draft toward review.

What it means for LLM4Agents

We are a spec consumer and a gateway, not a spec author. Three things follow.

First, status becomes a signal we can use. Today every open PR in the extensions directory looks equally real. If XP statuses ship, final with conformance tests means "safe to implement", and draft means "experimental". Our extensions audit and the receipts audit had to decide by reading code which proposals to trust. A status field replaces some of that judgment.

Second, the 402 body we emit is a public contract. Every extension key we add or honor is something an XP could later rename, narrow or reject. The safe position is to depend on no unaccepted proposal. The cost of tracking drops if the process works. The cost of a stalled process is that proposals sit at "awaiting sponsor" while implementers diverge.

Third, the process creates a place for our own evidence to count. The draft values demonstrated need and runnable prototypes. A reproducible audit that shows a failure on a real rail is that kind of evidence, and the ruiruii example shows outside material being offered in exactly this form. We should expect to contribute negative vectors, not opinions.

The threat is not the process itself. It is the transition. "Early-stage proposals move into the XP process" means a large number of open spec PRs may be asked to restart in a new format with a sponsor they do not have. Of 56 XP-shaped PRs, 12 are older than 180 days. If the TSC reviews every two weeks, throughput will decide whether the backlog becomes a queue or a graveyard.

Staying on the frontier

In order:

First, do not change code for #3801. Watch it. The triggers are a TSC decision, the first merged file under specs/xps/, and a statement of which in-flight proposals are grandfathered. Until then it is a draft.

Second, add a status column to our internal x402 support matrix. For each scheme and extension we track, record the source PR or spec, whether it is merged, and, once XPs exist, its XP status. Rule: we ship only merged specs, and we ship extensions only with a runnable test.

Third, write the behavior checklist for network bindings and publish it as a comment on a binding PR, ideally the next one we audit. Four questions: does the signed object expire, do two payments from one account commute, what does verify prove versus settle, what happens between them. It gives the "without changing behavior" clause an operational test.

Fourth, turn our harnesses into vectors. The recovery harness, the Nano hash reconstruction and the Sui simulate probe each produced pass/fail cases. Package each as a small JSON file with expected outcomes and offer them to the relevant PR. The draft's own conformance rule asks for exactly this, and the eleven open PRs that add vectors or conformance files use several different shapes.

Fifth, ask in the PR the question the outside author asked: what artifact makes an outsider sponsorable, and who assigns sponsors? A concrete answer unblocks everyone. We should add our view that the conformance requirement needs a named home, a file format and a CI contract before the first Standards Track XP reaches review. MCP's traceability file is a ready model.

Sixth, stay out of the principles debate, with one exception. "Present law over predicted law" is the principle that constrains what x402 will carry about tax and identity. Our gateway handles neither. We should not argue for or against it. We should make sure that whatever facts the 402 exposes are accurate, because that is the part the principle commits x402 to.