x402 Foundation (x402 a Series of LF Projects, LLC), Technical Steering Committee: Coinbase, Cloudflare, Stripe
Status
Live Protocol V2 has been live since 2025-12-11. The upto, batch-settlement, auth-capture and Lightning bindings are newer, and SDK coverage differs by language.
Latest version
Spec v2.0 (x402Version 2); SDK @x402/core 2.28.0 on 2026-09-29,
State as of
Verified (verified under 30 days ago)
Crypto-native
Multi-rail
Settlement rails (primary layer)
Payment credential
Discovery
Post-purchase and disputes
A. TL;DR and key facts
x402 lets a server charge for one HTTP request. It answers 402 with a price, the client retries with a signed payment, and a facilitator verifies and settles it, usually in USDC.
Why it exists
Paying for a single API call or web page has always needed an account, an API key, a card on file or a monthly invoice. Software agents cannot open accounts or type card numbers, and per-call prices of a fraction of a cent do not survive card fees. x402 puts the price and the payment inside the HTTP exchange itself, so any client with a wallet can pay any server on the first request, and the server never has to touch a blockchain because a facilitator does that part.
What it is not
Not a Coinbase product any more. Coinbase originated x402, but the x402 Foundation, a Linux Foundation project, now governs it. Source [1, 2, 3, 4]
Not only USDC on Base. Networks are CAIP-2 ids across EVM chains, Solana, Lightning and others, and default assets include USDT0, MegaUSD, USDM and USDT. Source [10, 17, 18, 19]
Not L402, A402 or x402r. L402 is an earlier HTTP 402 design on Lightning, A402 is an academic proposal, and x402r is a third-party refund layer. Source [33, 34, 35, 36]
Not a refund or dispute system. The exact scheme defines no refund; refunds exist only in auth-capture, batch-settlement channels or third parties. Source [35, 37, 38, 39]
Not an identity protocol. Identity is optional and lives in extensions such as sign-in-with-x and auth-hints, or in other protocols such as ERC-8004. Source [20, 28, 30, 40]
Not a custodian. The facilitator verifies and broadcasts but does not hold funds. Source [21, 41]
Not one wire format. V1 used a JSON body and X-PAYMENT headers; V2 uses PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE. Source [14, 42, 43]
Key facts as of 2026-10-11
Steward
x402 Foundation (x402 a Series of LF Projects, LLC); originated at Coinbase Developer Platform Source [1, 2, 3, 4]
AP2 (a2a-x402), ERC-8004 (x402Support, proofOfPayment), Stripe MPP (exact maps to charge), Visa TAP (browsingIOU) Source [29, 30, 31, 32]
How to read this explanation
ELI5 is a short plain-language version. Practitioner is the full text. Spec-deep adds field tables and wire examples. STE shows the Simplified Technical English version instead.
B. Detailed explanation
ELI5 mode: plain-language version only.
Practitioner mode: the full explanation.
Spec-deep mode: the full explanation plus 4 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
Picture a vending machine on the internet. You press the button for a snack, and instead of the snack the machine shows a price tag: one cent, paid in this kind of money, to this machine. You write a signed note that says “I pay one cent to this machine, and this note is good for the next minute only.” You slide the note into the slot and press the button again.
The machine does not count money itself. It hands your note to a helper standing behind it. The helper checks that the signature is really yours, that you have the money, and that nobody used this note before. If all is well, the machine gives you the snack and the helper cashes the note.
The note names the amount and the machine, so the helper cannot change either one. Each note also carries a one-time number and a short expiry, so nobody can use it twice. In the basic version there is no “give me my money back” button, and the machine learns nothing about who you are, only that the note was good.
That is x402. The snack is any web page or online service, the note is a digital signature, and the helper is called a . Software agents can do all of this on their own, with no account, password or card form.
x402 answers one question: how does a server charge for a single HTTP request without accounts, API keys or invoices? The server replies with a header that lists what it : a , a network, an amount, an asset and a payee address.Source [10, 14] The client signs a payment that matches one of those entries and retries the same request with the signature in a header.Source [14] The server never touches a chain itself. It hands the signature to a facilitator, which checks it (verify), lets the server respond, then submits it on-chain (settle).Source [7, 10] The client’s signature binds the amount and the recipient, so a facilitator cannot redirect funds, and a with a validity window stops replays.Source [10, 21] What x402 does not give you: refunds under the , a dispute process, or any statement about who the client is.Source [20, 28, 37, 38, 40] Those live in other layers: the , ERC-8004, or your own policy.Source [30, 35, 38, 39]
Problem and design goals
x402 is an open payment standard that puts payment inside an ordinary HTTP (Hypertext Transfer Protocol) request and response, using the status code 402 Payment Required.Source [7] Its repository says it aims to cover crypto and fiat networks alike, but the bindings written so far are almost all blockchains, plus Lightning and one credit-backed network run by Cloudflare.Source [7, 10, 17, 18, 19, 20] The design came out of Coinbase Developer Platform (CDP): the whitepaper is dated 2025-05-06 and credits Erik Reppel and five co-authors.Source [1]
The target is a payment that costs a fraction of a cent and happens on the first request, made by software that cannot fill in a sign-up form. Three design choices follow. First, the price travels in the 402 response, so the client needs no account or API (application programming interface) key in advance.Source [10, 14] Second, the client signs an authorization instead of sending funds, and a principle in the repository says no scheme may let the facilitator or the move funds other than as the client intended.Source [7] Third, chain work goes to a facilitator, which usually pays the gas, so neither side has to run blockchain infrastructure.Source [7, 10, 41, 51]
The specification is just as clear about what it leaves out. Client-side budget management and session handling are out of scope, so spending limits live in SDKs (software development kits) and wallets, not in the protocol.Source [10, 52] Keep that in mind when you read “agent payments” marketing: x402 moves a signed payment, and every decision about whether to sign it belongs to someone else.
Actors and roles
x402 has three roles.Source [7, 10] The client is any application or agent that wants a protected resource and can sign a payment. The resource server sells the resource: it publishes requirements, checks payments and serves the response. The facilitator verifies payments and executes them on one or more networks.Source [7, 10]
The facilitator is the role newcomers misread most. It does not hold funds and is not a custodian.Source [41] On EVM (Ethereum Virtual Machine) chains it broadcasts the client’s signed authorization and pays the gas; on Solana it co-signs the transaction as fee payer.Source [41, 51] On Solana the fee payer can also be the merchant, and the requirements name it in the extra object.Source [51] Anyone can run a facilitator, and a resource server can verify and settle on its own without one.Source [7, 41] The SDK packages point to the public facilitator at x402.org by default, which serves testnets only, so production servers pick a facilitator on purpose.Source [7, 53] Critics note that the CDP facilitator processes most payments even though the protocol is permissionless, and Cloudflare’s new gateway also routes through it.Source [50, 54, 55]
Two newer bindings add roles. In the credit-backed cloudflare:402 network, the network itself is and payTo is the constant merchant.Source [20] In the auth-capture scheme on EVM, an operator drives hold and capture on an escrow contract, by default the AuthCaptureEscrow contract from base/commerce-payments v1.1.Source [25]
Core objects
Five objects carry a payment. PaymentRequired is what the server sends with the 402: a version number, an optional error string, a ResourceInfo describing what is for sale, an accepts list and optional .Source [10] ResourceInfo needs only a URL; description, MIME type, service name, tags and an icon URL are optional.Source [10] Each entry of accepts is a PaymentRequirements object with six required fields (scheme, network, amount, asset, payTo, maxTimeoutSeconds) and an optional extra object.Source [10] Networks are (Chain Agnostic Improvement Proposal 2) identifiers such as eip155:84532, and amounts are strings in the asset’s smallest unit.Source [10] The extra object reserves two keys, assetTransferMethod and ; the rest is scheme specific, such as the token’s (EIP: Ethereum Improvement Proposal) domain name and version on EVM chains.Source [10, 21]
is what the client sends back. It repeats the version, may echo the resource, copies the chosen requirements into accepted, and carries a scheme-specific payload plus any extensions.Source [10] For the exact scheme on EVM with the default method, that payload is a signature and an authorization naming from, to, value, validAfter, validBefore and a nonce.Source [10, 21] Other methods use other shapes: a authorization whose spender is a fixed proxy contract, an ERC-7710 (ERC: Ethereum Request for Comments) delegation, or on Solana one partially signed transaction.Source [21, 51]
The facilitator answers with a VerifyResponse (isValid, an optional invalidReason, the payer and optional extension data) and a SettleResponse (success, errorReason, payer, transaction, network, amount and extensions).Source [10] A settle that broadcast nothing returns an empty transaction string, and a settle still pending must carry the hash.Source [10] GET /supported lists the scheme and network pairs a facilitator handles, the extensions it implements and its signer addresses.Source [10] Extensions travel in both directions as an info object plus a JSON Schema, and the client must echo what it received without deleting or overwriting it.Source [10]
Field tables. Spec version v2.0, read from specs/x402-specification-v2.md section 5 and specs/schemes/exact/scheme_exact_evm.md at commit f8f8330. Descriptions are paraphrased.
PaymentRequired (sent in the PAYMENT-REQUIRED header)Spec version v2.0
Reserved keys assetTransferMethod and paymentFlow; other keys are scheme specific (on EVM, name and version of the token EIP-712 domain). Spec reference for extra
PaymentPayload (sent in the PAYMENT-SIGNATURE header)Spec version v2.0
Illustrative example, spec version v2.0: a decoded PAYMENT-REQUIRED header. Addresses are placeholders; the asset is the (USD Coin) contract on Base Sepolia that the docs list as a default.
The main sequence in section C plays the default path: version 2 over HTTP, the exact scheme, the authorization payment flow.Source [10]
The client requests the resource without a payment header.Source [10, 14]
The server answers 402 and puts a base64-encoded PaymentRequired object in the PAYMENT-REQUIRED header.Source [10, 14] Since @x402/core 2.21.0 the SDK also sends Cache-Control no-store on that response, so shared caches do not keep it.Source [22]
The client picks one accepts entry and signs it. The TypeScript client first applies : by default only known assets, and at most $1 per payment.Source [22, 49] It then signs EIP-712 typed data for the EIP-3009 TransferWithAuthorization type.Source [21]
The client sends the same request again with a base64-encoded PaymentPayload in the PAYMENT-SIGNATURE header.Source [14]
The server posts , paymentPayload and paymentRequirements to the facilitator’s POST /verify.Source [10] Verify must not write state.Source [10] The facilitator checks the signature, that the recipient and amount match, the time window, the balance and whether the nonce was used before.Source [10, 21, 56, 57]
If the payment is valid the server runs the handler; if not, it answers 402 again.Source [10, 14]
The server posts the same body to POST /settle, and the facilitator broadcasts the transfer and pays the gas.Source [10, 41, 51]
The server returns 200 with the resource and a base64-encoded SettleResponse in PAYMENT-RESPONSE. A failed settle returns 402 with success false in the same header.Source [14]
Every step has a failure path, and section C plays five of them. An expired window, a wrong recipient and a low balance come back from verify as error codes such as invalid_exact_evm_payload_authorization_valid_before, invalid_exact_evm_payload_recipient_mismatch and insufficient_funds.Source [10] A replayed payment fails because the token contract records every nonce, and the TypeScript facilitator reads that record before it says yes.Source [10, 56, 57] That facilitator reports some reasons in its own words, such as invalid_exact_evm_recipient_mismatch and invalid_exact_evm_nonce_already_used, which differ from names in the spec, so match on both if you parse them.Source [57]
A facilitator that does not answer is the awkward case. The TypeScript facilitator client gives up after 90 seconds by default, and the Express middleware turns that into HTTP 502 without running the handler.Source [58, 59] A settle that times out is worse: the transfer may already have happened, so the server must look on chain before it retries, and a answer carries the hash to look for.Source [10, 41, 58]
Headers in V1 and V2. V2 renamed every header and moved the requirements out of the 402 body.
V2 HTTP headers (x402Version 2)Spec version v2.0
Field
Type
Required
Description
PAYMENT-REQUIRED
server to client
Yes
Base64-encoded PaymentRequired, sent with status 402.
PAYMENT-SIGNATURE
client to server
Yes
Base64-encoded PaymentPayload on the retried request.
PAYMENT-RESPONSE
server to client
Yes
Base64-encoded SettleResponse, on 200 (success) or 402 (success false).
EXTENSION-RESPONSES
facilitator to server
No
Base64-encoded extension outcomes; never forwarded to buyers.
V1 HTTP transport (x402Version 1), for contrastSpec version v1 (spec v0.2, 2025-10-03)
Field
Type
Required
Description
402 response body
server to client
Yes
JSON PaymentRequirementsResponse with x402Version, error and accepts; no header.
X-PAYMENT
client to server
Yes
Base64-encoded V1 PaymentPayload with x402Version, scheme, network and payload.
X-PAYMENT-RESPONSE
server to client
Yes
Base64-encoded V1 SettlementResponse.
network (value)
string
Yes
Plain names such as base-sepolia instead of CAIP-2 ids.
maxAmountRequired
string
Yes
V1 name of the price field (amount in V2).
HTTP status codes (V2 HTTP transport).
Case
Status
Payment required
402
Invalid payment (malformed payload or requirements)
400
Payment failed (verify or settle)
402
Server error
500
Success
200
Permit2 allowance missing (, exact Permit2)
412
Error codes named in the specification (section 9).insufficient_funds, invalid_exact_evm_payload_authorization_valid_after, invalid_exact_evm_payload_authorization_valid_before, invalid_exact_evm_payload_authorization_value_mismatch, invalid_exact_evm_payload_signature, invalid_exact_evm_payload_recipient_mismatch, invalid_network, invalid_payload, invalid_payment_requirements, invalid_scheme, unsupported_scheme, invalid_x402_version, invalid_transaction_state, unexpected_verify_error, unexpected_settle_error, settlement_pending. The TypeScript EVM facilitator also emits its own strings, for example invalid_exact_evm_nonce_already_used and invalid_exact_evm_insufficient_balance.
Signed type (exact, eip3009).TransferWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce), signed as EIP-712 typed data under the token contract domain.
Illustrative example, spec version v2.0: the body the resource server posts to the facilitator. The same body goes to /verify and then to /settle.
The order of verify, handler and settle is not fixed. V2 names three payment flows in extra.paymentFlow: authorization (verify, run, settle), upfront (settle, then run) and escrow (settle a deposit or hold, run, then settle the final charge).Source [10] Whatever the flow, at least one verify or settle must run before the handler.Source [10] A client must not pay into a flow it does not recognize, and should prefer authorization when a server offers more than one.Source [10]
Each flow puts the risk somewhere else. Under authorization the seller has done the work before money moves, so a failed settle is the seller’s loss; under upfront, a handler that fails leaves the client charged.Source [10, 60] Lightning uses upfront because nothing can be pulled from a Lightning wallet later. The server issues a fresh (the Lightning invoice format), the client pays it and returns the , and the facilitator checks the hash and records it against replay.Source [19] The auth-capture scheme defaults to escrow: a first settle places a hold, the handler runs, and a second settle captures the real amount or voids the hold.Source [10, 38] Its operations are authorize, charge, capture, void, refund and reclaim, and reclaim lets the client recover an untouched hold after the capture deadline.Source [38]
Settlement itself has three outcomes: success, a terminal failure, and settlement_pending, which is not final and which the server retries once and reconciles.Source [10, 41] Over (the Agent2Agent protocol) the task carries its own status values, from payment-required through payment-submitted and payment-verified to payment-completed or payment-failed.Source [16] channels have an on-chain lifecycle of their own, visible as ChannelCreated, Deposited, Claimed, Settled, Refunded, WithdrawInitiated, WithdrawFinalized and ChannelClosed events.Source [61] The state machine in section C folds all three flows into one diagram.
Payment flows (extra.paymentFlow, section 6.1).
Flow
Order
Note
authorization (default)
verify, resource, settle, respond
/verify is read-only; funds move after the handler.
upfront
settle, resource, respond
No /verify; needed where funds cannot be pulled later (Lightning).
escrow
settle, resource, settle, respond
First settle commits a deposit or hold; default for auth-capture and SVM (Solana Virtual Machine) upto.
auth-capture lifecycle operationsSpec version auth-capture v1.1 (2026-08-18)
Field
Type
Required
Description
authorize
once
No
Reserves the client funds in a hold. Client-authorized.
charge
once
No
Collects in one step with no hold (authorization flow).
capture
repeatable
No
Pays held funds to the receiver, up to the held total.
void
once
No
Releases the remaining hold while one exists.
refund
repeatable
No
Returns captured funds, up to captured minus refunded, until extra.refundDeadline.
reclaim
once
No
Client-only recovery of an untouched hold after extra.captureDeadline; never relayed by the facilitator.
Security and trust model (summary)
The signed note protects you in two ways: nobody can change the amount or the name on it, and it works only once and only for a minute. It does not protect you from writing the note to the wrong shop, from a shop that takes the money and then serves nothing, or from spending too much in a day. Those checks are up to you and your wallet.
The core guarantee is narrow and strong. In the exact EVM scheme the client’s signature covers the recipient and the amount, so a facilitator can broadcast the payment but cannot change where it goes or how much moves.Source [21] comes from a random 32-byte nonce that EIP-3009 tokens refuse to reuse, plus a validAfter and validBefore window.Source [10] In upto, a witness field names the one facilitator allowed to settle.Source [60]
Everything else is trust you place in a party. The exact scheme defines no refund, and any remedy is the server’s own arrangement.Source [37] Under upto the client trusts the server to charge fairly up to the ceiling.Source [10, 60] There is no dispute process in the protocol.Source [37, 38] Client spending limits are an SDK feature, not a protocol rule, and passing spendControls false turns them off.Source [7, 10, 49, 52]
SDK bugs have mattered more than protocol bugs so far. Two GitHub advisories rated high hit legacy resource-server packages (2025-08-20) and facilitators that process Solana payments (2026-03-07), and recent core releases closed route-matching bypasses through encoded paths.Source [22, 62, 63] Neither advisory has a CVE (Common Vulnerabilities and Exposures) identifier.Source [62, 63] Academic work describes five practical attacks on authorization, binding and replay handling, flaws such as cross-resource substitution and a duplicate settlement race, and the missing atomic link between payment and delivery.Source [34, 64, 65] Section H has the full threat table, and section I lists what a controls layer can add.
Versioning and governance
Two protocol versions exist, and the x402Version field says which one a message uses; version 2 is current.Source [10, 13] The v2.0 specification is dated 2025-12-09 and rebuilt the payment objects around CAIP-2 networks, a separate ResourceInfo and extensions.Source [10] V2 launched on 2025-12-11 with @x402/core 2.0.0.Source [11, 12] The headers changed names: V1 put the requirements in the 402 body and used X-PAYMENT and X-PAYMENT-RESPONSE, while V2 uses PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE.Source [14, 42, 43] The V1 specification stays in the repository, and the launch post says the SDKs stay backward compatible.Source [13, 66]
Package names follow the split. The unscoped npm packages, x402 and x402-express among them, are the V1 legacy set, while the @x402 scoped packages and the PyPI package x402 2.x implement V2.Source [7, 42, 67] PyPI x402 is not legacy: its latest version is 2.25.0, published 2026-09-29.Source [67] The TypeScript packages ship minor releases about weekly and reached 2.28.0 on 2026-09-29.Source [7, 12]
Governance moved from a company to a foundation. Cloudflare and Coinbase announced a foundation plan on 2025-09-23.Source [45] A technical charter for x402 a Series of LF Projects, LLC was adopted on 2026-03-31. The Linux Foundation announced the x402 Foundation on 2026-04-02 and its operational launch on 2026-07-14, with 40 member organizations.Source [2, 3, 4] The charter sets up a Technical Steering Committee (TSC) with one vote per representative and majority decisions, and needs a 75 percent supermajority to change the Core Principles.Source [2] TSC.md names Coinbase (Erik Reppel), Cloudflare (Rohin Lohe) and Stripe (Steve Kaliski).Source [5] The original repository moved to the x402-foundation organization, and coinbase/x402 is now a fork of it.Source [68, 69] The code is Apache-2.0, and contributions need GPG-signed (GNU Privacy Guard) commits.Source [6, 8] So: Coinbase originated x402, but it no longer governs it alone.Source [1, 2, 3, 4]
Names changed too. The scheme Cloudflare proposed as deferred in 2025-09 became batch-settlement when it merged on 2026-04-15, and old deferred examples still linger in one extension and in the V1 specification.Source [13, 40, 44, 45]
Extensibility
x402 grows along three axes. Schemes define how value moves: exact, upto, batch-settlement and auth-capture in V2.Source [10] A new scheme starts as a specification pull request, then gets one reference SDK, then the others.Source [8] Networks are bindings of a scheme: the TypeScript SDK covers 13 network families, from EVM chains and Solana to Lightning, while Go and Python cover fewer.Source [18, 19, 52] Extensions add optional features without touching the core: , sign-in-with-x, payment-identifier, offer-receipt, builder-code, http-message-signatures, auth-hints and two gas-sponsoring extensions.Source [7, 70]
A few deserve a closer look. Bazaar describes how to call a resource over HTTP or (Model Context Protocol), so that a discovery service can list it.Source [70] The CDP Bazaar endpoint answered without an API key, and it returns resource listings, not categories.Source [71] Payment-identifier gives idempotency: a server returns 409 when the same identifier arrives with a different payload.Source [72] Offer-receipt signs offers and receipts with EIP-712 or JWS (JSON Web Signature), but the SDK parity table lists it for TypeScript only.Source [52, 73] Builder-code appends an suffix to settlement calldata so indexers can attribute the app and the facilitator, which is attribution, not revenue sharing.Source [23, 35] Facilitators can also hand extension results to the server through an EXTENSION-RESPONSES header that buyers never see.Source [10]
Transports are the third axis. The same objects ride in HTTP headers, in the _meta field of an MCP tool call, and in A2A task metadata, while the facilitator API underneath stays HTTP.Source [10, 15, 16] Over MCP, if settlement fails after the tool ran, the server should return only the payment error, not the tool output.Source [15]
Extension keys and their main fieldsSpec version v2.0 (specs/extensions)
Field
Type
Required
Description
bazaar
discovery
No
info.input.type (http or mcp), method, queryParams, bodyType, body, headers, toolName, inputSchema; info.output.type and info.output.example.
info.authRequirements with acceptIndexes and methods (type, tokenType, authorizationServer).
eip2612GasSponsoring
gas
No
Client signs an EIP-2612 permit so the facilitator can approve Permit2 without client gas.
erc20ApprovalGasSponsoring
gas
No
Client supplies a signed approve transaction for Permit2.
How it composes with the other seven
x402 is a payment step with no opinion about who the client is or what the user approved, so it pairs with protocols that carry those answers.Source [10, 20, 28, 40, 52] Google’s AP2 (Agent Payments Protocol) announcement of 2025-09-16 launched an A2A x402 extension with Coinbase, which makes x402 one way to pay under AP2.Source [29] ERC-8004 keeps payments out of its core but gives agents an x402Support flag and lets feedback carry proof of an x402 payment.Source [30] MPP (Machine Payments Protocol), co-authored by Stripe and Tempo, maps x402 exact onto its charge intent and can serve both protocols on one route.Source [31] Visa’s TAP (Trusted Agent Protocol) specification has its own object for answering a 402.Source [32] No link to ACP (Agentic Commerce Protocol), maintained by OpenAI and Stripe, or to UCP (Universal Commerce Protocol) appears in their repositories.Source [7] The section “Compare and compose” below goes further.
Limitations and open issues
Volume is contested. The x402.org counter showed 75.41M transactions and $24.24M over 30 days when read on 2026-10-10, yet the page said it was last updated on 2026-08-25.Source [74] The same $24.24M was reported for mid August, so the figure may be stale.Source [74, 75] Visa and Artemis data to 2026-04-21 adjusts activity to about $15.0M across 109.6M transactions.Source [76] Visa’s Cuy Sheffield separately cited about $19M across about 134M, and nobody has reconciled the two.Source [77] Artemis flagged 63.94 percent of transactions as gamed on average between 2025-11-09 and 2026-02-07.Source [78] A paper of 2026-07-14 counts 136,708,672 settlements on Base over 280 days and argues that the count can be manufactured almost for free.Source [79] Read every volume figure as a claim with a date and a method.Source [74, 76, 78, 79]
Facilitators concentrate trust. The protocol is permissionless, yet one facilitator carries most payments.Source [50, 54, 55] A facilitator cannot redirect funds, but it can refuse service, and it sees every payment.Source [10, 21, 39]
Payment and delivery are not atomic. Under authorization the seller risks unpaid work, under upfront the buyer risks paying for nothing, and A402 proposes a fix.Source [10, 34, 60]
Headers get big. Base64 JSON can pass 2 KB and be dropped by intermediaries, which is why the cloudflare:402 binding strips schema and optional fields.Source [20]
Spec drift. SettleResponse is also called SettlementResponse, deferred examples survive the rename, the TypeScript facilitator uses its own reason strings, and the batch-settlement EVM version table carries a 2025 date for a 2026 file.Source [10, 27, 39, 40, 57]
Uneven SDKs. Python lacks auth-capture and Solana batch-settlement, and the Java module has no published artifact.Source [52, 80]
Metadata leaks. Resource URLs and descriptions reach the facilitator, and one paper treats that as a PII (personally identifiable information) channel.Source [10, 39, 81]
Small steering group. Three companies sit on the TSC, and Stripe also co-created the competing MPP.Source [5, 82]
What changed in 2025 and 2026
2025-05-06: whitepaper and public launch; npm x402 0.3.0 published the same day.Source [1, 9]
2025-08-20: first high-severity advisory, for legacy npm packages below 0.5.2.Source [62]
2025-09-16: the A2A x402 extension launched with AP2, and a2a-x402 published v0.1.0.Source [29, 83]
2025-09-23: Cloudflare and Coinbase announced a foundation plan; Cloudflare’s Agents SDK added x402 for agents and MCP servers.Source [45]
2025-10: daily transactions surged during a wave of x402-powered memecoin launches (reported).Source [84]
2026-01-08 and 2026-01-15: Permit2 support and the bazaar extension merged.Source [27, 70]
2026-02-02: sign-in-with-x merged; 2026-02-10 and 2026-02-11 brought a Stripe preview and Coinbase Agentic Wallets that use x402 (both reported).Source [27, 28, 85, 86]
2026-03-04: the upto scheme merged; 2026-03-07: the Solana facilitator advisory.Source [63, 87]
2026-03-31 and 2026-04-02: the charter was adopted and the Linux Foundation announced the x402 Foundation.Source [2, 3]
2026-04-15: batch-settlement merged with the cloudflare:402 binding; 2026-04-29: Circle Nanopayments went live.Source [44, 46]
2026-05-12 and 2026-05-13: TSC.md and the auth-capture scheme.Source [5, 47, 48]
2026-07-14: the foundation’s operational launch with 40 members.Source [4]
2026-08-18: spendControls with a $1 default cap in @x402/core 2.23.0.Source [12, 22]
2026-09-23: exact on Lightning; 2026-09-30: Cloudflare Monetization Gateway closed beta, settling USDC (USD Coin) on Base through Coinbase’s facilitator and separate from the credit-backed cloudflare:402 variant.Source [18, 19, 20, 50]
C. Diagrams
Main flow: x402 V2 over HTTP: exact scheme, authorization payment flow
The default x402 path. The server answers an unpaid request with 402 and a PAYMENT-REQUIRED header, the client retries with a signed EIP-3009 authorization in PAYMENT-SIGNATURE, the server asks a facilitator to verify, runs the handler, asks the facilitator to settle, and returns the resource with a PAYMENT-RESPONSE header.
Client (agent)
Resource server
Facilitator
Base Sepolia
1
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 13Client (agent) toto Resource server
GET /weather (no payment header)
The client asks for the resource like any HTTP request. It does not know the price yet, so it sends no PAYMENT-SIGNATURE header. A client that already knows the requirements can skip this round trip.
Generated from the flow definition (spec version v2.0, 2025-12-09). The player above uses the same data.
Text alternative
Sequence diagram: x402 V2 over HTTP: exact scheme, authorization payment flow. 4 participants: Client (agent), Resource server, Facilitator, and Base Sepolia. 13 steps, 4 crossing a trust boundary, 10 failure branches. Based on x402 v2.0 (2025-12-09). Step 1: Client (agent) to Resource server: GET /weather (no payment header). Step 2: Resource server to Client (agent): 402 Payment Required with PAYMENT-REQUIRED. If A route has no registered scheme: Since @x402/core 2.25.0 the SDK throws an error instead of answering 402 with an empty accepts list. Step 3: Client (agent) to Client (agent): Choose an accepts entry, check limits, sign EIP-712. If Amount is above the spend cap or the asset is not allowed: The SDK rejects the entry; if no entry is left, no payment is created. If The entry names a paymentFlow the client does not recognize: The client must skip that entry. Step 4: Client (agent) to Resource server: Retry GET /weather with PAYMENT-SIGNATURE. If The header is malformed: The server answers 400 (invalid payment). Step 5: Resource server to Facilitator: POST /verify. This step crosses a trust boundary. If The facilitator is unreachable or times out: See the facilitator-down flow: the Express middleware answers 502 and the handler does not run. Step 6: Facilitator to Base Sepolia: Read balance and nonce state, simulate. This step crosses a trust boundary. Step 7: Facilitator to Resource server: Return VerifyResponse isValid true. If isValid is false (for example expired window, wrong recipient, used nonce, low balance): The server answers 402 and the handler does not run. See the failure flows. Step 8: Resource server to Resource server: Run the handler. If The handler fails: The server does not settle, so the client is not charged (an SDK hook, settleOnCancel, can change this). Step 9: Resource server to Facilitator: POST /settle. This step crosses a trust boundary. If The settle call times out: The outcome is indeterminate: the transfer may still confirm, so the server must reconcile before it retries. Step 10: Facilitator to Base Sepolia: Broadcast transferWithAuthorization. This step crosses a trust boundary. If The nonce was consumed in the meantime or the balance dropped: The transaction reverts; the facilitator returns success false. Step 11: Base Sepolia to Facilitator: Return transaction receipt. Step 12: Facilitator to Resource server: Return SettleResponse success true. If errorReason is settlement_pending: Non-terminal: the transaction was broadcast but not confirmed. The response carries the hash, and the server reconciles before it decides. Step 13: Resource server to Client (agent): 200 OK with PAYMENT-RESPONSE.
Step 1: Client (agent) to Resource server: GET /weather (no payment header).
Step 2: Resource server to Client (agent): 402 Payment Required with PAYMENT-REQUIRED. If A route has no registered scheme: Since @x402/core 2.25.0 the SDK throws an error instead of answering 402 with an empty accepts list.
Step 3: Client (agent) to Client (agent): Choose an accepts entry, check limits, sign EIP-712. If Amount is above the spend cap or the asset is not allowed: The SDK rejects the entry; if no entry is left, no payment is created. If The entry names a paymentFlow the client does not recognize: The client must skip that entry.
Step 4: Client (agent) to Resource server: Retry GET /weather with PAYMENT-SIGNATURE. If The header is malformed: The server answers 400 (invalid payment).
Step 5: Resource server to Facilitator: POST /verify. This step crosses a trust boundary. If The facilitator is unreachable or times out: See the facilitator-down flow: the Express middleware answers 502 and the handler does not run.
Step 6: Facilitator to Base Sepolia: Read balance and nonce state, simulate. This step crosses a trust boundary.
Step 7: Facilitator to Resource server: Return VerifyResponse isValid true. If isValid is false (for example expired window, wrong recipient, used nonce, low balance): The server answers 402 and the handler does not run. See the failure flows.
Step 8: Resource server to Resource server: Run the handler. If The handler fails: The server does not settle, so the client is not charged (an SDK hook, settleOnCancel, can change this).
Step 9: Resource server to Facilitator: POST /settle. This step crosses a trust boundary. If The settle call times out: The outcome is indeterminate: the transfer may still confirm, so the server must reconcile before it retries.
Step 10: Facilitator to Base Sepolia: Broadcast transferWithAuthorization. This step crosses a trust boundary. If The nonce was consumed in the meantime or the balance dropped: The transaction reverts; the facilitator returns success false.
Step 11: Base Sepolia to Facilitator: Return transaction receipt.
Step 12: Facilitator to Resource server: Return SettleResponse success true. If errorReason is settlement_pending: Non-terminal: the transaction was broadcast but not confirmed. The response carries the hash, and the server reconciles before it decides.
Step 13: Resource server to Client (agent): 200 OK with PAYMENT-RESPONSE.
Lifecycle: x402 payment lifecycle (V2, all three payment flows)
A filled dot marks the initial state; terminal states have a double border; dashed lines go back to an earlier state. Numbers on the lines match the transition list.
Transition
Unpaid request to Payment required (402)
Trigger
Server sends 402
API call
HTTP 402 + PAYMENT-REQUIRED
Spec reference
transports-v2/http.md
About Payment required (402)
PAYMENT-REQUIRED header sent with the accepts list.
State notes
Unpaid request
No PAYMENT-SIGNATURE header.
Payment required (402)
PAYMENT-REQUIRED header sent with the accepts list.
Payload received
PAYMENT-SIGNATURE decoded; the flow comes from extra.paymentFlow.
success true; PAYMENT-RESPONSE carries the transaction hash.
Rejected
400 for a malformed payload and 402 for a failed payment (spec); the @x402/express middleware answers 502 when the facilitator is unreachable (SDK behavior).
Voided or reclaimed
auth-capture escrow only.
Spec version v2.0.
State diagram: x402 payment lifecycle (V2, all three payment flows)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Generated from the state machine definition (spec version v2.0).
Text alternative
State diagram: x402 payment lifecycle (V2, all three payment flows). 11 states: Unpaid request, Payment required (402), Payload received, Verified, Committed before execution, Handler executed, Settlement pending, Settled, Rejected, Responded 200, and Voided or reclaimed. Starts in Unpaid request. Ends in Rejected, Responded 200, and Voided or reclaimed. 18 transitions. From Unpaid request to Payment required (402) when Server sends 402 (HTTP 402 + PAYMENT-REQUIRED). From Payment required (402) to Payload received when Client retries with a signed payload (PAYMENT-SIGNATURE header). From Payload received to Rejected when Malformed payload or unsupported scheme, network or flow (HTTP 400). From Payload received to Verified when authorization flow: facilitator returns isValid true (POST /verify). From Payload received to Rejected when Facilitator returns isValid false (POST /verify, then HTTP 402). From Payload received to Rejected when Facilitator unreachable (@x402/express answers 502; SDK behavior, not in the spec) (HTTP 502). From Payload received to Committed before execution when upfront or escrow flow: first settle succeeds (POST /settle). From Verified to Handler executed when Handler runs. From Committed before execution to Handler executed when Handler runs. From Handler executed to Settled when authorization flow: settle succeeds, or escrow: capture succeeds (POST /settle). From Handler executed to Settlement pending when Settle broadcast but not confirmed, or timed out (POST /settle). From Settlement pending to Settled when Server reconciles on chain and finds the transfer. From Settlement pending to Rejected when Reconciliation shows no transfer and one retry fails (POST /settle). From Handler executed to Rejected when Settle fails (for example insufficient_funds) (HTTP 402 + PAYMENT-RESPONSE success false). From Handler executed to Voided or reclaimed when escrow: server voids the hold (POST /settle with payload.type void). From Handler executed to Voided or reclaimed when escrow: client reclaims an untouched hold after captureDeadline (reclaim called by the client on the escrow contract (never relayed through the facilitator)). From Settled to Responded 200 when Server returns the resource (HTTP 200 + PAYMENT-RESPONSE). From Handler executed to Responded 200 when upfront: payment already settled, server returns the resource (HTTP 200 + PAYMENT-RESPONSE).
From Unpaid request to Payment required (402) when Server sends 402 (HTTP 402 + PAYMENT-REQUIRED).
From Payment required (402) to Payload received when Client retries with a signed payload (PAYMENT-SIGNATURE header).
From Payload received to Rejected when Malformed payload or unsupported scheme, network or flow (HTTP 400).
From Payload received to Verified when authorization flow: facilitator returns isValid true (POST /verify).
From Payload received to Rejected when Facilitator returns isValid false (POST /verify, then HTTP 402).
From Payload received to Rejected when Facilitator unreachable (@x402/express answers 502; SDK behavior, not in the spec) (HTTP 502).
From Payload received to Committed before execution when upfront or escrow flow: first settle succeeds (POST /settle).
From Verified to Handler executed when Handler runs.
From Committed before execution to Handler executed when Handler runs.
From Handler executed to Settled when authorization flow: settle succeeds, or escrow: capture succeeds (POST /settle).
From Handler executed to Settlement pending when Settle broadcast but not confirmed, or timed out (POST /settle).
From Settlement pending to Settled when Server reconciles on chain and finds the transfer.
From Settlement pending to Rejected when Reconciliation shows no transfer and one retry fails (POST /settle).
From Handler executed to Rejected when Settle fails (for example insufficient_funds) (HTTP 402 + PAYMENT-RESPONSE success false).
From Handler executed to Voided or reclaimed when escrow: server voids the hold (POST /settle with payload.type void).
From Handler executed to Voided or reclaimed when escrow: client reclaims an untouched hold after captureDeadline (reclaim called by the client on the escrow contract (never relayed through the facilitator)).
From Settled to Responded 200 when Server returns the resource (HTTP 200 + PAYMENT-RESPONSE).
From Handler executed to Responded 200 when upfront: payment already settled, server returns the resource (HTTP 200 + PAYMENT-RESPONSE).
Four trust zones: the client holds the key and its own spend limits, the seller runs the middleware and the handler, the facilitator verifies and settles, and the network moves the funds. Discovery services are public and optional. Numbers follow the main flow.
Text alternative
Flowchart. The client zone holds the client or agent, its wallet key and spendControls. The client sends a request to the x402 middleware in the seller zone and gets 402 with PAYMENT-REQUIRED, signs with the wallet key, and retries with PAYMENT-SIGNATURE. The middleware calls the facilitator zone: POST /verify, which only reads the token contract, and POST /settle, which broadcasts to the token contract and pays gas. The middleware reads GET /supported at startup. The client can find resources through the Bazaar discovery endpoint and x402scan.
The V2 types from the specification. PaymentRequired travels in PAYMENT-REQUIRED, PaymentPayload in PAYMENT-SIGNATURE and SettleResponse in PAYMENT-RESPONSE. The payload object is scheme specific; the exact EVM form with an EIP-3009 authorization is shown.
Text alternative
Class diagram. PaymentRequired has x402Version, error, a ResourceInfo resource, one or more PaymentRequirements in accepts, and extensions. ResourceInfo has url, description, mimeType, serviceName, tags and iconUrl. PaymentRequirements has scheme, network, amount, asset, payTo, maxTimeoutSeconds and extra. PaymentPayload has x402Version, resource, the accepted PaymentRequirements, a scheme payload and extensions. The exact EVM payload has a signature and an authorization with from, to, value, validAfter, validBefore and nonce. Each extension has info and schema. Verify returns VerifyResponse with isValid, invalidReason and payer. Settle returns SettleResponse with success, errorReason, payer, transaction, network and amount. GET /supported returns kinds, extensions and signers.
V2 moved the payment requirements from the 402 body into a header, renamed every header, switched network names to CAIP-2 ids and renamed the price field. Both values of x402Version still exist, so check which one a server speaks.
Text alternative
Two rows. V1: a 402 response with a JSON body PaymentRequirementsResponse, a retry with the X-PAYMENT header, and an X-PAYMENT-RESPONSE header; networks are names such as base-sepolia and the price field is maxAmountRequired. V2: a 402 response with a PAYMENT-REQUIRED header, a retry with PAYMENT-SIGNATURE, and a PAYMENT-RESPONSE header; networks are CAIP-2 ids such as eip155:84532, the price field is amount, ResourceInfo is a separate object and extensions exist. An arrow labeled migration guide points from V1 to V2.
extra.paymentFlow decides when money moves relative to the handler. Authorization puts the risk of a failed settle on the seller, upfront puts the risk of a failed handler on the buyer, and escrow holds funds first and charges the real amount after. At least one check always runs before the handler.
Text alternative
Three rows. Authorization, the default: POST /verify, which is read only, then the handler runs, then POST /settle, then 200 with PAYMENT-RESPONSE. Upfront: POST /settle, then the handler runs, then 200 with PAYMENT-RESPONSE. Escrow: POST /settle to place a deposit or hold, then the handler runs, then a second POST /settle for the final charge, capture or void, then 200 with PAYMENT-RESPONSE.
Four schemes, from simplest to most stateful. exact settles once; upto settles a metered amount under a signed ceiling; batch-settlement serves on an off-chain voucher and settles in batches later; auth-capture holds funds, captures later and allows refunds. Dates are the first merge of each spec file.
Text alternative
Four groups. Exact, specified since 2025-02 before the launch: the client signs the exact amount and one transfer follows the handler; the Lightning binding of 2026-09-23 is paid upfront. Upto, 2026-03-04: the client signs a ceiling, the server settles the metered amount up to the ceiling, and a zero charge needs no transaction. Batch-settlement, 2026-04-15, formerly called deferred: a deposit opens a channel, each request carries a cumulative voucher and is served at once, and claims and one settlement come later for many vouchers; the cloudflare:402 variant is credit that Cloudflare bills later. Auth-capture, 2026-05-13: authorize places a hold before the handler, capture or void follows, refunds are possible until the refund deadline, and the client can reclaim after the capture deadline.
Where the payment objects sit in HTTP, MCP and A2A
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The same three objects (PaymentRequired, PaymentPayload, SettleResponse) ride in headers over HTTP, in the _meta field of an MCP tool call, and in task metadata over A2A. The facilitator API underneath stays HTTP.
Text alternative
Three columns. HTTP: 402 with the PAYMENT-REQUIRED header, then the PAYMENT-SIGNATURE header, then the PAYMENT-RESPONSE header. MCP: a tool result with isError true and PaymentRequired in structuredContent, then the _meta key x402/payment, then the _meta key x402/payment-response. A2A: a task in input-required with metadata x402.payment.required, then message metadata x402.payment.payload, then metadata x402.payment.receipts. All three lead to the facilitator API, which is HTTP in every case.
x402 failure: the authorization expired (validBefore in the past)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The client signed a window that closed before the server verified it. The facilitator rejects the payload, the handler does not run and the client must sign again.
Text alternative
Sequence diagram: x402 failure: the authorization expired (validBefore in the past). 3 participants: Client (agent), Resource server, and Facilitator. 5 steps, 1 crossing a trust boundary. Based on x402 v2.0 (2025-12-09). Step 1: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE. Step 2: Resource server to Facilitator: POST /verify. This step crosses a trust boundary. Step 3: Facilitator to Resource server: Return isValid false (valid_before). Step 4: Resource server to Client (agent): 402 with a fresh PAYMENT-REQUIRED. Step 5: Client (agent) to Client (agent): Sign again with a new window and nonce.
Step 1: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE.
Step 2: Resource server to Facilitator: POST /verify. This step crosses a trust boundary.
Step 3: Facilitator to Resource server: Return isValid false (valid_before).
Step 4: Resource server to Client (agent): 402 with a fresh PAYMENT-REQUIRED.
Step 5: Client (agent) to Client (agent): Sign again with a new window and nonce.
Step 1 of 5: Client (agent) to Resource server. Retry with PAYMENT-SIGNATURE.
x402 failure: the signed recipient does not match payTo
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The client signed an authorization to an address that is not the payTo in the server requirements, for example because it used stale or altered requirements. Verification fails on the recipient check.
Text alternative
Sequence diagram: x402 failure: the signed recipient does not match payTo. 3 participants: Client (agent), Resource server, and Facilitator. 5 steps, 1 crossing a trust boundary. Based on x402 v2.0 (2025-12-09). Step 1: Client (agent) to Client (agent): Sign to an unexpected address. Step 2: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE. Step 3: Resource server to Facilitator: POST /verify. This step crosses a trust boundary. Step 4: Facilitator to Resource server: Return isValid false (recipient mismatch). Step 5: Resource server to Client (agent): 402 with a fresh PAYMENT-REQUIRED.
Step 1: Client (agent) to Client (agent): Sign to an unexpected address.
Step 2: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE.
Step 3: Resource server to Facilitator: POST /verify. This step crosses a trust boundary.
Step 5: Resource server to Client (agent): 402 with a fresh PAYMENT-REQUIRED.
Source of truth: EIP-3009 (external link) Generated from src/content/flows/x402-failure-wrong-payto.json.
Play this flow step by step
Client (agent)
Resource server
Facilitator
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 5Client (agent) toto Client (agent)
Sign to an unexpected address
The requirements the client used named a different payTo than the server expects, for example after a proxy altered the 402 response or a cached copy went stale. The client signed authorization.to for that address.
Spec version v2.0 (2025-12-09). Sources: [10], [21], [57]
Step 1 of 5: Client (agent) to Client (agent). Sign to an unexpected address.
x402 failure: a used authorization is sent again (replayed nonce)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
A captured PAYMENT-SIGNATURE is sent a second time after it settled. The nonce is already used on the token contract, so verification fails and a second settlement is impossible.
Text alternative
Sequence diagram: x402 failure: a used authorization is sent again (replayed nonce). 4 participants: Client (agent), Resource server, Facilitator, and Base Sepolia. 6 steps, 2 crossing a trust boundary. Based on x402 v2.0 (2025-12-09). Step 1: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE. Step 2: Resource server to Facilitator: POST /verify. This step crosses a trust boundary. Step 3: Facilitator to Base Sepolia: Read authorizationState(from, nonce). This step crosses a trust boundary. Step 4: Base Sepolia to Facilitator: Return true (nonce used). Step 5: Facilitator to Resource server: Return isValid false (nonce already used). Step 6: Resource server to Client (agent): 402 with a fresh PAYMENT-REQUIRED.
Step 1: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE.
Step 2: Resource server to Facilitator: POST /verify. This step crosses a trust boundary.
Step 3: Facilitator to Base Sepolia: Read authorizationState(from, nonce). This step crosses a trust boundary.
Step 4: Base Sepolia to Facilitator: Return true (nonce used).
Spec version v2.0 (2025-12-09). Sources: [10], [56], [57]
Step 1 of 6: Client (agent) to Resource server. Retry with PAYMENT-SIGNATURE.
x402 failure: the payer balance is too low
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Two variants. At verify time the facilitator sees a low balance and the handler does not run. If the balance drops between verify and settle, settlement fails after the handler ran, and the server returns 402 with a failed PAYMENT-RESPONSE.
Text alternative
Sequence diagram: x402 failure: the payer balance is too low. 4 participants: Client (agent), Resource server, Facilitator, and Base Sepolia. 6 steps, 2 crossing a trust boundary, 1 failure branch. Based on x402 v2.0 (2025-12-09). Step 1: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE. Step 2: Resource server to Facilitator: POST /verify. This step crosses a trust boundary. Step 3: Facilitator to Resource server: Return isValid false (insufficient_funds). If The balance was enough at verify time but dropped before settle: Verify passes and the handler runs. Steps 4 to 6 show the settle-time variant. Step 4: Resource server to Facilitator: POST /settle (balance dropped after verify). This step crosses a trust boundary. Step 5: Facilitator to Resource server: Return success false (insufficient_funds). Step 6: Resource server to Client (agent): 402 with PAYMENT-RESPONSE success false.
Step 1: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE.
Step 2: Resource server to Facilitator: POST /verify. This step crosses a trust boundary.
Step 3: Facilitator to Resource server: Return isValid false (insufficient_funds). If The balance was enough at verify time but dropped before settle: Verify passes and the handler runs. Steps 4 to 6 show the settle-time variant.
Step 4: Resource server to Facilitator: POST /settle (balance dropped after verify). This step crosses a trust boundary.
Step 5: Facilitator to Resource server: Return success false (insufficient_funds).
Step 6: Resource server to Client (agent): 402 with PAYMENT-RESPONSE success false.
Spec version v2.0 (2025-12-09). Sources: [10], [14], [57]
Step 1 of 6: Client (agent) to Resource server. Retry with PAYMENT-SIGNATURE.
x402 failure: the facilitator is down or times out
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
If verify cannot reach the facilitator, the server answers 502 and the handler does not run. If settle times out, the outcome is indeterminate and the server must reconcile on chain before it retries.
Text alternative
Sequence diagram: x402 failure: the facilitator is down or times out. 4 participants: Client (agent), Resource server, Facilitator, and Base Sepolia. 5 steps, 3 crossing a trust boundary, 1 failure branch. Based on x402 v2.0 (2025-12-09). Step 1: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE. Step 2: Resource server to Facilitator: POST /verify (no answer). This step crosses a trust boundary. Step 3: Resource server to Client (agent): 502 Bad Gateway. Step 4: Resource server to Facilitator: POST /settle (times out). This step crosses a trust boundary. If The facilitator answers settlement_pending: Non-terminal. The response carries the broadcast hash; the server checks it on chain and retries at most once. Step 5: Resource server to Base Sepolia: Reconcile: look up the transaction. This step crosses a trust boundary.
Step 1: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE.
Step 2: Resource server to Facilitator: POST /verify (no answer). This step crosses a trust boundary.
Step 3: Resource server to Client (agent): 502 Bad Gateway.
Step 4: Resource server to Facilitator: POST /settle (times out). This step crosses a trust boundary. If The facilitator answers settlement_pending: Non-terminal. The response carries the broadcast hash; the server checks it on chain and retries at most once.
Step 5: Resource server to Base Sepolia: Reconcile: look up the transaction. This step crosses a trust boundary.
Step 1 of 5: Client (agent) to Resource server. Retry with PAYMENT-SIGNATURE.
x402 alternative path: upfront flow with the exact scheme on Lightning
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Lightning has no way to pull a signed authorization later, so the lnbtc binding uses the upfront flow: the client pays a BOLT11 invoice first, sends the preimage, the facilitator settles by checking the preimage, and only then does the server run the handler. There is no /verify call and no refund path.
Text alternative
Sequence diagram: x402 alternative path: upfront flow with the exact scheme on Lightning. 4 participants: Client (agent), Resource server, Facilitator, and Lightning Network. 8 steps, 2 crossing a trust boundary, 3 failure branches. Based on x402 v2.0 (2025-12-09). Step 1: Client (agent) to Resource server: GET /article/A. Step 2: Resource server to Client (agent): 402 with a fresh BOLT11 invoice. Step 3: Client (agent) to Lightning Network: Pay the invoice. This step crosses a trust boundary. If The invoice expired (maxTimeoutSeconds equals the invoice expiry): The payment fails; the client requests a new 402. Step 4: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE (preimage). Step 5: Resource server to Facilitator: POST /settle (no /verify). This step crosses a trust boundary. If The preimage does not match, or the payment hash was already recorded: Settle fails and the handler does not run. A replay is refused. Step 6: Facilitator to Resource server: Return SettleResponse success true. Step 7: Resource server to Resource server: Run the handler. If The handler fails after settlement: The client paid for nothing; any remedy is the server's own arrangement. Step 8: Resource server to Client (agent): 200 OK with PAYMENT-RESPONSE.
Step 1: Client (agent) to Resource server: GET /article/A.
Step 2: Resource server to Client (agent): 402 with a fresh BOLT11 invoice.
Step 3: Client (agent) to Lightning Network: Pay the invoice. This step crosses a trust boundary. If The invoice expired (maxTimeoutSeconds equals the invoice expiry): The payment fails; the client requests a new 402.
Step 4: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE (preimage).
Step 5: Resource server to Facilitator: POST /settle (no /verify). This step crosses a trust boundary. If The preimage does not match, or the payment hash was already recorded: Settle fails and the handler does not run. A replay is refused.
Step 6: Facilitator to Resource server: Return SettleResponse success true.
Step 7: Resource server to Resource server: Run the handler. If The handler fails after settlement: The client paid for nothing; any remedy is the server's own arrangement.
Step 8: Resource server to Client (agent): 200 OK with PAYMENT-RESPONSE.
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 8Client (agent) toto Resource server
GET /article/A
The client asks for a paid article.
HTTP payload. Illustrative example, spec version v2.0.
GET /article/A HTTP/1.1
Host: api.example.com
Spec version v2.0 (2025-12-09). Sources: [10], [18], [19]
Step 1 of 8: Client (agent) to Resource server. GET /article/A.
x402 alternative path: escrow flow with the auth-capture scheme
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The client authorizes a maximum. A first settle places a hold on an escrow contract, the resource runs, and a second settle captures the actual amount (or voids the hold). Refunds can follow until the refund deadline, and the client can reclaim an untouched hold after the capture deadline.
Text alternative
Sequence diagram: x402 alternative path: escrow flow with the auth-capture scheme. 4 participants: Client (agent), Resource server, Facilitator, and AuthCaptureEscrow (EVM). 9 steps, 4 crossing a trust boundary, 2 failure branches. Based on x402 v2.0 (2025-12-09). Step 1: Client (agent) to Resource server: POST /jobs (no payment). Step 2: Resource server to Client (agent): 402 with an auth-capture entry. Step 3: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE (one authorization). Step 4: Resource server to Facilitator: POST /settle (authorize: place the hold). This step crosses a trust boundary. Step 5: Facilitator to AuthCaptureEscrow (EVM): authorize on AuthCaptureEscrow. This step crosses a trust boundary. Step 6: Resource server to Resource server: Run the job and meter it. Step 7: Resource server to Facilitator: POST /settle (payload.type capture). This step crosses a trust boundary. If The server never captures: After captureDeadline the client can call reclaim directly on the escrow contract. If The buyer is unhappy later: The server can relay refund until refundDeadline. Step 8: Facilitator to AuthCaptureEscrow (EVM): capture 0.75 USDC. This step crosses a trust boundary. Step 9: Resource server to Client (agent): 200 OK with PAYMENT-RESPONSE.
Step 1: Client (agent) to Resource server: POST /jobs (no payment).
Step 2: Resource server to Client (agent): 402 with an auth-capture entry.
Step 3: Client (agent) to Resource server: Retry with PAYMENT-SIGNATURE (one authorization).
Step 4: Resource server to Facilitator: POST /settle (authorize: place the hold). This step crosses a trust boundary.
Step 5: Facilitator to AuthCaptureEscrow (EVM): authorize on AuthCaptureEscrow. This step crosses a trust boundary.
Step 6: Resource server to Resource server: Run the job and meter it.
Step 7: Resource server to Facilitator: POST /settle (payload.type capture). This step crosses a trust boundary. If The server never captures: After captureDeadline the client can call reclaim directly on the escrow contract. If The buyer is unhappy later: The server can relay refund until refundDeadline.
Step 8: Facilitator to AuthCaptureEscrow (EVM): capture 0.75 USDC. This step crosses a trust boundary.
Step 9: Resource server to Client (agent): 200 OK with PAYMENT-RESPONSE.
Step 1 of 9: Client (agent) to Resource server. POST /jobs (no payment).
How x402 composes with the other protocols
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
x402 is the payment step. AP2 can carry it as a payment method through a2a-x402 (whose embedding targets AP2 v0.1 mandates), ERC-8004 can record that an agent accepts it and attach proof of payment to feedback, Stripe MPP can serve it on the same route, and Visa TAP has its own object for answering a 402. L402 is an earlier, separate HTTP 402 design.
Text alternative
x402 sits in the center. AP2 mandates connect to x402 through the a2a-x402 extension, which targets AP2 v0.1. ERC-8004 registries connect through x402Support, agentWallet and proofOfPayment. Stripe MPP connects because x402 exact maps to MPP charge and mppx serves both. Visa TAP connects through a browsingIOU object that answers a 402. x402 uses MCP _meta and A2A metadata as transports. L402 is linked with a dotted line labeled same status code, different design. x402 is the rail for Circle Nanopayments and the Cloudflare Monetization Gateway beta.
Where published attacks and SDK advisories land. The signature protects amount and recipient, the nonce stops replay, but the protocol leaves payTo checks, budgets, delivery guarantees, privacy of metadata and facilitator honesty to the parties. Details and sources are in section H.
Text alternative
Five groups. Client side: signing an altered payTo or amount, and overspending under upto or without a cap. Wire and edge: a 402 response altered in transit, a captured signed header replayed, and large headers dropped by intermediaries. Resource server: route-matching bypass with encoded paths, a handler that runs while the settle fails, and cross-resource substitution. Facilitator: a duplicate settlement race, refusing or censoring payments, and seeing resource metadata. Chain and data: wash and farmed volume. An altered 402 leads to a wrong payTo signature, a replayed header targets the facilitator, and facilitator settlements feed the volume data.
Spec-deep mode: the full explanation plus 0 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
This section uses Simplified Technical English (ASD-STE100): short sentences, one instruction per step, and one word for one meaning.
x402 is an open protocol for payments in HTTP. A server uses status 402 to tell a client the price of a resource. The client signs a payment and sends the request again. A facilitator verifies the payment and then sends it to the network. Coinbase started x402 in 2025. The x402 Foundation of the Linux Foundation now controls the protocol.
x402 has three roles. The client signs the payment. The resource server sells the resource and sends the payment requirements. The facilitator verifies the payment and starts the settlement on the network. The facilitator does not keep the money of the client.
Version 2 is the current version. It uses three HTTP headers: PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE. Version 1 used a different set of headers.
The exact scheme moves one fixed amount one time. The signature of the client includes the amount and the payTo address. Thus, the facilitator cannot change the amount or the address.
The nonce and the time window stop a replay attack. x402 does not identify the client. x402 does not give a refund for an exact settlement. The protocol does not set a limit for the amount that a client pays. The client software or the wallet must apply the limits.
Procedure Pay for a resource with x402 (client)
Send the request to the server.
If the server sends status 402, read the PAYMENT-REQUIRED header.
Decode the header. Find the payment option that your wallet supports.
Make sure that the amount and the payTo address are correct.
Sign the payment with your key.
Send the request again. Put the signed payment in the PAYMENT-SIGNATURE header.
Read the PAYMENT-RESPONSE header. Keep the transaction identifier.
Procedure Accept an x402 payment (server)
Configure each paid route with a price, a network, an asset and a payTo address.
Select a facilitator that supports your scheme and your network.
If a request has no PAYMENT-SIGNATURE header, send status 402.
Put the payment requirements in the PAYMENT-REQUIRED header.
If a request has a PAYMENT-SIGNATURE header, decode the payment payload.
Send the payment payload and your payment requirements to the /verify endpoint of the facilitator.
If the facilitator rejects the payment, send status 402 again.
If the payment is valid, run the handler.
Send the same data to the /settle endpoint of the facilitator.
Put the settlement result in the PAYMENT-RESPONSE header.
Send the response to the client.
Procedure Verify and settle a payment (facilitator)
Decode the payment payload and the payment requirements from the request.
Make sure that the scheme and the network agree with the payment requirements.
Get the address of the signer from the EIP-712 signature.
Make sure that the to value of the authorization is equal to payTo.
Make sure that the value of the authorization is equal to the amount.
Make sure that the time now is after validAfter and before validBefore.
Read the balance of the payer and the state of the nonce.
If a check fails, send isValid as false with the error code.
When the server calls /settle, do all of the checks again.
Send the transaction to the network. Keep the transaction identifier.
If you cannot get the receipt, send settlement_pending with the transaction identifier.
Technical nouns and technical verbs
facilitator: A server that verifies a payment and sends it to the network. It does not keep the money.
resource server: The HTTP server that sells a resource and sends the payment requirements.
payment requirements: The list of payment options that the server accepts, with the scheme, network, amount, asset and payTo address.
payment payload: The signed payment that the client sends in the PAYMENT-SIGNATURE header.
exact scheme: A scheme that moves one fixed amount one time. It has no refund.
upto scheme: A scheme where the client signs a maximum amount and the server collects the measured amount.
auth-capture: A scheme that holds the money first, then collects it. It can return the money.
payment flow: The order of the verify step, the handler and the settle step.
nonce: A random value that the token contract accepts one time only.
settlement: The transfer of money on the network.
verify (TV): To make sure that a payment is correct, without a change to the network.
settle (TV): To send a payment to the network so that the money moves.
STE check report
Sentences
83
Longest procedural sentence
16 words (limit 20)
Longest descriptive sentence
18 words (limit 25)
Flags
None
Written to the public ASD-STE100 Issue 9 writing rules. Vocabulary not checked against the official dictionary.
Compare with the practitioner text side by side
Practitioner text (section B)
x402 answers one question: how does a server charge for a single HTTP request without accounts, API keys or invoices? The server replies 402 with a header that lists what it accepts: a scheme, a network, an amount, an asset and a payee address. The client signs a payment that matches one of those entries and retries the same request with the signature in a header. The server never touches a chain itself. It hands the signature to a facilitator, which checks it (verify), lets the server respond, then submits it on-chain (settle). The client's signature binds the amount and the recipient, so a facilitator cannot redirect funds, and a nonce with a validity window stops replays. What x402 does not give you: refunds under the exact scheme, a dispute process, or any statement about who the client is. Those live in other layers: the auth-capture scheme, ERC-8004, or your own policy.
x402 is an open payment standard that puts payment inside an ordinary HTTP (Hypertext Transfer Protocol) request and response, using the status code 402 Payment Required. Its repository says it aims to cover crypto and fiat networks alike, but the bindings written so far are almost all blockchains, plus Lightning and one credit-backed network run by Cloudflare. The design came out of Coinbase Developer Platform (CDP): the whitepaper is dated 2025-05-06 and credits Erik Reppel and five co-authors.
Simplified Technical English
x402 is an open protocol for payments in HTTP. A server uses status 402 to tell a client the price of a resource. The client signs a payment and sends the request again. A facilitator verifies the payment and then sends it to the network. Coinbase started x402 in 2025. The x402 Foundation of the Linux Foundation now controls the protocol.
x402 has three roles. The client signs the payment. The resource server sells the resource and sends the payment requirements. The facilitator verifies the payment and starts the settlement on the network. The facilitator does not keep the money of the client.
Version 2 is the current version. It uses three HTTP headers: PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE. Version 1 used a different set of headers.
E. Main personas
API, data or compute seller
Runs the resource server: prices routes, answers 402, and asks a facilitator to verify and settle. Source [10, 14, 53, 58, 59, 97]
Goals
Charge per call without accounts or invoices
Get paid in the same request that serves the data
Keep chain work out of the API team's code
Pains
Picking a facilitator for production because the x402.org default serves testnets only
Handler work that is lost when a settle fails under the authorization flow
Timeouts on /settle that leave the outcome unknown
Implements
Payment middleware such as @x402/express with a route map of accepts entries
An x402ResourceServer wired to an HTTPFacilitatorClient
Reconciliation for settlement_pending results
Must trust
The facilitator to verify honestly and broadcast promptly
The asset contract to enforce the nonce and the window
Its own route matching (past releases fixed encoded-path bypasses)
Questions, first steps, metrics and a day in the life
Questions they ask
Which facilitator supports my network and scheme, and what does it charge?
Do I need exact, upto or auth-capture for this endpoint?
What happens to my handler output if the settle fails?
First three steps
Run the @x402/express quick start against Base Sepolia with the x402.org facilitator
Price one route at $0.01 and watch the PAYMENT-REQUIRED header
Choose a production facilitator and compare its fees and networks
Metrics they care about
Paid requests per day
Verify and settle latency
Settle failure and settlement_pending rate
Revenue net of facilitator fees
A day in the life
Maya runs a weather API that used to sell monthly keys. She adds the Express middleware, prices the forecast route at one cent in USDC on Base, and points it at a facilitator. The first agent request gets a 402 with the price in a header; the retry carries a signature, the facilitator says it is valid, her handler runs, and the settle returns a transaction hash. On Friday a facilitator outage turns into a burst of 502 answers, and two settles time out. She checks both hashes on chain before retrying, finds one already confirmed, and writes a small reconciliation job so it never needs a person again.
Builds the client side: an agent or app that meets 402 responses, chooses an option, signs and retries. Source [22, 37, 42, 49, 98]
Goals
Let an agent pay for data and tools without a sign-up per vendor
Keep the agent inside a budget
Keep receipts for every payment
Pains
Two wire formats (V1 and V2) in the wild
Deciding which accepts entry to pick across networks and assets
Spending limits that exist only in the SDK, not in the protocol
Implements
wrapFetchWithPaymentFromConfig from @x402/fetch with a registered scheme
spendControls and payment policies
Storage of PAYMENT-RESPONSE transaction hashes
Must trust
The server's PAYMENT-REQUIRED header, especially payTo
The wallet key store
The server to deliver after a settle
Questions, first steps, metrics and a day in the life
Questions they ask
Is this server on V1 or V2?
What cap should my agent have per payment and per day?
Can I get a refund if the response is useless?
First three steps
Wrap fetch with @x402/fetch and call a testnet endpoint
Set spendControls to a cap below $1 and test a refusal
Log every PAYMENT-RESPONSE hash with the request it paid for
Metrics they care about
Spend per task
Payments refused by policy
Failed or unpaid deliveries
Latency added by the 402 round trip
A day in the life
Dev builds a research agent that buys market data from five APIs. He wraps fetch with the x402 client and registers the exact EVM scheme for Base. The SDK already refuses unknown assets and anything above $1, so he lowers the cap to ten cents and adds a policy that skips Solana entries for now. One API still speaks V1 and answers with a JSON body; he registers the V1 client for that host. Every PAYMENT-RESPONSE hash goes into the task log next to the URL. When one provider returns empty data after payment, he finds there is no refund path under exact and moves that provider to a manual allowlist.
Operates the verify and settle service, pays gas, and publishes what it supports. Source [10, 41, 54, 63, 99]
Goals
Verify fast and settle reliably across networks
Recover gas and costs through fees
Avoid settling anything twice
Pains
Duplicate settlement races and Solana duplicate submissions
Keeping signer keys funded for gas
Sanctions screening and its legal exposure
Implements
POST /verify, POST /settle and GET /supported
Nonce and replay checks, simulation and settlement caches
KYT and OFAC screening where it chooses to offer it
Must trust
RPC providers and chain finality
The token contracts (EIP-3009, Permit2 proxies)
Resource servers to send their own requirements, not the client's echo
Questions, first steps, metrics and a day in the life
Questions they ask
Which schemes and networks do I list in /supported?
How do I make /settle idempotent across processes?
What do I return when a receipt never arrives?
First three steps
Run a self-facilitation example against a testnet
Implement the eight facilitator safety rules from the security literature
Publish /supported with signers per CAIP-2 family
Metrics they care about
Verify and settle success rates
Gas cost per settlement
settlement_pending share
Screening hits
A day in the life
Priya runs a facilitator for three EVM chains and Solana. Her /supported answer lists exact and upto on each chain and one signer per family. Most of her day is not cryptography but operations: keeping the gas wallets topped up, watching the share of settles that end as settlement_pending, and making sure a retried settle from a second worker cannot broadcast twice. A paper on facilitator safety rules lands, and she maps each rule to a test. Screening runs before every settle; when a payer address matches a sanctions list, the settle fails with a clear reason and the resource server returns 402 instead of the data.
Pays on its own within limits a human set, choosing among accepts entries per request. Source [10, 21, 49, 64]
Goals
Finish the task within budget
Pay only for what the task needs
Leave a verifiable trail
Pains
Prices that change between calls
Servers that take payment and return nothing useful
Altered 402 responses that name another payTo
Implements
Selection logic over accepts entries
Per-payment and per-task caps
Receipt keeping and stop rules
Must trust
Its wallet and key isolation
The policy its operator configured
The facilitator not to stall payments
Questions, first steps, metrics and a day in the life
Questions they ask
Is this payTo the seller I meant to pay?
Is the price within my cap?
Do I have a way back if the result is wrong?
First three steps
Check payTo against the expected seller before every signature
Refuse amounts above the configured cap
Record each transaction hash with the task step
Metrics they care about
Spend per completed task
Refusals by policy
Payments without useful delivery
A day in the life
The agent is asked to compile a report from paid sources overnight. Each fetch that returns 402 goes through the same checks: the network and asset are on its list, the amount is under five cents, and the payTo matches the address its operator pinned for that domain. One source suddenly asks for twenty cents; the agent refuses and notes it. Another returns a 402 whose payTo differs from the pinned one, so it stops and flags the domain. By morning it has spent a little over a dollar across ninety calls, and every payment in its log has a transaction hash a human can check.
Record keeping of PAYMENT-RESPONSE hashes and offers or receipts
Data minimization for resource metadata
Must trust
The facilitator's screening and its records
The stablecoin issuer
Product terms such as Cloudflare's merchant-of-record role in cloudflare:402
Questions, first steps, metrics and a day in the life
Questions they ask
Is our facilitator a money transmitter in our markets?
Who is merchant of record in each variant we use?
What personal data leaves our systems in resource descriptions?
First three steps
Map which facilitator screens what (the CDP facilitator runs OFAC and KYT checks)
Review section J for each market we sell in
Strip personal data from resource URLs and descriptions
Metrics they care about
Share of payments screened
Records retrievable per payment
Open regulatory questions per market
A day in the life
Lena reviews the plan to sell API calls through x402 in the US and the EU. The first thing she notices is what the protocol leaves out: no identity, no sanctions check, no dispute process. Screening therefore depends on the facilitator, and the team's chosen facilitator documents OFAC and KYT checks on every payment, which she records as a vendor control. She asks the engineers to stop putting customer names in resource descriptions, because those travel to the facilitator. For the credit-backed Cloudflare variant she notes that Cloudflare is merchant of record with its own terms, and she sends that contract to legal.
Builds independent controls around x402: budgets, allowlists, approvals and monitoring at the client, edge or facilitator. Source [10, 23, 49, 52, 90]
Goals
Enforce limits the protocol does not define
Act before a signature exists
Detect abuse from public data
Pains
Budgets are out of scope in the spec
On chain, x402 payments look like ordinary transfers
Each SDK has different hooks
Implements
Policies and hooks such as onBeforePaymentCreation and onBeforeSettle
payTo allowlists and per-task budgets
Monitoring on facilitator events and contract events
Must trust
The SDK to call its hooks in order
The facilitator to report outcomes accurately
Indexers that label payments
Questions, first steps, metrics and a day in the life
Questions they ask
Where can I stop a payment: before signing, at the edge, or at settle?
How do I tell x402 payments from other transfers?
Can I revoke a signed authorization before it settles?
First three steps
Add a policy that enforces a payTo allowlist before signing
Set validBefore windows as short as the use allows
Subscribe to settle outcomes and alert on unusual spend
Metrics they care about
Payments blocked before signing
Time from anomaly to block
Coverage of agents under a policy
A day in the life
Omar's team sells a spend-control layer to companies that run agents. For x402 his main lever is the client: a policy hook that runs before the payment is created, checks payTo against an allowlist, enforces a daily budget per agent, and refuses unknown assets. A second lever is short validity windows, because a signed authorization cannot be recalled once it leaves the agent. On the seller side he offers hooks before verify and settle. Monitoring is harder: on chain the payments look like ordinary token transfers, so he relies on the facilitator's records and builder codes where sellers use them.
Frames the buyer side of x402 as a decision problem, selecting among payable providers under a finite wallet with feedback only on chosen purchases, and proposes 402Pilot, a protocol-agnostic decision layer instantiated with a payment-aware discounted contextual Thompson-sampling policy. On the 402Pilot-Bench replay benchmark (823 tasks, five provider pipelines, three market regimes) it keeps service quality while spending 39 to 43 percent of the wallet.
Why it matters here: Treats x402 as settled infrastructure and asks how an agent should decide what to buy over it; a bridge between the payment rail and agent economics. x402: A decision layer for when an agent should pay an x402 price.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{li2026402pilot,
title = {{402Pilot: An x402 Decision Layer for Autonomous Agent Micropayments}},
author = {Yin Li and Yanbo He and Boo-Ho Yang and Rav Lawana and Ziyue Li and Wei Zeng and Jing Tang and Fugee Tsung},
year = {2026},
eprint = {2608.01341},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2608.01341}
}
Builds Tamarin models of x402, MPP, ACP and AP2 from their specifications, schemas and reference code using one shared abstraction of the agent payment lifecycle, then asks source-backed verification questions to expose missing bindings and cross-stage correspondences, which it consolidates into 18 security principles. Across 86 verification cases it reproduces 46 known or calibration cases, reports 40 new formal-consistency findings, and validates ten of them against x402 implementations with proofs of concept.
Why it matters here: The only side-by-side formal model of x402, stripe-mpp, openai-acp and ap2 so far; it shows where each specification leaves delegated authority, settlement and fulfillment unbound. AP2: Tamarin models that include AP2. ERC-8004: Trustless Agents: Formal models of agent payment protocols around ERC-8004. Agentic Commerce Protocol (ACP): Models ACP in Tamarin with x402, MPP and AP2; the only formal analysis that names it. Stripe MPP (Machine Payments Protocol): Models MPP in Tamarin alongside x402, ACP and AP2; the only formal analysis that names MPP. UCP: Formal analysis of agent payment protocols; the abstract does not name UCP but analyzes AP2, which UCP embeds as an extension. x402: Formal Tamarin models of x402 alongside MPP, ACP and AP2.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{jiang2026formal,
title = {{A Formal Analysis of Agent Payment Protocols}},
author = {Ke Jiang and Mohan Yu and Yuan Chang and Mohit Kumar Jangid and Jianyu Niu and Cong Wang and Yinqian Zhang},
year = {2026},
eprint = {2609.00060},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.00060}
}
Proposes A402, a payment architecture that binds cryptocurrency payments to service execution through Atomic Service Channels and TEE-assisted adaptor signatures, so that payment finalizes only if the requested service is executed and delivered, with a TEE-based liquidity vault aggregating channel settlements on chain. Evaluated against x402 on Bitcoin and Ethereum integrations.
Why it matters here: Addresses the end-to-end atomicity gap that x402 leaves open, and connects agent micropayments to the payment-channel lineage. Stripe MPP (Machine Payments Protocol): Binding payment to service execution, the gap MPP's charge intent addresses only by forbidding delivery before verification. x402: Shows that x402 does not bind payment to service execution and proposes Atomic Service Channels.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{li2026a402,
title = {{A402: Binding Cryptocurrency Payments to Service Execution for Agentic Commerce}},
author = {Yue Li and Lei Wang and Kaixuan Wang and Zhiqiang Yang and Ke Wang and Zhi Guan and Jianbo Gao},
year = {2026},
eprint = {2603.01179},
archivePrefix = {arXiv},
primaryClass = {cs.DC},
url = {https://arxiv.org/abs/2603.01179}
}
A chapter-length treatment of agent-to-agent finance as a layer of machine-mediated financial interaction in which agents discover counterparties, express intent, pay and generate auditable evidence, drawing on blockchain agent-to-agent payment work, ERC-8004 registries, provenance-based wallets and official evidence on AI adoption in finance. Its central design question is bounded autonomy.
Why it matters here: Positions erc-8004 and blockchain agent payments such as x402 as candidate financial market infrastructure and sets out the accountability questions regulators will ask.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{gong2026a2afinance,
title = {{Agent-to-Agent Finance: Blockchain Payments and Trust Infrastructure for Autonomous AI Agents}},
author = {Hui Gong},
year = {2026},
eprint = {2607.00245},
archivePrefix = {arXiv},
primaryClass = {q-fin.GN},
url = {https://arxiv.org/abs/2607.00245}
}
Proposes the Agentic Settlement Protocol, an application profile over on-chain authorize-and-capture escrow for purchases whose fulfillment is confirmed off-chain, with a three-deadline hold model, a fulfillment-verification ladder, engine-authoritative partial refunds with per-seller exposure controls, and a normative interface that includes an x402 scheme and a vault ABI; it is a design paper instantiated on the XDC Network, with evaluation deferred to follow-up work. The arXiv author metadata splits the first author's name into two single-word entries; it is recorded here as one name, as it appears on the abstract page.
Why it matters here: Argues that x402's atomic, final payments fit metered access but not refundable commerce, and shows how an escrow profile can still be exposed as an x402 scheme. x402: An application profile for refundable, delayed-fulfillment payments, a gap in x402 exact.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{mohammadkhani2026asp,
title = {{Agentic Settlement Protocol: An Application Profile for Refundable, Delayed-Fulfilment Agent Commerce on Stablecoin Rails}},
author = {Behnam Mohammadkhani and Atul Khekade and Ritesh Kakkad},
year = {2026},
eprint = {2609.02208},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.02208}
}
Defines agentic payments as transactions started and completed by AI agents, sets out how they work across retail, e-commerce and decentralized finance, and classifies their technical, legal and societal risks, including liability gaps and regulatory non-compliance.
Why it matters here: One of the few peer-reviewed legal analyses aimed at agent payments specifically, useful for the compliance and liability questions every protocol in the atlas leaves to implementers. AP2: Risks and regulation of agent payments. Mastercard Agent Pay: Survey of risks and regulation for AI agents in payments that covers card-network programs. Agentic Commerce Protocol (ACP): Risks and regulation of AI agents in payments, covering ACP.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@article{amariles2026payments,
title = {{AI Agents in Payments: Applications, Risks and Regulations}},
author = {David Restrepo Amariles and Damien Charlotin and Liyun He-Guelton},
year = {2026},
journal = {European Journal of Risk Regulation},
volume = {17},
number = {3},
pages = {884--907},
publisher = {Cambridge University Press},
doi = {10.1017/err.2026.10103},
url = {https://doi.org/10.1017/err.2026.10103}
}
First empirical study of ERC-8004 on Ethereum, BNB Smart Chain and Base from deployment through 2026-05-13, crawling Identity and Reputation Registry events, registration files and associated x402 payments. Only 3%, 4% and 15% of registrations on the three chains expose a valid registration file with a live endpoint, reputation values are not commensurable and are cheap to manipulate, and 73.5%, 59.2% and 90.6% of reviewers show coordinated Sybil behavior; removing flagged feedback leaves 15.8%, 77.9% and 86.8% of rated agents with no valid feedback.
Why it matters here: Primary evidence for the disputed status of erc-8004 reputation data and for the gap between registrations and operational agents; it also links x402 settlements to registered identities. ERC-8004: Trustless Agents: The main measurement of ERC-8004 in practice: liveness and Sybil reviewers on three chains.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{xiong2026trustless,
title = {{Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem}},
author = {Xihan Xiong and Zelin Li and Wei Wei and Qin Wang and William Knottenbelt and Zhipeng Wang},
year = {2026},
eprint = {2606.26028},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2606.26028}
}
Introduces Capability-Priced Micro-Markets, combining Project NANDA capability-based discovery, HTTP 402 micropayments with x402 and H402 extensions, and the Agent Capability Negotiation and Binding Protocol into a repeated bilateral game with incomplete information, shown to converge to a constrained Radner equilibrium, and defines a privacy elasticity of demand.
Why it matters here: A micro-economic model of markets priced over x402-style HTTP 402 payments.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{huang2026cpmm,
title = {{Capability-Priced Micro-Markets: A Micro-Economic Framework for the Agentic Web over HTTP 402}},
author = {Ken Huang and Jerry Huang and Mahesh Lambe and Hammad Atta and Yasir Mehmood and Muhammad Zeeshan Baig and Muhammad Aziz Ul Haq and Nadeem Shahzad and Shailja Gupta and Rajesh Ranjan and Rekha Singhal},
year = {2026},
eprint = {2603.16899},
archivePrefix = {arXiv},
primaryClass = {cs.GT},
url = {https://arxiv.org/abs/2603.16899}
}
Describes a compliance-aware architecture that combines x402-style signature-based payment authorization and relayed execution with programmable compliance enforced on chain through a policy wrapper and a policy manager coordinating modular checks, so settlement stays low-friction when conditions are met and transaction-linked attestations are recorded. The arXiv comment labels it a demo-track paper, but no venue is confirmed.
Why it matters here: Shows one route to adding regulatory checks to x402 settlement at execution time rather than in an off-chain workflow. x402: Compliance-aware agent payments on stablecoin rails, relevant to facilitator screening.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{see2026compliance,
title = {{Compliance-Aware Agentic Payments on Stablecoin Rails}},
author = {Kenneth See and Xue Wen Tan},
year = {2026},
eprint = {2605.00071},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2605.00071}
}
Extends the A2A protocol with ledger-anchored identities, publishing AgentCards on chain as smart contracts for verifiable discovery, and with x402 micropayments so that agents can discover, authenticate and pay one another across organizational boundaries; includes an implementation and evaluation. Published in Springer CCIS from IJCCI 2025 under the title given here; the arXiv preprint (2507.19550, 2025) carries the longer title 'Towards Multi-Agent Economies: Enhancing the A2A Protocol with Ledger-Anchored Identities and x402 Micropayments for AI Agents'.
Why it matters here: Peer-reviewed design that pairs x402 with on-chain agent identity, the same combination that erc-8004 plus x402 deployments pursue. ERC-8004: Trustless Agents: Ledger-anchored identity with A2A and x402, before ERC-8004. x402: Combines A2A with ledger-anchored identities and x402 micropayments.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{vaziry2026a2ax402,
title = {{Enhancing the A2A Protocol with Blockchain-Based Identities and x402 Micropayments for Agentic AI}},
author = {Awid Vaziry and Sandro Rodriguez Garzon and Axel Küpper},
year = {2026},
booktitle = {Computational Intelligence (IJCCI 2025), Communications in Computer and Information Science, vol. 2827},
publisher = {Springer Nature Switzerland},
series = {Communications in Computer and Information Science},
pages = {454-472},
doi = {10.1007/978-3-032-15632-7_25},
eprint = {2507.19550},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2507.19550}
}
Formalizes x402 and demonstrates five practical attacks on authorization, binding, replay protection and web-layer handling, validated on local chains, Base Sepolia and live endpoints, plus an audit of three open-source SDKs and endpoints. The attacks yield either unpaid service or paid-but-denied outcomes, and the paper proposes mitigations.
Why it matters here: Direct attack catalog for x402 that spans the HTTP layer and the on-chain settlement layer. x402: Five practical attacks and an audit of three x402 SDKs; the main source for section H.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{li2026fiveattacks,
title = {{Five Attacks on x402 Agentic Payment Protocol}},
author = {Zelin Li and Qin Wang and Zhipeng Wang},
year = {2026},
eprint = {2605.11781},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2605.11781}
}
Analyzes x402 as a stack of HTTP semantics, per-chain schemes and SDK choices against five invariants and finds four flaw classes: cross-resource substitution, duplicate-settlement races, allowance overdraft and denial of settlement, reaching resource-leakage ratios up to 100% against official SDKs and a production deployment. It also proves that output-only pay-per-token pricing cannot be both fair and bounded against hidden reasoning-token inflation, and proposes mitigations with provable guarantees.
Why it matters here: Explains the state-synchronization gap between synchronous HTTP and asynchronous settlement that is specific to x402-style rails. Stripe MPP (Machine Payments Protocol): x402 free-riding attacks that map onto MPP charge implementations. x402: Four flaw classes, including cross-resource substitution and a duplicate settlement race.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{ling2026freeriding,
title = {{Free-Riding the Agentic Web: A Systematic Security Analysis of x402 Payments}},
author = {Shengchen Ling and Yihang Huang and Yuefeng Du and Yuan Chen and Yajin Zhou and Lei Wu and Cong Wang},
year = {2026},
eprint = {2605.30998},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2605.30998}
}
Presents presidio-hardened-x402, open-source middleware that intercepts x402 payment requests before transmission to redact personally identifiable information from payment metadata, enforce declarative spending policies and block replays. On a synthetic corpus of 2,000 metadata triples the recommended NLP mode reaches a micro-F1 near 0.9 at p99 latency under 6 ms; version 2 of the preprint revises the threshold and headline numbers.
Why it matters here: Highlights that x402 metadata travels to facilitators without data processing agreements, a privacy control gap in the protocol as deployed. x402: Treats x402 payment metadata as a PII channel and proposes filtering middleware.
Population-scale measurement of x402 on Base over a 280-day window (136,708,672 settlements worth about 44.1 million dollars) with a coarser Solana census. Resolving the true payer through the meta-transaction layer, the authors classify 21.20% of settlements as fictitious and 63.78% as internal to a linked cluster, bound genuinely independent value between about 188 thousand and 20.3 million dollars, and conclude that the settlement count measures manufacturability rather than adoption.
Why it matters here: The main source for the dispute over x402 volume authenticity; any x402 metric on the atlas should be shown alongside this analysis. x402: Population-scale measurement that questions x402 volume figures.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{ling2026howagentic,
title = {{How Agentic Is Agentic Commerce? A Population-Scale Measurement of x402 Adoption and Authenticity}},
author = {Shengchen Ling and Yajin Zhou and Lei Wu and Cong Wang},
year = {2026},
eprint = {2607.12575},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2607.12575}
}
A vision paper arguing that once buyers are agents paying over agent-native rails such as x402 and AP2, the scarce resource becomes trustworthy product information rather than product matching. It sketches a market in which buyer agents pay fractions of a cent to unlock seller- and reviewer-supplied evidence, with reviewer trust scored reputationally, and lists the NLP problems this creates.
Why it matters here: Names x402 and AP2 directly as the rails that make per-fact micropayments feasible, and ties paid information to the reputation scoring that ERC-8004 registries aim to provide. Stripe MPP (Machine Payments Protocol): Micro-transaction markets for product information, a use case for per-request MPP charges.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{ventirozos2026paying,
title = {Paying to Know: Micro-Transaction Markets for Verified Product Information in Agentic E-Commerce},
author = {Filippos Ventirozos and Matthew Shardlow},
year = {2026},
eprint = {2606.24783},
archivePrefix = {arXiv},
primaryClass = {cs.CL},
url = {https://arxiv.org/abs/2606.24783},
note = {arXiv preprint}
}
Defines the agentic clearing problem, deciding whether an agent met its delegated obligation and which settlement action follows, and argues that MCP, A2A, x402, AP2 and the Visa and Mastercard network agent protocols all assume that determination without producing it. RAILS specifies seven primitives and a formal model of admissibility-graded verification yielding a soundness property that no financially material settlement rests on evidence below the obligation's admissibility floor. The abstract names Visa and Mastercard generically rather than by protocol name.
Why it matters here: Names x402, ap2 and the Visa and Mastercard agent programs as rails that lack a clearing layer; useful for the atlas comparison of where disputes and fulfillment evidence live. Visa Trusted Agent Protocol: The only paper found that names TAP; places it as the network's edge attestation layer.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{valoisfranklin2026rails,
title = {{RAILS: Verification-Native Clearing For Agentic Commerce}},
author = {Adrian de Valois-Franklin and Alex Bogdan},
year = {2026},
eprint = {2606.08790},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2606.08790}
}
Systematizes blockchain-based agent-to-agent payments, with x402 as the lead example, into a four-stage lifecycle of discovery, authorization, execution and accounting, classifies representative designs at each stage, and isolates recurring weaknesses: weak intent binding, misuse under valid authorization, payment-service decoupling and limited accountability.
Why it matters here: Gives a lifecycle vocabulary for x402 and for the discovery role that erc-8004 registries are meant to fill, and names the payment-service decoupling problem that later x402 attack papers exploit. ERC-8004: Trustless Agents: Survey that places ERC-8004 among agent payment components. Stripe MPP (Machine Payments Protocol): Systematizes blockchain agent-to-agent payments; does not name MPP but covers the Tempo-style rails. x402: Systematizes blockchain agent-to-agent payments, with x402 as a central case.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{zhang2026sok,
title = {{SoK: Blockchain Agent-to-Agent Payments}},
author = {Yuanzhe Zhang and Yuexin Xiang and Yuchen Lei and Qin Wang and Tian Qiu and Yujing Sun and Spiridon Zarkov and Tsz Hon Yuen and Andreas Deppeler and Jiangshan Yu and Kwok-Yan Lam},
year = {2026},
eprint = {2604.03733},
archivePrefix = {arXiv},
primaryClass = {q-fin.GN},
url = {https://arxiv.org/abs/2604.03733}
}
A systematization of knowledge that frames the security of autonomous LLM agents in commerce along five dimensions (agent integrity, transaction authorization, inter-agent trust, market manipulation, regulatory compliance), derives 12 cross-layer attack vectors from a curated corpus of papers, protocol documents, industry reports and incidents, and proposes a layered defense for the authorization gaps in current agent payment protocols. The ACP it lists is written 'Agent Commerce Protocol', which may not be OpenAI's Agentic Commerce Protocol; that mapping is unconfirmed.
Why it matters here: Places erc-8004, ap2, x402 and stripe-mpp in one threat framework and argues that their authorization gaps compound across the reasoning, tooling, custody and settlement layers. AP2: Places AP2 among agent commerce attack vectors. Stripe MPP (Machine Payments Protocol): Includes MPP in its protocol set for agent commerce security. x402: Security SoK of agentic commerce that covers x402.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{mao2026sok,
title = {{SoK: Security of Autonomous LLM Agents in Agentic Commerce}},
author = {Qian'ang Mao and Jiaxin Wang and Ya Liu and Li Zhu and Cong Ma and Jiaqi Yan},
year = {2026},
eprint = {2604.15367},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2604.15367}
}
A dynamic model in which an agent's reputation is capital that attracts future demand, and the agent chooses each period between honest operation, investing in quality, or a one-shot deviation that cashes out the reputation and restarts under a penalized new identity. The temptation depends on identity-reset cost, reputation persistence, demand sensitivity and enforcement design; ERC-8004, ERC-8183 and x402 are named as the motivating infrastructure.
Why it matters here: Names ERC-8004 and x402 directly and states the economic condition under which an on-chain reputation registry disciplines agents: resetting an identity must cost more than the one-shot gain from burning it. ERC-8004: Trustless Agents: Economics of reputation when identities are cheap.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{gatta2026tempting,
title = {Tempting the Agent: The Economics of Reputation without Persistent Identity in AI Agent Markets},
author = {Federico Gatta and Manuel Naviglio and Francesco Tarantelli},
year = {2026},
eprint = {2609.02992},
archivePrefix = {arXiv},
primaryClass = {q-fin.GN},
url = {https://arxiv.org/abs/2609.02992},
note = {arXiv preprint}
}
Large-scale empirical study of the Web4 agent economy built on MCP, x402 and EIP-8004 (ERC-8004), analyzing 99,448 multi-chain identity registrations, 317,596,323 transaction logs, the source code of 341 MCP projects and 349 GitHub issues. It finds a highly active machine-to-machine payment economy with millions of daily transactions resting on immature identity, authorization and interoperability practice, with payment interoperability the most persistent bottleneck.
Why it matters here: Measurement of erc-8004 registrations and x402 transaction volume from a software-engineering angle; read it together with the authenticity analyses before quoting volume figures.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{jin2026web4,
title = {{The Web4 Agent Economy: A Large-Scale Empirical Study of the Landscape, Challenges, and Opportunities}},
author = {Yuhan Jin and Shuohan Wu and Chong Chen and Lingfeng Bao and Xiaohu Yang and Jiachi Chen},
year = {2026},
eprint = {2606.25876},
archivePrefix = {arXiv},
primaryClass = {cs.SE},
url = {https://arxiv.org/abs/2606.25876}
}
Studies facilitator-mediated x402 deployments in the wild, derives eight security rules for facilitators and four attack vectors (Free Shopping, Asset Theft, Service Denial, Gas Abuse), and applies a semi-automated black-box tool to 15 facilitators serving over 60,000 sellers and 360,000 buyers, finding violations in all of them. Findings were disclosed and mitigated, including changes by Coinbase, and the paper adds a measurement of more than 119 million Base and Solana transactions. Listed on the USENIX Security 2026 technical sessions page (accessed 2026-10-10).
Why it matters here: Peer-reviewed evidence that the x402 facilitator is a shared trust point whose flaws affect many merchants at once, plus adoption and centralization metrics. x402: Studies facilitator-mediated deployments and proposes eight safety rules for facilitators.
Metadata verified 2026-10-10 through publisher.
Show BibTeX
@inproceedings{wang2026http402,
title = {{When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments}},
author = {Qinying Wang and Yong Yang and Yuan Chen and Shouling Ji and Mathias Payer},
year = {2026},
booktitle = {USENIX Security Symposium (USENIX Security 2026)},
publisher = {USENIX Association},
eprint = {2607.19545},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2607.19545}
}
Introduces TraceRank, a reputation-weighted ranking for x402-enabled services in which payment transactions act as endorsements, seeded with precomputed reputation and propagated through the payment graph weighted by value and recency, then combined with semantic search. The authors argue that this resists Sybil spam because many low-reputation payers rank below a few high-reputation ones.
Why it matters here: An early proposal for discovery and reputation over the x402 payment graph, the same problem that erc-8004 reputation registries target. x402: Uses the x402 payment graph for Sybil-resistant service discovery.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{shi2025sybil,
title = {{Sybil-Resistant Service Discovery for Agent Economies}},
author = {David Shi and Kevin Joo},
year = {2025},
eprint = {2510.27554},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2510.27554}
}
Unifies persistent identity, scoped delegation, peer trust, discovery and payment over Nostr relays with three custom event kinds (identity declarations with BIP340 Schnorr signatures and pre-rotation commitments, scoped delegation chains that narrow at each hop, and peer attestations forming a Sybil-deterrent trust graph), with Lightning L402 payments bound to agent identity. A Python prototype shows sub-millisecond offline verification and 157 ms median L402 settlement on regtest. The arXiv comment reports acceptance at AGENTICS 2026 (IJCCI 2026) for Springer CCIS; no publisher record confirms it yet.
Why it matters here: A registry-free alternative to erc-8004 identity and reputation, paired with L402, the Lightning cousin of x402.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{larsen2026nostragent,
title = {{NostrAgent: A Decentralized Identity and Delegation Architecture for Sovereign Agentic Systems}},
author = {Oliver Aleksander Larsen and Mahyar Tourchi Moghaddam},
year = {2026},
eprint = {2609.22944},
archivePrefix = {arXiv},
primaryClass = {cs.SE},
url = {https://arxiv.org/abs/2609.22944}
}
Surveys agent communication protocols with a two-dimensional classification (context-oriented versus inter-agent, general-purpose versus domain-specific), compares them on security, scalability and latency, and lays out directions such as layered architectures, privacy preservation and group interaction.
Why it matters here: Provides the taxonomy into which payment and commerce protocols (x402, AP2, ACP, UCP) slot as domain-specific layers above MCP and A2A. UCP: Survey of AI agent protocols for orientation.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{yang2025protocols,
title = {A Survey of AI Agent Protocols},
author = {Yingxuan Yang and Huacan Chai and Yuanyi Song and Siyuan Qi and Muning Wen and Ning Li and Junwei Liao and Haoyi Hu and Jianghao Lin and Gaowei Chang and Weiwen Liu and Ying Wen and Yong Yu and Weinan Zhang},
year = {2025},
eprint = {2504.16736},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2504.16736},
note = {arXiv preprint}
}
Describes the NANDA index architecture in which a lean index resolves to cryptographically verifiable AgentFacts supporting multi-endpoint routing, sub-second revocation and key rotation, schema-validated capability assertions and privacy-preserving discovery, with a CRDT-based update protocol and prototype resolvers.
Why it matters here: Another discovery and identity layer competing with erc-8004 registries; relevant to how agents find x402-priced services.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{raskar2025nanda,
title = {{Beyond DNS: Unlocking the Internet of AI Agents via the NANDA Index and Verified AgentFacts}},
author = {Ramesh Raskar and Pradyumna Chari and John Zinky and Mahesh Lambe and Jared James Grogan and Sichao Wang and Rajesh Ranjan and Rekha Singhal and Shailja Gupta and Robert Lincourt and Raghu Bala and Aditi Joshi and Abhishek Singh and Ayush Chopra and Dimitris Stripelis and Bhuwan B and Sumit Kumar and Maria Gorskikh},
year = {2025},
eprint = {2507.14263},
archivePrefix = {arXiv},
primaryClass = {cs.NI},
url = {https://arxiv.org/abs/2507.14263}
}
Proposes Sprites, a payment channel construction for smart-contract chains that cuts the worst-case time collateral is locked along a multi-hop route and supports partial deposits and withdrawals without closing the channel. It also gives a modular treatment of general state channels.
Why it matters here: A key reference for channel designs on Ethereum-style chains, where x402 settles; it explains the collateral and dispute costs any channel-based agent payment scheme must budget for. Stripe MPP (Machine Payments Protocol): Payment channel foundations behind MPP sessions.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{miller2017sprites,
title = {{Sprites and State Channels: Payment Networks that Go Faster than Lightning}},
author = {Andrew Miller and Iddo Bentov and Ranjit Kumaresan and Christopher Cordi and Patrick McCorry},
year = {2017},
eprint = {1702.05812},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/1702.05812}
}
Joseph Poon, Thaddeus Dryja. 2016. Not peer reviewed
The white paper (draft version 0.5.9.2, dated 2016-01-14) for a network of bidirectional payment channels in which transfers happen off chain and are routed across channels with hashed timelock contracts, so only channel opening and closing touch the blockchain.
Why it matters here: Payment channels are the main route to cheap, fast repeated payments; the deferred and session schemes discussed for x402 and MPP inherit the channel model this paper popularized. Stripe MPP (Machine Payments Protocol): Foundation for the lightning method and for cumulative channel updates.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{poon2016lightning,
title = {{The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments}},
author = {Joseph Poon and Thaddeus Dryja},
year = {2016},
howpublished = {White paper, draft version 0.5.9.2},
note = {Not peer reviewed},
url = {https://lightning.network/lightning-network-paper.pdf}
}
Adapts probabilistic micropayments to decentralized currencies such as Bitcoin, designing schemes where a payer issues lottery-style tickets and only winning tickets are settled on chain, with protections against a payer who double-spends the escrow.
Why it matters here: Links the 1990s micropayment literature to blockchain settlement, the setting in which x402 operates and in which MPP offers on-chain payment methods. Stripe MPP (Machine Payments Protocol): Micropayments for decentralized currencies.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{pass2015decentralized,
title = {{Micropayments for Decentralized Currencies}},
author = {Rafael Pass and abhi shelat},
year = {2015},
booktitle = {Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security},
pages = {207--218},
publisher = {ACM},
doi = {10.1145/2810103.2813713},
url = {https://doi.org/10.1145/2810103.2813713}
}
Proposes paying for many small items with electronic lottery tickets: each ticket wins a larger payment with small probability, so the expected value equals the price while the number of real transactions drops sharply.
Why it matters here: Probabilistic payment is one of the standing answers to per-request fees that are smaller than settlement cost, a problem x402 and MPP face whenever an agent buys thousands of cheap API calls. Stripe MPP (Machine Payments Protocol): Probabilistic micropayments, an alternative to channels.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{rivest1997lottery,
title = {{Electronic lottery tickets as micropayments}},
author = {Ronald L. Rivest},
year = {1997},
booktitle = {Financial Cryptography},
series = {Lecture Notes in Computer Science},
pages = {307--314},
publisher = {Springer},
doi = {10.1007/3-540-63594-7_87},
url = {https://doi.org/10.1007/3-540-63594-7_87}
}
Introduces two micropayment schemes: PayWord, where a user commits to a hash chain and pays by revealing successive hash values, and MicroMint, where coins are hash collisions that are cheap to verify but costly to mint at scale. Both aim to make each payment far cheaper than a public-key signature.
Why it matters here: The hash-chain idea behind PayWord is the template for streaming and session payments; MPP sessions and payment channels used with x402 apply the same principle of one setup and many cheap increments. Stripe MPP (Machine Payments Protocol): Cumulative micropayment tokens, an ancestor of cumulative vouchers.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{rivest1997payword,
title = {{PayWord and MicroMint: Two simple micropayment schemes}},
author = {Ronald L. Rivest and Adi Shamir},
year = {1997},
booktitle = {Security Protocols},
series = {Lecture Notes in Computer Science},
pages = {69--87},
publisher = {Springer},
doi = {10.1007/3-540-62494-5_6},
url = {https://doi.org/10.1007/3-540-62494-5_6}
}
Steve Glassman, Mark Manasse, Martín Abadi and others. 1995. Fourth International World Wide Web Conference (WWW4). Peer reviewed
Describes Millicent, a protocol for web purchases below one cent in which brokers sell vendor-specific scrip that each vendor can validate locally, without extra network round trips or heavy cryptography. Brokers handle accounts and billing so vendors and customers do not need direct financial relationships.
Why it matters here: The direct ancestor of pay-per-request web payments: x402 and MPP revisit the same goal of charging tiny amounts per HTTP resource, with stablecoins and facilitators in the broker role.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@inproceedings{glassman1995millicent,
title = {{The Millicent Protocol for Inexpensive Electronic Commerce}},
author = {Steve Glassman and Mark Manasse and Martín Abadi and Paul Gauthier and Patrick Sobalvarro},
year = {1995},
booktitle = {Fourth International World Wide Web Conference},
address = {Boston, MA, USA},
url = {https://www.w3.org/Conferences/WWW4/Papers/246/}
}
Extracts a verified finite-state machine (37 states and 76 transitions from 929 formalized statements) from the A2A specification with LLM assistance and reasons over it to find 11 protocol-level vulnerabilities exploitable by specification-compliant adversaries, including cross-client context injection, credential harvesting through identity loss in multi-hop delegation chains, and exfiltration through unattested capability claims.
Why it matters here: ap2 and the a2a-x402 extension are layered on A2A, so specification-level flaws in A2A delegation and identity flow directly into their trust assumptions.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{lotfi2026a2abreak,
title = {{A2ABreak: Systematic Security Analysis of the A2A Protocol}},
author = {Alireza Lotfi and Mirza Masfiqur Rahman and Imtiaz Karim and Elisa Bertino},
year = {2026},
eprint = {2609.10871},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.10871}
}
Presents a fraud taxonomy for agents with spend authority organized by five observation levels, a benchmark of twenty fraud classes built from production aggregates (1,647 service operations and 1,068 settlements), and gordonguard, an open-source detector stack. Calibrated detectors flag 6.5 percent of clean traffic and leave eight classes at chance, and a median payment of $0.007 makes one human review 143 times costlier than the payment it checks.
Why it matters here: Targets fraud on machine-to-machine rails such as x402 and MPP, where a counterparty can be exactly who it claims to be and still overcharge, and shows why identity checks alone, including ERC-8004 identity, do not stop value loss.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{srivastava2026acb,
title = {Agentic Commerce Bench: Measuring Fraud Detection for Agents That Spend Money},
author = {Ankit Srivastava and Debjyoti Paul},
year = {2026},
eprint = {2609.35886},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.35886},
note = {arXiv preprint}
}
Introduces Invocation-Bound Capability Tokens, an append-only token chain that fuses identity, attenuated authorization and provenance binding, in a compact JWT mode and a chained Biscuit mode with Datalog policies for multi-hop delegation across MCP, A2A and HTTP. Python and Rust implementations add sub-millisecond overhead, and all 600 adversarial attempts were rejected.
Why it matters here: Delegation tokens for the A2A and MCP layers that ap2 and the a2a-x402 extension sit on, and a descendant of the Macaroons caveat model. AP2: Verifiable delegation across MCP and A2A.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{prakash2026aip,
title = {{AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A}},
author = {Sunil Prakash},
year = {2026},
eprint = {2603.24775},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2603.24775}
}
APEX adapts HTTP 402-style payment gating to UPI-like real-time fiat rails with a challenge-settle-consume lifecycle, HMAC-signed short-lived tokens, idempotent settlement and policy-governed spend approval; in six scenarios policy enforcement cut spending by 27.3% while blocking all replay and invalid-token attempts.
Why it matters here: Shows the x402 pattern without the cryptocurrency rail, relevant to regions where stablecoin settlement is impractical.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{uddin2026apex,
title = {{APEX: Agent Payment Execution with Policy for Autonomous Agent API Access}},
author = {Mohd Safwan Uddin and Mohammed Mouzam and Mohammed Imran and Syed Badar Uddin Faizan},
year = {2026},
eprint = {2604.02023},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2604.02023}
}
Replays 4,371 human-written attacks from a capture-the-flag event against a live payment agent across 14 models, five policy levels and two tracks, with and without a deterministic pre-action check implementing the author's Open Agent Passport specification. Transfers to recipients the passport did not permit occurred 140 times in 76,842 model-alone evaluations and zero times in 69,297 behind the layer, while 25,370 legitimate payments still executed.
Why it matters here: A benchmark of the authorization boundary that AP2 mandates, x402 payment headers and TAP delegation all depend on: deterministic policy enforcement outside the model stopped recipient hijacks that prompting alone did not. The Open Agent Passport is the author's own specification, so read the comparison with that in mind.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{uchibeke2026aport,
title = {APort Vault: Benchmarking AI Agent Payment Authorization with the Open Agent Passport},
author = {Uchi Uchibeke},
year = {2026},
eprint = {2609.22076},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.22076},
note = {arXiv preprint}
}
Develops Authority-Inference Separation, an architecture in which an agent's proposed financial action gains temporary executable authority only after a deterministic control plane validates registered identity, accountable ownership, mandate lineage, policy version and exact economic semantics, with blockchain enforcing granted authority and recording evidence. A 48-fixture prototype rejected all 36 synthetic authorization attacks, and a test of 1,700 Base transactions tied to public x402 facilitator addresses shows that public ledgers evidence settlement but not mandate, accountability or delivery.
Why it matters here: Uses live x402 facilitator traffic to show what on-chain data cannot prove, and frames mandate lineage in terms that map onto ap2 mandates and erc-8004 identity.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{gong2026ais,
title = {{Authority-Inference Separation in Agentic Finance: First-Line Control, Blockchain Enforcement, and Replayable Assurance}},
author = {Hui Gong and Michail Samawi and Francesca Medda},
year = {2026},
eprint = {2608.30519},
archivePrefix = {arXiv},
primaryClass = {q-fin.GN},
url = {https://arxiv.org/abs/2608.30519}
}
Characterizes the pre-action authorization problem, enforcing policy on a tool call before it executes, and presents the Open Agent Passport, an open specification and implementation that intercepts tool calls, evaluates a declarative policy and emits signed audit records at a median of 53 ms. In a live adversarial testbed with 4,437 decisions, social engineering succeeded 74.6% of the time under a permissive policy and 0% across 879 attempts under a restrictive one.
Why it matters here: The authorization layer that the APort Vault benchmark later uses for payment authorization; it sits in front of x402 and ap2 spending actions.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{uchibeke2026oap,
title = {{Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents}},
author = {Uchi Uchibeke},
year = {2026},
eprint = {2603.20953},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2603.20953}
}
Shows that CaMeL's guarantees do not compose when agents call other agents as tools, because a downstream agent can reinterpret untrusted data as trusted input, and gives a concrete attack. Multi-CaMeL, an agent-to-agent protocol that passes untrusted data through a separate channel, brings attack success on MultiAgentDojo to 0.0 percent versus 0.2 percent for single-agent CaMeL and 12.9 percent undefended.
Why it matters here: Agent-to-agent commerce (A2A with x402, or buyer and merchant agents under ACP) is the hierarchical setting in which single-agent defenses fail; the protocol-level fix speaks to how payment messages between agents should be typed.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{petersgill2026multicamel,
title = {Can CaMeLs Talk? Securing Multi-Agent Systems Against Indirect Prompt Injection Attacks},
author = {James Peters-Gill and Avi Semler and Henning Bartsch and Ilia Shumailov and Christian Schroeder de Witt},
year = {2026},
eprint = {2610.05640},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2610.05640},
note = {arXiv preprint}
}
CaMeL wraps the LLM in a protective system layer that extracts control and data flow from the trusted user query, so retrieved data can never alter program flow, and attaches capabilities to values so tool calls are checked against security policies. It solved 77 percent of AgentDojo tasks with provable security versus 84 percent for an undefended agent.
Why it matters here: The capability model is a natural enforcement point for payment policy: an AP2 cart mandate or an x402 spend limit can be expressed as a CaMeL policy on the payment tool's arguments.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{debenedetti2026camel,
title = {Defeating Prompt Injections by Design},
author = {Edoardo Debenedetti and Ilia Shumailov and Tianqi Fan and Jamie Hayes and Nicholas Carlini and Daniel Fabian and Christoph Kern and Chongyang Shi and Andreas Terzis and Florian Tramèr},
year = {2026},
booktitle = {2026 IEEE Conference on Secure and Trustworthy Machine Learning (SaTML)},
publisher = {IEEE},
pages = {587-618},
doi = {10.1109/SaTML68715.2026.00040},
eprint = {2503.18813},
archivePrefix = {arXiv},
url = {https://arxiv.org/abs/2503.18813}
}
KITA keeps the user's signing key and every threshold key share outside all LLM processes; an action is authorized only when t reviewer-signer domains contribute shares bound to the canonical action after authenticated approval, so a prompt-injected proposer cannot forge an authorization. The path is implemented with a structured-output LLM adapter and threshold BLS signatures.
Why it matters here: Addresses the gap formal analyses of x402 and AP2 point to: the agent that reads untrusted content should not hold the credential that signs the payment.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{zheng2026kita,
title = {From Review to Authorization: Key-Isolated Threshold Signing for LLM Agents},
author = {Yu Zheng and Qizhi Zhang},
year = {2026},
eprint = {2609.05901},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.05901},
note = {arXiv preprint}
}
Identifies a post-fulfillment activation gap: payment, budget, OAuth, mandate and fulfillment checks validate a transaction but do not decide whether a resource an agent acquires (compute, credentials, accounts, other agents) may become usable authority. Proposes a provenance-bounded runtime authorization architecture that quarantines acquired outputs and activates them only through checked activation transactions, with eight proved safety properties and trace-based evaluation.
Why it matters here: Extends the ap2 and x402 question from whether a payment was authorized to what the agent may do with what it bought, a gap none of the eight protocols addresses.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{zhu2026runtimeauth,
title = {{Runtime Authorization for Resources Acquired by AI Agents}},
author = {Genliang Zhu and Chu Wang},
year = {2026},
eprint = {2609.14744},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2609.14744}
}
Systematizes security and economic requirements across the lifecycle of an agent task into 17 property families over six stages, examines 12 systems and standards, five mechanism families and four classical baselines, and introduces guarantee closure, a criterion for whether guarantees made at one stage still constrain later decisions. Experiments over 840 matched executions and an 11,648-case check expose recurring gaps between verification and settlement.
Why it matters here: Relevant to stacks that chain ERC-8004 identity and validation with x402 payment: it shows how an escrow can release funds on an approval that carries little evidence the work was done. Which 12 systems are covered was not confirmed from the abstract alone.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{sun2026sokeconomic,
title = {SoK: Decentralized Agent Economic Infrastructure},
author = {Rui Sun and Xihan Xiong and Qin Wang and Fei Gao and Zelin Li and Zehua Cheng and Jiahao Sun and Zhipeng Wang},
year = {2026},
eprint = {2610.01756},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2610.01756},
note = {arXiv preprint}
}
Proposes a set of principled design patterns that restrict how untrusted inputs can influence an agent's actions, analyzes their utility and security trade-offs, and illustrates them with case studies of real applications.
Why it matters here: A practical checklist for anyone building a buying agent on ACP, AP2 or x402: the patterns constrain which parts of agent state untrusted merchant content may ever touch.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{beurerkellner2025patterns,
title = {Design Patterns for Securing LLM Agents against Prompt Injections},
author = {Luca Beurer-Kellner and Beat Buesser and Ana-Maria Creţu and Edoardo Debenedetti and Daniel Dobos and Daniel Fabian and Marc Fischer and David Froelicher and Kathrin Grosse and Daniel Naeff and Ezinwanne Ozoani and Andrew Paverd and Florian Tramèr and Václav Volhejn},
year = {2025},
eprint = {2506.08837},
archivePrefix = {arXiv},
primaryClass = {cs.LG},
url = {https://arxiv.org/abs/2506.08837},
note = {arXiv preprint}
}
Defines context manipulation (input channels, memory modules and external data feeds) as the attack surface of blockchain agents, shows on ElizaOS that injected prompts or falsified memories trigger unauthorized asset transfers, and introduces CrAIBench with over 150 Web3 tasks and over 500 attack cases. Memory injection proved more effective than prompt injection, and prompt-injection detectors offered little protection.
Why it matters here: The closest existing study of agents that hold crypto spending keys, the deployment model for x402 clients and ERC-8004 registered agents; a poisoned memory can drain a wallet that no protocol-level check would stop.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{patlan2025memories,
title = {Real AI Agents with Fake Memories: Fatal Context Manipulation Attacks on Web3 Agents},
author = {Atharv Singh Patlan and Peiyao Sheng and S. Ashwin Hebbar and Prateek Mittal and Pramod Viswanath},
year = {2025},
eprint = {2503.16248},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2503.16248},
note = {arXiv preprint}
}
An extensible environment for agents that run tools over untrusted data, with 97 realistic tasks (email, e-banking, travel booking), 629 security test cases and pluggable attacks and defenses. Frontier models fail many tasks even without attacks, and existing injections break some but not all security properties.
Why it matters here: Its e-banking and booking suites are the closest public testbed to agent payments, and the defenses cited here (CaMeL, multi-CaMeL) report their numbers on it.
Metadata verified 2026-10-10 through publisher.
Show BibTeX
@inproceedings{debenedetti2024agentdojo,
title = {AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents},
author = {Edoardo Debenedetti and Jie Zhang and Mislav Balunović and Luca Beurer-Kellner and Marc Fischer and Florian Tramèr},
year = {2024},
booktitle = {Advances in Neural Information Processing Systems 37 (NeurIPS 2024), Datasets and Benchmarks Track},
url = {https://proceedings.neurips.cc/paper_files/paper/2024/hash/97091a5177d8dc64b1da8bf3e1f6fb54-Abstract-Datasets_and_Benchmarks_Track.html},
eprint = {2406.13352},
archivePrefix = {arXiv}
}
A benchmark of 1,054 test cases over 17 user tools and 62 attacker tools that measures whether tool-integrated agents follow injected instructions aimed at direct harm or data exfiltration. Across 30 agents the vulnerability was substantial, with ReAct-prompted GPT-4 following injections in roughly one case in four.
Why it matters here: Supplies the attacker-tool framing (a malicious tool result that triggers a transfer) that payment-agent threat models for AP2 and x402 reuse.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{zhan2024injecagent,
title = {InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents},
author = {Qiusi Zhan and Zhixiang Liang and Zifan Ying and Daniel Kang},
year = {2024},
booktitle = {Findings of the Association for Computational Linguistics: ACL 2024},
publisher = {Association for Computational Linguistics},
pages = {10471-10506},
doi = {10.18653/v1/2024.findings-acl.624},
url = {https://aclanthology.org/2024.findings-acl.624/},
eprint = {2403.02691},
archivePrefix = {arXiv}
}
Introduces indirect prompt injection: adversaries plant instructions in data that an LLM-integrated application will retrieve, so the model is attacked without any direct interface. The paper gives a security taxonomy of impacts, including data theft, worming and contamination of the information ecosystem, and demonstrates attacks on real systems.
Why it matters here: The founding paper for the threat every agentic payment protocol must contain; AP2 mandates, x402 pre-execution filters, TAP intent signatures and ACP's structured checkout all exist partly because retrieved merchant content can hijack the buying agent. Agentic Commerce Protocol (ACP): Indirect prompt injection, relevant to merchant text rendered by the agent.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{greshake2023injection,
title = {Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection},
author = {Kai Greshake and Sahar Abdelnabi and Shailesh Mishra and Christoph Endres and Thorsten Holz and Mario Fritz},
year = {2023},
booktitle = {Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (AISec '23)},
publisher = {ACM},
pages = {79-90},
doi = {10.1145/3605764.3623985},
eprint = {2302.12173},
archivePrefix = {arXiv},
url = {https://arxiv.org/abs/2302.12173}
}
Introduces macaroons, bearer credentials built from chained HMACs that any holder can attenuate by adding caveats (contextual restrictions such as time, target or third-party discharge) without contacting the issuer, enabling decentralized delegation in cloud services.
Why it matters here: The attenuable-token model behind later agent delegation designs (Biscuit tokens in AIP, scoped mandates in ap2) and a reference point for how visa-tap and openai-acp scope agent authority. AP2: Caveat-based attenuation, an ancestor of constraint-limited delegation. x402: Macaroons, the credential in the original L402 design (an earlier HTTP 402 approach on Lightning).
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{birgisson2014macaroons,
title = {{Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud}},
author = {Arnar Birgisson and Joe Gibbs Politz and Úlfar Erlingsson and Ankur Taly and Michael Vrable and Mark Lentczner},
year = {2014},
booktitle = {Proceedings 2014 Network and Distributed System Security Symposium (NDSS)},
publisher = {Internet Society},
doi = {10.14722/ndss.2014.23212},
url = {https://doi.org/10.14722/ndss.2014.23212}
}
Introduces blind signatures, where a signer signs a message without seeing it, and uses them to build payments that the bank can verify but cannot link back to the payer.
Why it matters here: The origin of private digital cash; it frames the privacy trade-off in agent payments, where x402 settles on public ledgers and card-based agent payments expose purchase data to the networks.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{chaum1983blind,
title = {{Blind Signatures for Untraceable Payments}},
author = {David Chaum},
year = {1983},
booktitle = {Advances in Cryptology},
pages = {199--203},
publisher = {Springer},
doi = {10.1007/978-1-4757-0602-4_18},
url = {https://doi.org/10.1007/978-1-4757-0602-4_18}
}
A survey tracing market microstructure from floor trading through electronic order books, batch auctions, dark pools and blockchain automated market makers to AI agents that discover, pay for and compete over resources, organized around whether a market can allocate efficiently without participants revealing everything. It argues that allocation is the missing layer of the agent-commerce protocol stack.
Why it matters here: Positions payment protocols such as x402 and MPP as settlement without allocation, and names extractable value and algorithmic collusion as the next problems for agent markets.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{aldridge2026microstructure,
title = {Evolution of Market Microstructure in the Age of AI},
author = {Irene Aldridge},
year = {2026},
eprint = {2609.33058},
archivePrefix = {arXiv},
primaryClass = {econ.EM},
url = {https://arxiv.org/abs/2609.33058},
note = {arXiv preprint}
}
Replaces centralized orchestration with AgentLance, a repeated labor market in which agents bid on tasks using private costs, an allocator picks winners from bids and public reputation records, a VCG-style rule sets payments, and winners can subcontract through the same mechanism. It outperforms single-model, centralized and market baselines, and the authors show a centralized LLM allocator can be swayed by a single inserted preference.
Why it matters here: Demonstrates reputation records and payments working together to allocate agent labor, which is the combination ERC-8004 (reputation) and x402 (payment) aim to provide on open rails.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{liu2026agentlance,
title = {Markets, Not Planners: Decentralized Orchestration of LLM Agents with Private Information},
author = {Xiao Liu and Haoyang Li and Songwei Li and Hongbo Fang and Fengli Xu and Feng Shi and James Evans},
year = {2026},
eprint = {2608.23867},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2608.23867},
note = {arXiv preprint}
}
Argues that the deepest economic effect of generative AI is lower communication friction between consumers and businesses, with assistant agents and service agents transacting programmatically. The authors separate unscripted interactions, enabled by language and protocol design, from unrestricted interactions, which depend on market structure and governance, and discuss walled gardens versus an open agent web, advertising and discovery, micro-transactions and the rebundling of digital goods.
Why it matters here: The clearest economic framing of why ACP, UCP and AP2 exist: its assistant-agent and service-agent split maps onto the buyer-agent and merchant roles those protocols standardize, and its walled-garden warning is the open question behind all of them, with x402 as the micro-transaction case.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@article{rothschild2026agenticeconomy,
title = {The Agentic Economy},
author = {David M. Rothschild and Markus M. Mobius and Jake M. Hofman and Eleanor Dillon and Daniel G. Goldstein and Nicole Immorlica and Sonia Jaffe and Brendan Lucier and Aleksandrs Slivkins and Matthew Vogel},
year = {2026},
journal = {Communications of the ACM},
volume = {69},
number = {2},
pages = {39-42},
doi = {10.1145/3747175},
url = {https://doi.org/10.1145/3747175},
eprint = {2505.15799},
archivePrefix = {arXiv}
}
Proposes a framework for the Agentic Web built on three dimensions (intelligence, interaction, economics), traces its evolution from the PC and mobile web, and discusses communication protocols, orchestration and an Agent Attention Economy together with governance risks.
Why it matters here: Its economics dimension and attention-economy discussion anticipate the discovery and monetization questions that UCP, ACP and x402 are now standardizing.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{yang2025agenticweb,
title = {Agentic Web: Weaving the Next Web with AI Agents},
author = {Yingxuan Yang and Mulei Ma and Yuxuan Huang and Huacan Chai and Chenyu Gong and Haoran Geng and Yuanjian Zhou and Ying Wen and Meng Fang and Muhao Chen and Shangding Gu and Ming Jin and Costas Spanos and Yang Yang and Pieter Abbeel and Dawn Song and Weinan Zhang and Jun Wang},
year = {2025},
eprint = {2507.21206},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2507.21206},
note = {arXiv preprint}
}
Places LLM sellers in simulated continuous double auctions and tests when they collude, defined as secret cooperation that harms another party. Direct seller communication increases collusion, propensity differs by model, and oversight or urgency from authority figures changes collusive behavior.
Why it matters here: Relevant to any multi-seller agent market on ACP, UCP or x402: giving seller agents a channel to talk to each other is itself a competition risk.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{agrawal2025collusion,
title = {Evaluating LLM Agent Collusion in Double Auctions},
author = {Kushal Agrawal and Verona Teo and Juan J. Vazquez and Sudarsh Kunnavakkam and Vishak Srikanth and Andy Liu},
year = {2025},
eprint = {2507.01413},
archivePrefix = {arXiv},
primaryClass = {cs.GT},
url = {https://arxiv.org/abs/2507.01413},
note = {arXiv preprint}
}
Proposes the sandbox economy as a lens on the emerging layer in which AI agents transact at machine speed, classifying it by origin (emergent or intentional) and by permeability to the human economy. The authors discuss auctions for resource allocation, mission economies, and the identity, trust and oversight infrastructure needed to steer such markets, warning that the current path leads to a large and highly permeable agent economy with systemic risk.
Why it matters here: Names the infrastructure gaps (verifiable identity, reputation, controls on permeability) that ERC-8004 and x402 are being built to fill, and gives the policy vocabulary for discussing them.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{tomasev2025virtual,
title = {Virtual Agent Economies},
author = {Nenad Tomasev and Matija Franklin and Joel Z. Leibo and Julian Jacobs and William A. Cunningham and Iason Gabriel and Simon Osindero},
year = {2025},
eprint = {2509.10147},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2509.10147},
note = {arXiv preprint}
}
Argues from pricing history that people prefer flat-rate and bundled pricing over metered charges, and that the mental cost of deciding on each tiny payment is the main obstacle to micropayments, not the technology.
Why it matters here: The classic objection to pay-per-use pricing; agent payments may sidestep it because software, not a person, makes each spending decision, which is the core bet behind x402 and MPP. Stripe MPP (Machine Payments Protocol): The classic critique of per-unit pricing; useful against the falling average MPP payment size.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{odlyzko2003against,
title = {{The Case Against Micropayments}},
author = {Andrew Odlyzko},
year = {2003},
booktitle = {Financial Cryptography},
series = {Lecture Notes in Computer Science},
pages = {77--83},
publisher = {Springer},
doi = {10.1007/978-3-540-45126-6_6},
url = {https://doi.org/10.1007/978-3-540-45126-6_6}
}
Designs Recourse, a set of smart contracts that binds each agent action to its scope, recovery plan, evidence, payout and collateral, so residual harm from a permitted action that fails can be settled through an optimistic oracle or arbitration. The authors deploy it on Base Sepolia and report less uncompensated harm than authorization-only baselines; the arXiv comment says it was accepted at IEEE BCCA 2026, not yet confirmed in proceedings.
Why it matters here: Adds the after-the-fact remedy that payment and identity protocols lack; it pairs naturally with ERC-8004 reputation and on-chain settlement used by x402.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{bindschaedler2026recourse,
title = {{Bonded Recourse for Smart-Contract Settlement of Compensable Agent Side Effects}},
author = {Laurent Bindschaedler and Quentin Botha and Christoph Siebenbrunner},
year = {2026},
eprint = {2609.01939},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.01939}
}
Specifies terms.txt, a robots.txt-style file for per-path, per-purpose machine-access terms, and an origin-enforced exchange combining Web Bot Auth signatures, signed intent, delegation tokens, HTTP 402 negotiation and signed receipts, with a dependency-free implementation adding 0.20 to 0.65 ms per request. The arXiv comment reports submission to IEEE Internet Computing; it is not accepted as of the arXiv record.
Why it matters here: Combines the Web Bot Auth signatures that visa-tap builds on with HTTP 402 negotiation in the style of x402 and stripe-mpp, for content access rather than checkout.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{chowdhury2026termstxt,
title = {{terms.txt: A Consent and Compensation Protocol for Agentic Web Access}},
author = {Rajarshi Chowdhury},
year = {2026},
eprint = {2609.11152},
archivePrefix = {arXiv},
primaryClass = {cs.NI},
url = {https://arxiv.org/abs/2609.11152}
}
Grey literature: central banks, standards drafts and white papers
Global Legal Entity Identifier Foundation (GLEIF). 2026. GLEIF Working Paper Series. Not peer reviewed
A working paper (cover dated September 2026, written by contributors from GLEIF, Curvy Protocol, zERC20, Terminal 3 and an independent expert) arguing that existing law can allocate liability for agent payments but practical proof of delegated authority is missing. It proposes Agent Mandate Credentials anchored in the verifiable LEI to show which organization stands behind an agent and what it may do.
Why it matters here: Offers an organizational-identity answer to the "who is behind this agent" question that ERC-8004 registries, Visa TAP keys and Agent Pay tokens each answer differently.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@techreport{gleif2026agenticpayments,
title = {{Agentic AI in Payments: Establishing Interoperable Trust and Control}},
author = {{Global Legal Entity Identifier Foundation (GLEIF)}},
year = {2026},
institution = {Global Legal Entity Identifier Foundation},
type = {GLEIF Working Paper Series},
month = {sep},
url = {https://www.gleif.org/organizational-identity/research-publications/2026-08-13_agentic_ai_in_payments_v1.0-1.pdf}
}
Prem Munday. 2026. Bank Underground (Bank of England staff blog). Not peer reviewed
A Bank of England staff blog post (2026-05-21) on how agentic commerce could reshape payment design, stressing that deployers stay legally responsible for their agents and asking how existing frameworks apply to card, account-to-account and tokenized rails. Views are the author's, not the Bank's.
Why it matters here: Shows how a payment system operator and overseer frames the contest between card-network agent programs and newer rails such as stablecoin-based x402.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{munday2026bankunderground,
title = {{Agentic commerce and the battleground for new payments infrastructure}},
author = {Prem Munday},
year = {2026},
howpublished = {Bank Underground blog, Bank of England},
note = {Published 2026-05-21},
url = {https://bankunderground.co.uk/2026/05/21/agentic-commerce-and-the-battleground-for-new-payments-infrastructure/}
}
Visa, Artemis. 2026. Visa and Artemis joint research report. Not peer reviewed
A joint report (summary page last updated 2026-07-14) that splits agentic commerce into agent purchases on behalf of people and small machine-to-machine payments, and measures x402 at about $15.0 million adjusted volume over 109.6 million transactions and MPP at about $25,000 over 115,000 transactions, using Artemis data as of 2026-04-21.
Why it matters here: The main vendor-published measurement of x402 and MPP volumes; the adjusted figures exclude activity Artemis classed as wash or test traffic, and they are self-reported, not independently audited.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{visa2026groundup,
title = {{Agentic Payments from the Ground Up: What the Onchain Data Tells Us}},
author = {{Visa} and {Artemis}},
year = {2026},
howpublished = {Visa},
note = {Research report with Artemis; data as of 2026-04-21},
url = {https://www.visa.com/en-us/thought-leadership/innovation/agentic-payments-from-the-ground-up}
}
Examines how agentic AI could change authorization, liquidity, settlement, compliance and resilience in payments, using a three-layer model of intent, authorization and settlement. It stresses the tension between probabilistic AI behavior and the deterministic requirements of payment systems.
Why it matters here: The IMF view of where agent decisions should stop and rule-based payment execution should begin, a split visible in how AP2 mandates and card network tokens separate intent from settlement.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@techreport{davidovic2026imfnote,
title = {{How Agentic AI Will Reshape Payments}},
author = {Sonja Davidovic and Hervé Tourpe},
year = {2026},
institution = {International Monetary Fund},
type = {IMF Notes},
number = {2026/004},
month = {apr},
doi = {10.5089/9781513533308.068},
url = {https://doi.org/10.5089/9781513533308.068}
}
Christopher J. Waller. 2026. Speech at Sibos 2026, Miami, Florida. Not peer reviewed
A Federal Reserve Governor speech separating agent-assisted commerce, where the buyer decides and pays, from agent-delegated commerce, where an agent shops and pays within guardrails, and naming authentication, liability and fraud as the main barriers to the delegated model. The Board speech feed dates it 2026-09-29.
Why it matters here: States in policy terms the shift every protocol in the atlas addresses: proving that an agent holds authority to pay, not only that the cardholder is genuine.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{waller2026sibos,
title = {{Payments in the Age of AI Agents}},
author = {Christopher J. Waller},
year = {2026},
howpublished = {Speech, Board of Governors of the Federal Reserve System},
note = {Sibos 2026, Miami, Florida, 2026-09-29},
url = {https://www.federalreserve.gov/newsevents/speech/waller20260928a.htm}
}
B. Ryan, J. Moxey, T. Meagher and others. 2026. IETF Internet-Draft draft-httpauth-payment-01. Not peer reviewed
Revision 01 (2026-09-09) of the draft behind the Machine Payments Protocol, written by authors from Tempo Labs and Stripe. It defines a "Payment" HTTP authentication scheme that uses the 402 status code to issue payment challenges and stays agnostic to payment method through registered method identifiers.
Why it matters here: The core MPP specification in IETF form; comparing it with x402, which also uses HTTP 402, shows the two designs for pay-per-request access.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{ryan2026httpauthpayment,
title = {{The "Payment" HTTP Authentication Scheme}},
author = {B. Ryan and J. Moxey and T. Meagher and J. Weinstein and S. Kaliski},
year = {2026},
howpublished = {Internet-Draft draft-httpauth-payment-01, IETF},
note = {Work in progress, 2026-09-09},
url = {https://datatracker.ietf.org/doc/draft-httpauth-payment/}
}
Bank for International Settlements. 2025. BIS Annual Economic Report 2025, chapter III. Not peer reviewed
Argues that tokenized platforms built around central bank reserves, commercial bank money and government bonds can form the next monetary system, and that stablecoins fail the three tests of singleness, elasticity and integrity needed to be its mainstay. Published 2025-06-29.
Why it matters here: x402 and the on-chain MPP methods settle mostly in stablecoins; this chapter is the leading central bank critique of that settlement asset.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@incollection{bis2025aerch3,
title = {{The next-generation monetary and financial system}},
author = {{Bank for International Settlements}},
year = {2025},
booktitle = {Annual Economic Report 2025},
chapter = {III},
publisher = {Bank for International Settlements},
month = {jun},
url = {https://www.bis.org/publ/arpdf/ar2025e3.htm}
}
x402 makes two strong promises and leaves the rest to the parties. The client's signature binds the amount and the recipient, so a facilitator can only broadcast what the client signed, and a single-use nonce with a validity window stops replay. Everything around that is out of scope: whether the payTo in a 402 response is the seller the client meant, how much an agent may spend, whether the service is delivered after payment, what the facilitator learns, and whether the facilitator serves everyone. Most real incidents so far were SDK bugs (route matching, Solana duplicate settlement), not protocol breaks, and the academic literature focuses on binding, atomicity and facilitator behavior.
STRIDE threats (12)
STRIDE
Threat
Spec mitigation
Implementer notes
S Spoofing
Payee substitution in an altered 402 responseAn attacker who can change the 402 response (a compromised proxy, a malicious mirror or an injected tool result) swaps payTo for its own address. The client signs a valid authorization to the attacker. Source [21, 37, 64, 73]Preconditions: The attacker can modify or forge the PAYMENT-REQUIRED header; The client does not check payTo against an expected address.Impact: Funds go to the attacker; an exact settlement cannot be reversed by the protocol.
Partly
The signature protects payTo after signing, not before. Pin expected payTo addresses per domain in a client policy, use TLS end to end, and prefer signed offers (offer-receipt) where the seller supports them.
S Spoofing
Replay of a captured payment headerSomeone resends a PAYMENT-SIGNATURE that already paid, to get the resource again or to charge the payer twice. Source [10, 22, 56, 72]Preconditions: The attacker sees a signed header (logs, a proxy, a shared cache).Impact: Blocked: EIP-3009 tokens refuse a used nonce, and facilitators check nonce state at verify time.
Mitigated by spec
Keep validBefore short, never cache responses that carry payment headers (the SDK sets Cache-Control no-store on 402), and add payment-identifier for idempotent server-side access grants.
T Tampering
Facilitator changes the amount or recipientA malicious or buggy facilitator tries to settle a different amount or send funds elsewhere. Source [7, 21, 60]Preconditions: The facilitator controls the broadcast.Impact: None for exact on EVM: amount and recipient are inside the signed EIP-712 struct, and the Permit2 proxy enforces the witness recipient.
Mitigated by spec
Keep this property when adding schemes: the trust-minimizing principle forbids schemes that let the facilitator move funds against client intent. Under upto, the witness also names the only facilitator allowed to settle.
T Tampering
Duplicate settlement raceConcurrent or retried settles for the same payment produce more than one transfer or more than one access grant. Source [37, 41, 63, 65]Preconditions: Several settle workers, or networks where duplicates are not rejected on chain.Impact: Double charging or double service; a 2026 advisory covered facilitators that process Solana payments.
Partly
Patch to @x402/svm 2.6.0, PyPI x402 2.3.0 or Go 2.5.0 or later. Deduplicate atomically across every settle process; the Solana SDK keeps a 120 second settlement cache.
T Tampering
Cross-resource substitutionA payment made for one resource is accepted for another, for example a cheap route's payment used on an expensive one. Source [10, 65]Preconditions: The server does not tie a verified payment to the specific route and requirements it issued.Impact: Underpayment or free access.
Partly
Verify against the server's own requirements for the requested route, never against the accepted object the client echoed. The free-riding paper lists this among four flaw classes.
R Repudiation
Paid but not delivered, or delivered but unpaidPayment and service execution are separate steps. Under authorization the server serves before it settles; under upfront the client pays before the handler runs. Source [10, 34, 38]Preconditions: A handler or settle failure, or a dishonest party.Impact: The seller loses work when a settle fails, or the buyer loses money when the handler fails; neither side can prove the other's fault inside the protocol.
Left to implementers
Use auth-capture for refundable or delayed delivery, keep PAYMENT-RESPONSE hashes and offer-receipt receipts as evidence, and watch research such as A402 that binds payment to execution.
R Repudiation
Manufactured volume and wash activityBecause facilitators often pay gas, settlement counts can be inflated almost for free, and nothing on chain shows who controls a paying wallet. Source [76, 78, 79]Preconditions: Cheap gas and permissive facilitators.Impact: Misleading adoption metrics and leaderboards; poor inputs for reputation systems.
Left to implementers
Report adjusted figures with their method and date; weight reputation by payment evidence and buyer diversity.
I Information disclosure
Personal data in payment metadataResource URLs and descriptions in PaymentRequired and PaymentPayload reach the facilitator, which may have no data agreement with the payer. Source [10, 81]Preconditions: Servers put identifiers or query data in resource fields.Impact: Leakage of personal or business data to third parties.
Left to implementers
Keep resource.url and description generic, strip query strings, and consider filtering middleware as proposed in the Hardening x402 paper.
D Denial of service
Facilitator outage or refusalThe facilitator is down, slow or refuses certain payers or sellers. Most traffic runs through few facilitators. Source [41, 54, 58, 59]Preconditions: A server depends on one facilitator.Impact: Paid routes answer 502 or stop selling; a settle timeout leaves the outcome unknown.
Partly
Anyone can run a facilitator and a server can self-facilitate. Configure a second facilitator, set timeouts deliberately (the TypeScript client defaults to 90 seconds), and reconcile settlement_pending results on chain before retrying.
D Denial of service
Oversized headers dropped in transitBase64 JSON headers can exceed 2 KB, and some intermediaries drop or truncate large headers. Source [20]Preconditions: Many accepts entries or large extensions.Impact: Clients never see the requirements, or servers never see the payment.
Partly
Keep accepts lists short and omit optional fields; the cloudflare:402 binding strips schema objects for this reason.
E Elevation of privilege
Payment bypass through route matchingEncoded path tricks (percent-encoded line terminators, backslashes, escaped slashes) make a paid route look unpaid to the middleware while the framework still serves it. Source [22, 62]Preconditions: The server runs an affected SDK version; Routes are matched with wildcards or path parameters.Impact: Free access to paid resources.
Left to implementers
Upgrade @x402/core (fixes in 2.21.0, 2.22.0 and 2.27.0) and test protected routes with encoded variants. An older high-severity advisory (GHSA-3j63-5h8p-gf7c) hit legacy resource-server packages below 0.5.2.
E Elevation of privilege
Overspending by an agentAn agent pays more than its owner intended: no cap, a disabled cap, or an upto ceiling that the server fully uses. Source [10, 49, 60]Preconditions: spendControls disabled or set high; Upto endpoints with generous ceilings.Impact: Budget loss; under upto the client trusts the server to charge fairly up to the ceiling.
Left to implementers
Budgets are out of scope in the spec. Keep the SDK default cap ($1 per payment) or lower it, add per-task budgets in a policy hook, and set low ceilings for upto.
Preconditions: spendControls set to false, as the browser paywall does for humans; The agent calls many paid endpoints in a loop.
A bug makes the agent call a paid route repeatedly
Each call is a valid, small exact payment
No cap stops the loop
Impact: Budget drained in small, irreversible payments.
Published research findings
A Formal Analysis of Agent Payment Protocols: Tamarin models of x402, MPP, ACP and AP2. (paper in section G) Source [101]
When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments: First systematic study of facilitator-mediated deployments; proposes eight security rules for facilitators and reports four new attack vectors. A widely repeated claim that all 15 tested facilitators broke at least one rule is not in the abstract. (paper in section G) Source [54]
How Agentic Is Agentic Commerce? A Population-Scale Measurement of x402 Adoption and Authenticity: Counts 136,708,672 settlements on Base over 280 days and argues the count is not adoption because it can be manufactured almost for free. (paper in section G) Source [79]
Free-Riding the Agentic Web: A Systematic Security Analysis of x402 Payments: Four flaw classes, including cross-resource substitution and a duplicate settlement race, organized around five invariants. (paper in section G) Source [65]
Five Attacks on x402 Agentic Payment Protocol: Five practical attacks on authorization, binding, replay protection and web-layer handling, tested on local chains, Base Sepolia and live endpoints, with audits of three SDKs. (paper in section G) Source [64]
Hardening x402: PII-Safe Agentic Payments via Pre-Execution Metadata Filtering: Resource metadata sent to servers and facilitators is a PII leakage channel; proposes redacting middleware with spending policies. (paper in section G) Source [81]
A402: Binding Cryptocurrency Payments to Service Execution for Agentic Commerce: x402 does not make execution, payment and delivery atomic; proposes Atomic Service Channels. (paper in section G) Source [34]
CVEs and advisories
GHSA-qr2g-p6q7-w82m severity high: High-severity GitHub advisory for facilitators that process Solana payments; patched in @x402/svm 2.6.0, PyPI x402 2.3.0 and Go 2.5.0. No CVE identifier assigned. VerifiedSource [63]
GHSA-3j63-5h8p-gf7c severity high: High-severity GitHub advisory for the legacy npm packages x402, x402-next, x402-express and x402-hono below 0.5.2, mainly affecting resource server builders. No CVE identifier assigned. VerifiedSource [62]
x402 natively binds the payee and amount, bounds every authorization in time, prevents replay and returns a transaction hash. It leaves identity, consent, budgets, revocation of a signed payment, disputes and reputation to SDKs, facilitators or other protocols. The best places for an independent controls layer are the client before signing (policy hooks, payTo allowlists, budgets) and the facilitator at settlement (screening).
Identity is optional and separate from payment: sign-in-with-x (CAIP-122 wallet proof), auth-hints (OAuth 2.0 with DPoP) and RFC 9421 agent signatures in cloudflare:402. Source [20, 28, 40]
Agent registration (know your agent)
External
No registry in x402. ERC-8004 can record that an agent accepts x402; cloudflare:402 needs the signature agent registered with Cloudflare. Source [20, 26, 30]
User consent capture
External
The protocol has no consent object. The browser paywall asks a human in the UI; agents rely on mandates from other protocols such as AP2. Source [7, 49, 88]
Spending caps
Partial
Budgets are out of scope in the spec. The TypeScript client applies spendControls by default (default assets only, $1 per payment); upto signs a ceiling. Source [10, 49, 60]
Merchant or payee scoping
Native
The signature covers payTo and the amount; upto also names the one facilitator allowed to settle. Source [21, 60]
Time windows and expiry
Native
validAfter, validBefore, Permit2 deadline, maxTimeoutSeconds and Lightning invoice expiry bound every authorization. Source [10, 19]
Revocation
Partial
A signed exact authorization cannot be recalled before it expires. auth-capture adds void and client reclaim after captureDeadline; batch-settlement channels allow timed withdrawal. Source [38, 39]
Step-up authentication
None
The specification defines no step-up or challenge beyond the 402 itself. Source [10]
Replay protection
Native
Single-use 32-byte nonces enforced by EIP-3009 tokens, Permit2 nonces, cumulative vouchers, and replay stores for Lightning payment hashes. Source [10, 19, 39]
Receipts and evidence
Native
PAYMENT-RESPONSE carries the transaction hash; the optional offer-receipt extension signs offers and receipts (TypeScript only). Source [14, 52, 73]
Dispute support
None
No dispute process. exact has no refund; auth-capture adds refunds, and third parties such as x402r add arbitration. Source [35, 37, 38]
Reputation
External
None in x402. ERC-8004 feedback can carry proofOfPayment for an x402 payment. Source [30, 90]
Monitoring signals
Partial
Settlements are public on chain but look like ordinary transfers; /supported, Bazaar and x402scan are public; header contents are private. Source [21, 71, 90, 102]
Kill switch
External
No protocol kill switch. Clients stop by policy or spendControls; servers stop by removing routes; facilitators can refuse to settle. Source [41, 49]
No protocol budget. Client-side budget management is out of scope. Caps exist only in SDKs and wallets, and can be switched off with spendControls false. Source [10, 49]
No way to recall a signed exact payment. Once a client signs, the authorization is valid until validBefore; nothing in exact lets the client withdraw it. Source [10, 37]
No disputes. Neither exact nor upto define refunds; the protocol has no dispute process. Source [37, 38]
No identity or consent object. The protocol says nothing about who the client is or what a user approved; extensions and other protocols fill this. Source [28, 30]
Weak on-chain labeling. An exact EIP-3009 payment is an ordinary token transfer on chain, so monitors cannot easily isolate x402 traffic without builder codes or facilitator data. Source [23, 90]
Where an independent controls layer can act
Before authorization
Decide whether to pay at all: allowlists, budgets, asset and network policy. Client policies and hooks (onPaymentRequired, onBeforePaymentCreation) and spendControls in the SDK. Source [49, 52]
At signing
Limit what a signature can do. Short validBefore windows, low upto ceilings, wallet-level signing policies and key isolation. Source [10, 60]
At the edge
Check requests before they reach the seller. Payment middleware, CDN gateways such as Cloudflare's, and RFC 9421 agent identity in cloudflare:402. Source [20, 50]
At settlement
Screen and deduplicate before money moves. Facilitator KYT and OFAC screening, onBeforeSettle hooks, atomic deduplication across settle workers. Source [37, 52, 99]
After the fact
Recover and learn. auth-capture refunds, third-party x402r, transaction-hash receipts, contract events and x402scan monitoring. Source [35, 38, 102]
Implementer checklist
Pin the expected payTo per seller and refuse anything else before signing. The signature protects payTo only after you sign it. Source [21]
Keep spendControls on and set a cap lower than the $1 default for unattended agents. Budgets are not part of the protocol. Source [10, 49]
Verify against your own requirements for the requested route, not the accepted object the client echoed. Prevents cross-resource substitution. Source [65]
Treat a settle timeout as unknown and reconcile on chain before retrying. The facilitator may already have settled. Source [10, 58]
Keep @x402 packages current and test encoded-path variants of paid routes. Several releases fixed payment bypasses in route matching. Source [22]
Store every PAYMENT-RESPONSE transaction hash with the request it paid for. It is the only receipt exact provides. Source [14]
Strip personal data from resource URLs and descriptions. They reach the facilitator. Source [81]
Use auth-capture when buyers need refunds or delivery is delayed. exact is final. Source [38]
J. Compliance and regulation
Not legal advice. This is a study summary of public rules as of the dates cited. Ask counsel about your situation.
x402 moves signed stablecoin payments and has no identity, KYC or sanctions layer of its own, so regulation lands on the parties: stablecoin issuers, facilitators that broadcast payments, and sellers that receive them. The open questions are whether a non-custodial facilitator counts as a money transmitter or payment service provider (existing guidance does not address it directly), who screens for sanctions and carries travel-rule data, and how consumer-protection rules written for bank accounts apply to wallet transfers. Rows are dated; check each source before you rely on it.
Rules by topic and jurisdiction
Jurisdiction
What applies
Confidence
Consumer protection and liability
United States
Regulation E protects consumers against unauthorized transfers from accounts held at financial institutions, and the CFPB withdrew its 2025 proposal on emerging payment mechanisms (effective 2025-05-15). Whether it covers an x402 stablecoin wallet transfer is unclear, and exact payments have no protocol refund. Source [37, 107, 108]
Verified
United States
Products built on x402 add their own gates: the Cloudflare Monetization Gateway closed beta is limited to eligible US sellers and buyers, and Stripe's preview was reported as US only. Source [50, 85]
Reported
Canada
The Retail Payment Activities Act brought payment service providers under Bank of Canada supervision on 2025-09-08 (risk management and safeguarding of funds). Source [123]
Verified
Card network rules
Card-network rules do not apply to exact stablecoin settlements. The x402 Foundation runs a card-acceptance working group, but no specification text exists yet; cloudflare:402 is credit billed by Cloudflare as merchant of record under its own terms. Source [20, 93]
Verified
Card network rules
No primary Visa or Mastercard rule on agent-specific disputes or liability shifts was found as of 2026-10-11; a Worldpay analysis says no liability shift exists yet for agentic transactions. Source [127]
Unverified
AML and sanctions
United States
The protocol has no KYC, know-your-agent or sanctions layer. The CDP facilitator runs OFAC and Know Your Transaction checks on payments; other facilitators vary. Source [10, 99, 100]
Verified
United States
OFAC guidance for the virtual currency industry (2021-10-15) says sanctions duties apply to virtual currency businesses, penalties are generally strict liability, and screening should be risk-based. Facilitators and sellers each need their own view of this. Source [103]
Verified
United States
FinCEN guidance FIN-2019-G001 (2019-05-09) treats intermediaries by their control over value, and calls hosted wallet providers money transmitters. It does not address a non-custodial relayer that only broadcasts a payer-signed transfer, so how it applies to x402 facilitators is an open inference. Source [41, 104]
Reported
European Union
The Transfer of Funds Regulation (EU) 2023/1113 has applied the travel rule to crypto-asset transfers since 2024-12-30. x402 headers carry no originator or beneficiary data, so any travel-rule data must come from the service providers involved. Source [10, 111]
Verified
United Kingdom
Since 2023-09-01 UK cryptoasset businesses must apply the travel rule, and the FCA expects them to stay responsible even when they use third-party suppliers. Source [117]
Verified
Canada
FINTRAC treats transferring virtual currency for clients as a money services business activity that needs registration, including for foreign businesses serving people in Canada. Source [122]
Verified
Stablecoin rules
United States
The GENIUS Act (Public Law 119-27, 2025-07-18) regulates payment stablecoins such as USDC and takes effect on the earlier of 2027-01-18 or 120 days after final regulations. Source [105]
Verified
United States
As of 2026-10-11 only proposed GENIUS Act rules were found (the OCC proposal of 2026-03-02); press reports say the 2026-07-18 rulemaking deadline passed without final rules. Source [106]
Reported
European Union
MiCA (Regulation (EU) 2023/1114) has applied to e-money tokens since 2024-06-30 and in full since 2024-12-30; the transitional period for crypto-asset service providers ended on 2026-07-01. Source [109, 110]
Verified
United Kingdom
The FCA published its cryptoasset regime policy statements on 2026-06-30, including stablecoin issuance (PS26/10); the full set of regulated activities applies from 2027-10-25. Source [116]
Verified
Canada
The Stablecoin Act in Bill C-15 received Royal Assent on 2026-03-26; the Bank of Canada will register and supervise non-bank fiat-backed stablecoin issuers, with the framework expected to take effect in 2027. Source [120, 121]
Verified
Singapore
Digital payment token services need a MAS license under the Payment Services Act 2019, and MAS finalized a framework for single-currency stablecoins issued in Singapore on 2023-08-15. Source [124, 125]
Verified
Strong customer authentication
European Union
PSD3 and the Payment Services Regulation reached provisional agreement on 2025-11-27 and were listed as close to adoption on 2026-09-20, not yet in the Official Journal. They target payment service providers; x402 stablecoin payments sit mainly under MiCA instead. Source [109, 115]
Verified
AI-specific rules
European Union
AI Act transparency duties under Article 50 apply from 2026-08-02; the Digital Omnibus (Regulation (EU) 2026/1744) moved Annex III high-risk obligations to 2027-12-02. Nothing in the AI Act is specific to agent payments. Source [112, 113]
Verified
United Kingdom
The FCA payments priorities report (2026-03-25) says it will consider whether regulation must change for agentic AI payments, and HM Treasury consulted on modernising payment services regulation from 2026-07-14 to 2026-10-06, naming agentic payments. Source [118, 119]
Verified
Singapore
MAS issued Guidelines on AI Risk Management for financial institutions on 2026-10-07, effective 2027-10-07, mentioning agentic AI systems that act autonomously. Source [126]
Verified
Data protection
European Union
GDPR covers information about an identifiable person, including online identifiers. Resource URLs, descriptions and payer addresses linked to a person that x402 sends to a facilitator can be personal data. Source [81, 114]
Verified
K. Observability lens
3 of 5 observability score
Every on-chain settlement is public, with a transaction hash returned to the client, but an exact EIP-3009 payment looks like an ordinary token Transfer plus AuthorizationUsed, so nothing marks it as x402.
The x402 contracts (Permit2 proxies, batch settlement) emit named events at the same address on every supported EVM chain, which makes those paths easy to index.
Facilitator capabilities (GET /supported) and the Bazaar resource catalog are public HTTP endpoints, and x402scan publishes an explorer and API.
The richest data (requirements, resource URLs, amounts before settlement, vouchers, screening decisions) stays in headers and facilitator logs, and credit-backed cloudflare:402 commitments never reach a chain.
Public volume counters exist but are contested and were not visibly updated after 2026-08-25.
Publicly observable
Public signals
What
Where
How
Exact EIP-3009 settlements
The token contract on each chain
Transfer and AuthorizationUsed events; the transaction hash also arrives in PAYMENT-RESPONSE. Source [14, 21, 90, 91]
Same addresses on every supported EVM chain; batch channels emit ChannelCreated, Deposited, Claimed, Settled, Refunded, WithdrawInitiated, WithdrawFinalized and ChannelClosed. Source [61]
Facilitator capabilities
GET /supported (for example https://x402.org/facilitator/supported)
Lists kinds (x402Version, scheme, network), extensions and signer addresses per CAIP-2 family. Source [10, 128]
Resource catalog
GET /discovery/resources and GET /discovery/search; CDP instance at api.cdp.coinbase.com/platform/v2/x402/discovery/resources
Public listings of resources with accepts entries and lastUpdated; no API key needed on the CDP instance; no category data. Source [10, 71]
Explorer and registry
https://www.x402scan.com and its API routes (buyers, facilitators, merchants, origins, registry, resources, send, wallets)
Operated by Merit Systems; discovery reads /openapi.json with x-payment-info, then /.well-known/x402, and trusts runtime 402 behavior over static metadata. Source [102, 129]
Agent key directories
/.well-known/http-message-signatures-directory
RFC 9421 public keys for signature agents in cloudflare:402 and the http-message-signatures extension. Source [20, 26]
Attribution codes
Settlement calldata
builder-code appends an ERC-8021 Schema 2 suffix naming app, wallet or facilitator, and service. Source [23]
Project counters and advisories
x402.org, GitHub Security Advisories, the repository
PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE contents. They travel only between client, server and facilitator, including resource URLs, descriptions and amounts.
Facilitator logs, KYT and OFAC decisions, pending settlement stores. Operational data of each facilitator; nothing obliges publication.
Batch-settlement vouchers before a claim. Cumulative vouchers live in server storage until the server claims them on chain.
cloudflare:402 credit commitments and billing identity. Credit-backed payments never reach a chain; Cloudflare maps signature identities to accounts.
Who controls a paying wallet. Nothing on chain links a wallet to an agent or a person, which is the root of the volume dispute.
What an indexer or monitor could capture
Exact EIP-3009 settlements from Token Transfer and AuthorizationUsed events, joined with known facilitator signer addresses from /supported: authorizer address, nonce, transaction hash, facilitator signerSource [10, 21, 91]
Permit2 proxy settlements from x402ExactPermit2Proxy and x402UptoPermit2Proxy events at their fixed addresses: proxy address, from, to, amount, assetSource [21, 61]
Seller and resource catalog from GET /discovery/resources on public Bazaar instances and x402scan registry routes: resource URL, payTo, scheme, networkSource [71, 102]
App and facilitator attribution from ERC-8021 builder-code suffix in settlement calldata: app code (a), wallet or facilitator code (w), service code (s)Source [23]
L. Ecosystem and adoption
Stewards
x402 Foundation (x402 a Series of LF Projects, LLC): Governs the protocol under a technical charter adopted 2026-03-31; Linux Foundation project since 2026. Source [2, 3, 4]
Technical Steering Committee: Coinbase, Cloudflare, Stripe: Votes on technical decisions; named in TSC.md on 2026-05-12. Source [5, 47]
Coinbase Developer Platform: Originated x402 and wrote the 2025-05-06 whitepaper; runs the largest facilitator. Source [1, 55]
Implementers and deployments
Implementers (9)
Name
Role
Status
Coinbase CDP facilitator
Facilitator on Base, Polygon, Arbitrum, World and Solana with KYT and OFAC screening. Source [99, 100]
Live
Facilitators listed in the x402 docs (PayAI, Corbits, Dexter, Fireblocks, Polygon, Celo, NEAR x402 Facilitator, T54 XRPL and others)
Independent verify and settle services; the docs say the list is not exhaustive. Source [53]
Unknown
Cloudflare Monetization Gateway
Closed beta that settles USDC on Base through Coinbase's facilitator; US sellers and buyers only. Source [50]
Beta
Cloudflare Agents SDK and AI Gateway
withX402 and paidTool for agents and MCP servers since 2025-09-23; AI Gateway accepts PAYMENT-METHOD: x402. Source [45, 130]
Live
Circle Nanopayments (Circle Gateway)
Gas-free USDC payments from $0.000001 using EIP-3009 inside the x402 flow, batched settlement. Source [46, 131]
Live
Stripe machine payments preview
Charges agents in USDC on Base through x402 (reported). Source [85]
Beta
Coinbase Agentic Wallets
Agent wallets reported to transact through x402. Source [86]
Announced
x402scan (Merit Systems)
Explorer, registry and public API for x402 activity. Source [102]
Live
Google a2a-x402 and AP2 samples
A2A extension and human-present and human-not-present x402 samples. Source [89, 132]
Stars on the canonical repository. Source [68] Caveat: Interest, not usage.
npm downloads of @x402/core, last 30 days
1,492,519 downloads
npm registry download count for the V2 core package. Source [133] Caveat: Includes CI installs; the legacy V1 package x402 had 2,007,353 in the same window.
x402.org 30-day transactions
75.41M transactions
Self-reported counter on x402.org; the page displayed this on 2026-10-10 with "Last updated: 2026-08-25". Source [74] Caveat: Raw count, not adjusted for wash activity; appears not updated since at least mid August 2026. Disputed Source [75, 76, 79].
x402.org 30-day volume
$24.24M USD
Self-reported counter on x402.org, read on 2026-10-10. Source [74] Caveat: The same figure was reported for mid August 2026 by Crypto Briefing. Disputed Source [75, 76].
Adjusted x402 volume (Visa and Artemis)
$15.0M across 109.6M transactions USD and transactions
Cumulative data to 2026-04-21 after removing activity Artemis classes as non-organic; average $0.14 per transaction. Source [76] Caveat: Secondary report of a Visa and Artemis chart; Visa's Cuy Sheffield separately cited about $19M across about 134M. Disputed Source [77].
Share of transactions flagged as gamed (Artemis)
63.94 percent (average)
Average share flagged between 2025-11-09 and 2026-02-07; peak 90.21 percent. Source [78] Caveat: Secondary analysis; the detection logic is not published. Disputed Source [74].
Settlements on Base (academic count)
136,708,672 settlements
Settlements over a 280 day window, from arXiv:2607.12575. Source [79] Caveat: The paper argues settlement counts are not adoption because they can be manufactured almost for free.
Quote from Rishin Sharma (Solana Foundation) in the Linux Foundation release of 2026-04-02, for 2026 to date; a self-reported figure from an interested party. Source [3] Caveat: About 70 percent of monthly volume was reported for mid August 2026, while Base held about 90 percent of adjusted transactions in Visa and Artemis data; volume share and transaction share differ. Disputed Source [75, 77].
Cumulative transactions (press)
120M to 187M transactions
Range across trackers reported by Crypto Briefing. Source [75] Caveat: Trackers disagree. Disputed Source [75].
x402 Foundation members
40 organizations
Members at the operational launch, 17 of them Premier. Source [4] Caveat: The listed names count 39 or 40 depending on one combined entry.
Costs
Costs, who pays them, and how sure we are
Item
Value
Who pays
As of
Confidence and caveat
CDP facilitator settlement fee
First 1,000 on-chain transactions each month free, then $0.001 per on-chain transaction Source [100]
Resource server (the facilitator customer)
Verified Counts on-chain transactions, not payment requests; prices change without notice.
exact and EVM upto: one; Solana upto: two; batch-settlement: one claim covers many vouchers Source [100]
Facilitator pays gas, recovered through its fee
Verified Deposits, refunds and withdrawals in batch-settlement count as one transaction each.
Other facilitators
PayAI: on-chain gas plus 30 percent per settlement since 2026-09-21, paid in $0.001 credits, with 1,000 free credits per receiving wallet for life (about 650 Solana or 430 Base settlements); thirdweb 0.3 percent (secondary); self-hosted pays only gas and operations Source [134, 135]
Resource server
Verified PayAI figures from its own pricing docs; its facilitator home page still showed an older plan. The thirdweb figure comes from a secondary comparison of 2026-07-12; verify on the vendor page.
Gas for a USDC transfer
Base about $0.005 to $0.01; Solana about $0.001 to $0.005; Ethereum L1 about $1 to $5 Source [51, 136]
Facilitator on the exact EVM path and as Solana fee payer, or the merchant when it sponsors
Reported Secondary mid-2026 estimate under normal congestion.
Circle Nanopayments
Payments from $0.000001 USDC; no per-transaction fee schedule published Source [131]
Not stated (buyers sign off-chain at zero gas)
Verified Who pays the batch settlement gas is not stated.
Verified x402 itself charges nothing; costs are facilitator fees and gas. cloudflare:402 is credit billed by Cloudflare as merchant of record under its own terms.
Pay for a request with @x402/fetch (client)@x402/fetch with @x402/evm 2.28.0Client sidetypescript
import { wrapFetchWithPaymentFromConfig } from "@x402/fetch";import { ExactEvmScheme } from "@x402/evm";import { privateKeyToAccount } from "viem/accounts";const account = privateKeyToAccount("0xYourPrivateKey");const fetchWithPayment = wrapFetchWithPaymentFromConfig(fetch, { schemes: [ { network: "eip155:8453", // Base mainnet client: new ExactEvmScheme(account), }, ],});const response = await fetchWithPayment("https://api.example.com/paid-endpoint", { method: "GET",});
From the package README quick start. On a 402 the wrapper decodes PAYMENT-REQUIRED, signs with the registered scheme and retries with PAYMENT-SIGNATURE. Never put a real key in code; the atlas playground uses ephemeral keys on fake chains. @x402/fetch with @x402/evm documentation (external link)Source [98]
Lower the default spend cap (client)@x402/fetch (x402ClientConfig) 2.28.0Client sidetypescript
const fetchWithPayment = wrapFetchWithPaymentFromConfig(fetch, { schemes: [{ network: "eip155:8453", client: new ExactEvmScheme(account) }], // Default: only known assets, "$1" per payment. false disables all limits. spendControls: { maxAmountPerPayment: "$0.10" },});
Simulation of the V2 and V1 402 handshake, facilitator verify and settle, failure injection, an EIP-712 signature with an ephemeral key on a fake chain (424242), and the SDK spend cap. No real funds, no wallet, no network calls.
Simulation, no real fundsFollows spec version v2.0
Loading the simulation.
Keys are generated in this browser for this session only, on test chain identifiers or fixture data. No wallet connects and nothing is sent to a network.
P. Compare and compose
Stripe MPP is the closest sibling, and the two are built to coexist. MPP’s documentation says the x402 model maps onto MPP’s charge intent, and its mppx library lets one server route answer with either challenge and accept either credential.Source [31] Stripe sits on the x402 TSC and co-created MPP, so expect the two to keep converging at the edges.Source [4, 5, 82] Pick x402 when you want the model and the family (, , ); compare the two side by side in the matrix before you commit to one.
AP2 and x402 meet through the a2a-x402 , launched on 2025-09-16, which carries x402 requirements and payments inside messages and, in its embedded flow, inside AP2 mandates.Source [29, 88, 89] That embedding targets AP2 v0.1: it puts the requirements in a CartMandate, and AP2 v0.2 has no Cart mandate, so the two specifications are out of step today.Source [88, 89] The AP2 repository still ships human-present and human-not-present x402 samples.Source [89]
ERC-8004 supplies what x402 leaves out: who the agent is and how it behaved. Its registration file has an x402Support boolean, and its off-chain feedback file can carry a proofOfPayment for an x402 payment.Source [30] Its best practices recommend agentWallet as the address that receives x402 payments, and they warn that indexers cannot easily tell x402 payments from ordinary transfers.Source [21, 90, 91]
Visa TAP answers in its own way. The TAP specification defines a conditional browsingIOU object that the agent sends when a merchant asked for payment with a 402. The merchant checks it against its 402 response and grants access, expecting the funds at settlement.Source [32] TAP’s sample merchant backend uses non-standard X-Payment headers, not the x402 wire format.Source [92] Visa and Mastercard are both Premier members of the x402 Foundation, which also runs a card-acceptance working group.Source [4, 93] , an earlier HTTP 402 payment design on Lightning, sits in the orbit: no source says it is the ancestor of x402.Source [33, 36] Lightning Labs launched it as LSAT on 2020-03-30 with a plus a and renamed it L402 on 2023-04-20. The bLIP-0026 draft, rewritten on 2026-02-25 and still an open pull request, makes macaroons optional.Source [33, 36, 94, 95, 96]
Relations to other protocols
Compatible withfrom AP2: The a2a-x402 Embedded Flow nests x402 inside AP2 mandates, but it targets the v0.1 CartMandate and PaymentMandate; AP2 v0.2 has no Cart mandate. The AP2 repository ships x402 samples. Source [140, 141]
Complementsfrom ERC-8004: Trustless Agents: Neither depends on the other. ERC-8004 publishes x402Support, uses agentWallet as the payee address, and lets feedback files carry proofOfPayment for an x402 payment; Erik Reppel co-authors ERC-8004 and sits on the x402 TSC. Source [5, 142, 143]
Complementsfrom Mastercard Agent Pay: Mastercard is a premier member of the x402 Foundation, and Coinbase's AP4M quote names x402; no Agent Pay technical document mentions x402. Source [144, 145]
Compatible withfrom Stripe MPP (Machine Payments Protocol): MPP maps x402 headers onto Payment authentication and x402 exact onto charge; upto and batch-settlement are comparable to sessions. mppx 0.9.0 and later serves both on one route; the mppx client prefers the Payment challenge. Source [146, 147, 148]
Competes withfrom Stripe MPP (Machine Payments Protocol): Both are HTTP 402 payment protocols; MPP's comparison page, written by its authors, recommends MPP by default. Stripe co-authors MPP and sits on the x402 TSC. Source [146, 149]
Complementsfrom Visa Trusted Agent Protocol: TAP's browsingIOU answers an HTTP 402 with card-acquiring data but uses none of x402's headers or payloads; Visa is a Premier member of the x402 Foundation and said at launch it was working with Coinbase on interoperability. Source [4, 32, 150]
Compatible withx402 to Stripe MPP (Machine Payments Protocol): MPP maps x402 exact onto its charge intent, and mppx can serve both protocols on one route; Stripe sits on the x402 TSC and co-created MPP. Source [5, 31]
Complementsx402 to ERC-8004: Trustless Agents: ERC-8004 registration files carry an x402Support flag, feedback files can carry proofOfPayment for an x402 payment, and best practices use agentWallet as the x402 receipt address. Source [30, 90]
Complementsx402 to Visa Trusted Agent Protocol: The TAP specification defines a browsingIOU object an agent sends when a merchant answered with 402; TAP samples use non-standard X-Payment headers rather than the x402 wire format. Visa is a Premier member of the x402 Foundation. Source [4, 32, 92]
Embedsx402 to AP2: AP2 can carry x402 as a payment method through the a2a-x402 extension launched on 2025-09-16; its embedded flow targets AP2 v0.1 mandates (CartMandate), which AP2 v0.2 no longer has. Source [29, 88, 89]
Same stewardx402 to Mastercard Agent Pay: Mastercard is a Premier member of the x402 Foundation, which runs a card-acceptance working group; no technical link to Agent Pay was found. Source [4, 93]
x402 in the compare matrix (34 dimensions)
Dimension
Value
Confidence
Primary job
Pay-per-request payments over HTTP 402 The server prices a request in a 402 response, the client signs a payment, a facilitator verifies and settles it.Source [7, 10]
Verified
Layers covered
Settlement rails and payment credential; discovery through Bazaar; refunds only in auth-capture No identity, intent or checkout layer.Source [10, 38, 70]
Verified
Stewards
x402 Foundation (Linux Foundation); TSC: Coinbase, Cloudflare, Stripe Originated at Coinbase Developer Platform.Source [1, 4, 5]
Verified
Governance model
Foundation under an LF Projects technical charter TSC with one vote per representative and majority decisions; 75 percent supermajority for Core Principles.Source [2]
Verified
License (spec and code)
Apache-2.0 No separate docs license found; contributions need GPG-signed commits.Source [6, 8]
Live (V2 since 2025-12-11) upto, batch-settlement, auth-capture and Lightning are 2026 additions with uneven SDK coverage.Source [11, 52]
Verified
Transports
HTTP headers, MCP _meta, A2A task metadata The facilitator API is HTTP in every case.Source [14, 15, 16]
Verified
Settlement rails
EVM chains, Solana, Lightning and other CAIP-2 networks; credit-backed cloudflare:402 Fiat ids such as ach:us appear only as examples of the id format.Source [10, 17, 20]
Verified
Agent identity model
None in the core; optional extensions sign-in-with-x (CAIP-122), auth-hints (OAuth 2.0 with DPoP), RFC 9421 agent signatures in cloudflare:402.Source [20, 28, 40]
Verified
User authorization model
The client signature on each payment No user mandate object; AP2 mandates can carry x402 through a2a-x402.Source [21, 88]
Verified
Human-present and human-not-present support
Both Built for unattended clients with SDK spend controls; @x402/paywall serves humans; AP2 ships human-present and human-not-present x402 samples.Source [49, 89]
Verified
Merchant of record
The resource server In cloudflare:402 the network (Cloudflare) is merchant of record.Source [10, 20]
Verified
Credential type
Signed payment authorization EIP-3009 or Permit2 signatures, ERC-7710 delegations, a partially signed Solana transaction, or a Lightning preimage.Source [19, 21, 51]
Verified
Cryptography
EIP-712 typed-data signatures; Ed25519 for RFC 9421 and Solana; SHA-256 preimages on Lightning Smart wallets through ERC-1271 and ERC-6492.Source [19, 20, 21, 22]
Verified
Replay protection
Single-use nonce plus a validity window, enforced by the token contract Replay stores for Lightning payment hashes; cumulative vouchers in batch-settlement.Source [10, 19, 39]
Verified
Native spending controls
None in the protocol; SDK default of $1 per payment Budgets are out of scope in the spec; upto signs a ceiling.Source [10, 49]
Verified
Revocation
None for a signed exact payment before it expires auth-capture adds void and client reclaim; channels allow timed withdrawal.Source [38, 39]
Verified
Refunds and disputes
No refunds in exact; no dispute process auth-capture refunds; third-party x402r for refunds and arbitration.Source [35, 37, 38]
Verified
Privacy exposure
Settlements are public on chain; resource metadata reaches the facilitator Header contents stay private between client, server and facilitator.Source [10, 21, 81]
Verified
Discovery mechanism
Bazaar extension and GET /discovery/resources Public CDP Bazaar; x402scan reads /openapi.json and /.well-known/x402.Source [10, 71, 129]
Verified
Permissionless or registration required
Permissionless Anyone can run a facilitator; cloudflare:402 needs the signature agent registered with Cloudflare.Source [26, 41]
Verified
Decentralization
Open and permissionless, concentrated in practice Most payments go through one facilitator.Source [41, 54, 55]
Reported
Observability score
3 of 5 Public settlements and endpoints, but payments look like ordinary transfers and headers stay private.Source [71, 90, 102]
Verified
Fees and who pays them
No protocol fee; facilitator fee plus gas CDP: 1,000 free on-chain transactions a month, then $0.001 each; verification free (as of 2026-10-11). The facilitator pays gas on the EVM exact path and as Solana fee payer.Source [21, 51, 100]
Verified
Who pays (short)
Facilitator pays gas; seller pays the facilitator fee On Solana the merchant can sponsor as fee payer; cloudflare:402 is billed by Cloudflare.Source [41, 51, 100]
AP2 (a2a-x402), ERC-8004, Stripe MPP, Visa TAP No link found with OpenAI ACP or UCP.Source [7, 30, 31, 32, 88]
Verified
Reference implementations and SDKs
@x402 TypeScript 2.28.0, PyPI x402 2.25.0, Go module v2 Java in the repository but unpublished; legacy V1 npm packages still downloaded.Source [12, 67, 80, 151]
Verified
Adoption evidence
Real but contested x402.org showed $24.24M over 30 days (last updated 2026-08-25); Visa and Artemis adjusted cumulative activity to about $15.0M across 109.6M transactions (data to 2026-04-21).Source [74, 76, 79]
Reported
Published security research
Yes: several 2026 papers and two high-severity advisories Five attacks, free-riding flaws, facilitator risks, A402, PII leakage, formal analysis; GHSA-3j63-5h8p-gf7c and GHSA-qr2g-p6q7-w82m.Source [54, 62, 63, 64, 65]
Verified
Regulatory touchpoints
Stablecoin, money transmission and sanctions rules fall on facilitators and sellers No KYC or sanctions layer in the protocol; the CDP facilitator runs OFAC and KYT checks.Source [10, 99, 100]
Verified
Biggest open question
How much activity is real commerce, and can payment and delivery be made atomic? Source [34, 79]
No longer. Coinbase Developer Platform originated it in 2025, but since 2026 it is governed by the x402 Foundation, a Linux Foundation project with a Technical Steering Committee of Coinbase, Cloudflare and Stripe. coinbase/x402 is now a fork of the foundation repository. Source [1, 2, 3, 4, 5, 69]
MisconceptionIs every x402 payment USDC on Base?
No. Networks are CAIP-2 ids across many EVM chains, Solana, Lightning and others, and default assets include USDT0, MegaUSD, USDM and USDT as well as USDC. A Solana Foundation quote in the Linux Foundation release of 2026-04-02 put Solana at nearly 65 percent of x402 volume in 2026 to date. Source [3, 10, 17, 18, 19]
MisconceptionAre the V1 and V2 headers the same?
No. V1 put the requirements in a JSON body and used X-PAYMENT and X-PAYMENT-RESPONSE. V2 uses PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE, CAIP-2 network ids and an amount field instead of maxAmountRequired. Source [13, 14, 42, 43]
MisconceptionIs the PyPI package x402 a legacy V1 package?
No. PyPI x402 2.x is the V2 Python SDK (2.25.0 on 2026-09-29). The legacy V1 packages are the unscoped npm packages such as x402 and x402-express. Source [7, 42, 67]
MisconceptionWhat happened to the deferred scheme?
Cloudflare proposed it in 2025-09. It merged on 2026-04-15 under the name batch-settlement, together with the credit-backed cloudflare:402 binding. The separate deferred pull request closed without merging. Source [44, 45, 138]
Can a facilitator steal or redirect the payment?
Not under exact on EVM: the signature covers the amount and the recipient, so the facilitator can only broadcast what the client signed. It can refuse or delay service, and it sees payment metadata. Source [10, 21, 39, 41]
Can I get a refund?
Not in the exact scheme, which defines no refund. auth-capture supports void, refund and reclaim, batch-settlement channels allow refunds and withdrawal, and third parties such as x402r add refund and arbitration. Source [35, 37, 38, 39]
How much does x402 cost?
The protocol charges nothing. Costs are facilitator fees and gas. The CDP facilitator makes the first 1,000 on-chain transactions each month free, then charges $0.001 per transaction, and verification is free (as of 2026-10-11). Source [41, 51, 100]
MisconceptionHow big is x402 really?
Contested. The x402.org counter showed $24.24M over 30 days but was last updated 2026-08-25; Visa and Artemis adjusted cumulative activity to about $15.0M across 109.6M transactions (data to 2026-04-21); an academic study argues settlement counts can be manufactured almost for free. Source [74, 76, 78, 79]
MisconceptionIs the Cloudflare Monetization Gateway the same thing as cloudflare:402?
No. The Monetization Gateway closed beta (2026-09-30) settles USDC on Base through Coinbase's facilitator. cloudflare:402 is a separate credit-backed batch-settlement variant where Cloudflare is merchant of record. Source [20, 50]
MisconceptionIs x402 the same as L402?
No. L402 is an earlier HTTP 402 payment design on Lightning by Lightning Labs, launched as LSAT on 2020-03-30 with a macaroon plus a BOLT11 invoice and renamed L402 on 2023-04-20. Its bLIP-0026 draft, rewritten on 2026-02-25 and still an open pull request, makes macaroons optional. No source states that L402 is the ancestor of x402, and x402's own Lightning binding sends only a preimage, no macaroon. Source [19, 33, 36, 94, 95, 96]
Does x402 limit how much my agent can spend?
The protocol does not; budgets are out of scope. The TypeScript client applies spendControls by default: only default assets and at most $1 per payment, unless you change or disable them. Source [7, 10, 22, 49, 52]
Who runs x402scan?
Merit Systems, which publishes the source on GitHub and is a General member of the x402 Foundation. Source [4, 102]
R. Open questions and research frontier
How much x402 activity is real commerce?
Raw counters, Visa and Artemis adjusted figures and academic counts disagree by an order of magnitude, and the x402.org counter has not visibly moved since 2026-08-25. A shared, published method for labeling organic payments does not exist yet. Source [74, 76, 77, 79]
Will a2a-x402 be updated for AP2 v0.2?
The a2a-x402 v0.2 embedded flow puts requirements in an AP2 v0.1 CartMandate, which AP2 v0.2 no longer has. The two transport specs also use different extension URIs. Source [16, 88, 89]
Can payment and delivery be made atomic?
Each payment flow shifts risk to one side. A402 proposes Atomic Service Channels; auth-capture adds refunds but not proof of delivery. Source [34, 38]
How decentralized will facilitation be in practice?
Anyone can run a facilitator, yet most payments go through one, and new products such as the Cloudflare Monetization Gateway also route through it. Facilitator safety rules from research are not part of the spec. Source [41, 50, 54, 55]
What will the identity, tax and card-acceptance working groups produce?
The x402 Foundation has wg-identity, wg-tax, wg-card-acceptance and wg-domain-discovery repositories, but no specification text from them yet. Source [93]
Will SDK parity catch up?
TypeScript covers 13 network families; Python lacks auth-capture and Solana batch-settlement; offer-receipt is TypeScript only; the Java module is unpublished; x402-a2a is not on PyPI. Source [52, 80, 132]
Should payment metadata be minimized by the spec?
Resource URLs and descriptions reach facilitators that may not have data agreements with payers; research proposes filtering middleware, but the spec has no rule. Source [10, 81]
Will the GitHub advisories get CVE identifiers, and will reporting move to the foundation?
Neither high-severity advisory has a CVE id, and SECURITY.md still routes reports to Coinbase's HackerOne program. Source [62, 63, 139]
S. Self-test
Quiz
0 of 10 answered.
Flashcards
0 of 15 marked known. Card 1 of 15.
Prompt
PAYMENT-REQUIRED
T. Notes
Notes stay in this browser. Nothing is sent anywhere.