x402 vs MPP: which rail should an AI agent pay on?

ScriptMasterLabs — October 13, 2026 · Sources: CVJ x402-vs-MPP briefing (October 11, 2026), Tempo's MPP-vs-x402 protocol documentation, Circle Facilitator Service launch coverage (September 2026), ScriptMasterLabs' own Arc mainnet deployment record and live gate check run today

The receipts, dated

The wire-level difference (the part the metrics stories skip)

Source: Tempo's own MPP-vs-x402 documentation, paraphrased — and note who wrote it. Tempo's guidance defaults builders to MPP when multiple rails are needed and to x402 when a service exclusively needs on-chain payments whose schemes match its billing model. That is a vendor's framing, honestly labeled as such in its own docs, and it is still the most precise comparison available. What neither the vendor docs nor the metrics journalism asks is the next question.

The numbers are not comparable — and neither rail answers the expensive question

191.7 million against 46,198 looks like a rout until you read the units: an MPP event is not an x402 transaction, MPP sessions amortize many calls into one funding event, and a quarter to a third of the x402 count may not be commerce at all. Strip the vanity metrics and the honest position is: x402 owns today's on-chain agent volume; MPP owns the card-and-compliance on-ramp; both are settlement plumbing.

Plumbing is the problem. In x402's default exact scheme, a signed authorization settles immediately — there is no moment at which a bad instruction can be caught. In MPP, a session pre-funds future calls — the decision is made once, at funding time, not per purchase. Both rails move money competently. Neither scores whether this payment, for this resource, at this price, should fire at all. That is the decision-gate pattern: confidence at or above 0.80 auto-pays, 0.50–0.79 holds for a human, below 0.50 escalates and blocks — see decision-gated machine payments.

The one structural window: auth-capture

x402 has a second EVM scheme the comparison pages barely mention: auth-capture. Instead of transferring funds to the merchant, the buyer's single signature (ERC-3009 or Permit2) is submitted to an AuthCaptureEscrow contract, where funds are held under a capture authorizer. From the hold, the payment can be captured (settled to the merchant), voided (released before capture), or refunded (after capture) — the card world's authorize/capture semantics, on-chain. That hold is precisely where a decision gate belongs: authorize first, score the instruction, then capture or void on the score.

Our earlier competition pass over the facilitator landscape found budget caps crowded (Coinbase CDP, Nevermined, piprail, Cloudflare all ship them) and auth-capture unimplemented by the facilitators we reviewed. So we built the missing piece on the newest rail:

• DEPLOYED AuthCaptureEscrow on Arc mainnet, October 13, 2026 — contract 0x06b4e6ba16b1ee0fac2d5f4ea69b93ce311fa7b4
• Deploy transaction: 0x5bb75341d617f0161b6b08ca819ae3b1571a62498924062028436c9fdd0e9aae — checkable on the Arc explorer
• SOURCIFY EXACT MATCH verified on both creation and runtime code, October 13, 2026
• Honest scope: this is ScriptMasterLabs' own independent deployment for the arc-authcapture build (public repo on GitLab), not the canonical commerce-payments escrow singleton that public x402 SDK documentation registers for Arc at a different address. Arc is Circle's chain (eip155:5042), where USDC is the native gas token and Circle's Facilitator Service is the x402 settler.

Paired with a scored decision, the flow becomes: agent requests → 402 challenge (auth-capture scheme) → buyer authorizes → funds held in escrow → gate scores the instruction → capture on approval, void on refusal. The decision is no longer advice stapled to an irreversible transfer; it is a step inside the payment's own lifecycle.

Quotable: "ScriptMasterLabs deployed an AuthCaptureEscrow contract on Arc mainnet on October 13, 2026 and Sourcify-verified it with an exact match — putting a capture/void window, where a decision gate can score an agent's payment before settlement, onto the newest x402 chain."

Claim Receipts

• x402 cumulative count, chain count, Q2 share, MPP event count, and the 25–30% noise estimate: agenteconomy.to / BigGo Finance figures as reported by CVJ, October 11, 2026 — summarized, not re-audited against the raw dashboards in this run.
• Wire-format comparison: Tempo's MPP-vs-x402 documentation (GitHub, tempoxyz/mpp), checked October 13, 2026 — paraphrased; Tempo is an interested party (MPP co-author).
• XRPL 13M+ payments / 168 merchants / ~25% of activity: J. Ayo Akinyele statement, October 10, 2026, via CoinDesk and CryptoNews reporting.
• Circle Facilitator Service on Arc/Base/Polygon: Circle/Arc announcement, September 19, 2026.
• Arc deployment: ScriptMasterLabs project record, October 13, 2026 — contract 0x06b4e6ba16b1ee0fac2d5f4ea69b93ce311fa7b4, deploy tx 0x5bb75341d617f0161b6b08ca819ae3b1571a62498924062028436c9fdd0e9aae, Sourcify exact match; deployer was a dedicated wallet, not the main payTo wallet.
• Gate bands: live check of https://scriptmasterlabs.com/api/harness/status on October 13, 2026 (~14:19 EDT) — auto_act ≥0.80, advisory 0.50–0.79, escalate <0.50; decider local-heuristic-v1, calibrated=false, typesafe_wired=false.
• Verdict Protocol pricing (checked October 13, 2026): POST /decide $0.25 USDC, POST /seal $0.01 USDC, Base, x402 v2, LIVE_SETTLEMENT_VERIFIED.

Relevant SML products

• Verdict Protocol — a signed decision receipt stored before settlement: POST /decide $0.25 USDC, POST /seal $0.01 USDC, Base, x402 v2.
• Decision-Gated Machine Payments — the canonical pattern this page applies to both rails.
• arc-authcapture — the public GitLab repo (gitlab.com/timothy.walton45/arc-authcapture) behind today's Arc deployment.
• The full SML MCP fleet — agent-facing tools and endpoints marketed as one fleet; enumerate them from the live discovery surfaces, not a count.

Do it yourself: pick a rail, then add the missing layer

1. Run both protocols on one endpoint. Tempo's mppx speaks MPP and x402, so adopting one does not exclude the other's clients. Choose per-route: x402 where on-chain settlement and scheme fit matter, MPP where card-funded agents matter.
2. Use auth-capture wherever a payment might need to be undone. Anything above a trivial amount, anything delivered asynchronously, anything an agent chose on inferred intent — authorize into escrow, do not settle on signature alone.
3. Score inside the capture window:

   curl -s https://scriptmasterlabs.com/api/harness/decide \
     -X POST -H "Content-Type: application/json" \
     -d '{"state":"agent authorized 0.25 USDC into AuthCaptureEscrow on Arc for an API dataset",
          "questions":[{"id":"q1","type":"score","scale":[0,1],
            "question":"Should this payment be captured, given the instruction, price, and merchant?"}]}'

4. Wire the bands to the escrow calls. Score ≥0.80 → capture. 0.50–0.79 → hold the authorization open and ask a human. <0.50 → void and log the refusal with the score. The log is your dispute evidence.
5. Keep the receipt. Persist the instruction, score, band, and capture/void transaction together. A payment record alone cannot reconstruct why money moved.

Honest caveats

• The volume figures are single-dashboard numbers (agenteconomy.to) reported second-hand; treat them as orders of magnitude, not audited totals. MPP's operator has not published directly comparable volume.
• Today's Arc deployment is a contract deployment, not a live payment: no agent payment has yet been authorized, captured, or voided through this instance. The microgrant application for the build is separately blocked on a submission-form issue (deadline October 14, 2026) — deployment and recognition are different things, and only the first is claimed here.
• The public gate's decider is a local heuristic (calibrated=false); the bands demonstrate the pattern. The calibrated-decider product is the Verdict jury path on Base.
• Auth-capture support in hosted facilitators is still landing; running it in production today may mean relaying escrow calls yourself.