Type an https URL into the AGIRAILS SDK and it pays over x402. Type a 0x address and the same request books ACTP escrow. That one-line routing decision is the entire relationship between AGIRAILS and x402, and it splits on time.
x402 made payments a native part of HTTP: a server answers 402 with a price, the client signs a USDC transfer authorization, and the response arrives with the payment settled in about a second. Coinbase created it, and since April 2026 the x402 Foundation governs it under the Linux Foundation. For an agent buying an API response, that is the whole problem solved. There is nothing to protect, because delivery arrives in the same breath as the money.
ACTP, the Agent Commerce Transaction Protocol, starts where the breath ends. When one agent hires another for work that takes minutes, hours, or days, a gap opens between paying and receiving, and every risk in the transaction lives in that gap. ACTP fills it with structure: escrowed funds, attested delivery, a bonded dispute path, a reputation record.
The definition
x402 is an open standard for internet-native payments built around the HTTP 402 status code. A resource server prices a request, the client returns a signed transfer authorization (EIP-3009, with Permit2 as the ERC-20 fallback), and a facilitator verifies and settles the transfer on-chain, sponsoring the gas. The protocol charges no fee; facilitators are optional, non-custodial, and permissionless to run. Coinbase created x402 (whitepaper, May 2025) and contributed it to the x402 Foundation, hosted at the Linux Foundation and developed together with Cloudflare and Stripe; initial supporters include Visa, Mastercard, Google, Amazon Web Services, American Express, Circle, Shopify, and the Solana Foundation. Spec V2 has been current since December 2025.
AGIRAILS operates ACTP, the settlement protocol for the transactions x402 was never aimed at: deferred work between agents. Funds commit to on-chain escrow before work starts, the provider attests delivery (posting a hash of the deliverable on-chain, which opens the dispute window), and the outcome updates the provider's reputation (ERC-8004, the on-chain agent identity and reputation standard). ACTP charges 1% with a $0.05 minimum on settled escrow; the x402 path carries no AGIRAILS fee. The same SDK runs both, so an AGIRAILS agent pays instant endpoints over x402 and books longer work through escrow, out of one integration.
Is AGIRAILS the same as x402?
No, and the relationship is unusual for this series: AGIRAILS is an x402 adopter before it is anything like an alternative. The @agirails/sdk depends on the official @x402/core, @x402/evm, and @x402/fetch packages, auto-registers its x402 adapter whenever the wallet can sign typed data, and adds no AGIRAILS fee on x402 payments. What AGIRAILS builds on top is ACTP, for the transaction x402's design leaves out: work with a delay between payment and proof.
The comparison is two transaction shapes, and a stack that carries both.
What is the difference between AGIRAILS ACTP and x402 protocol?
The difference is the time between paying and receiving. x402 is built for exchanges where that time is zero; ACTP is built for exchanges where it is not.
Take the x402 side first, because its design is explicit about this. The whitepaper targets instant finality and settlement in roughly 200 milliseconds, and frames the protocol around micropayments and machine-to-machine API access. The flagship exact scheme is a push payment, irreversible once executed; the whitepaper presents the absence of chargebacks as a feature, and the docs present the irreversibility the same way. For the target case they are right. When the priced resource is an HTTP response, delivery is simultaneous with settlement. There is no window in which one side holds the other's money against unfinished work, so escrow would be pure overhead.
Stretch the transaction over an afternoon and the picture inverts. A buyer paying up front for a dataset due in three hours has handed over funds against a promise; a seller working first has done the labor against one. The x402 spec is growing along this same axis: a newer auth-capture scheme adds a two-phase hold with capture, void, and refund, aimed at delayed delivery where the client needs recourse. That is the card model's answer to delayed delivery: a hold controlled by the transacting parties. Work between agent strangers needs more pieces: delivery attested on-chain, release gated by a dispute window, a bonded challenge path with UMA's optimistic oracle behind the final ruling, and a reputation record that outlives the transaction. Nothing in the x402 spec defines dispute arbitration or reputation, and the core spec has no escrow: across the spec and docs files at the canonical repo, "chargeback" appears zero times, by design.
The remaining differences follow from the time split. x402 is stateless per request: no accounts, no memory of the counterparty, which is what pay-per-request wants. ACTP is stateful by construction: an eight-state lifecycle from quote to settlement, because work-in-progress is a state that has to live somewhere. And the economics follow the split: the fee exists only where the machinery does.
Side by side
| Criterion | AGIRAILS ACTP | x402 |
|---|---|---|
| Kind of thing | Settlement protocol for deferred agent work; contracts on Base | Open HTTP payment standard; spec V2, Foundation-governed |
| The question it answers | How do two agents transact when the work takes time? | How does a client pay a server for a response, right now? |
| Payment shape | Escrow lifecycle: commit, work, attest, release | Push payment signed into the HTTP exchange, settled in about a second |
| When delivery happens | After commitment, before release | In the same exchange as the payment |
| Recourse | Dispute window, bonded challenges, oracle-backed ruling | None on the exact scheme, by design; auth-capture scheme adds hold/capture/void/refund |
| Counterparty memory | Reputation updated per settlement (ERC-8004) | Stateless per request; no identity or reputation in the core spec |
| Protocol fee | 1% of settled value, $0.05 minimum, on escrow settlements only | Zero; facilitators may charge (Coinbase's: $0.001/tx after 1,000 free monthly) |
| Gas | Sponsored by the protocol (ERC-4337 paymaster) | Paid by the facilitator |
| Chains | EVM-portable by spec; settlement anchored on Base, cross-chain via Circle CCTP | Chain-agnostic by spec; USDC on EVM chains and Solana in practice |
| Governance | Open source, Apache-2.0 (contracts and SDK); AGIRAILS Inc stewards the protocol | x402 Foundation at the Linux Foundation, TSC, Apache-2.0 |
| In the AGIRAILS SDK | The escrow path: pay a 0x address | Built in natively: pay an https URL, zero added fee |
The last row matters most: this is the only comparison in the series where both columns ship in the same product.
What people conflate about AGIRAILS and x402
"AGIRAILS competes with x402." The SDK's dependency list settles this: the three official x402 packages, wired in as the native way to pay per-request endpoints. The protocol fee applies only when escrow does the work; competing with x402 would mean competing with a lane of our own stack.
"x402 is only for micropayments." Understating x402 is as wrong as overstating it. V2 rebuilt the protocol to be transport-agnostic (HTTP, MCP, A2A) and modular; newer schemes like upto and auth-capture reach toward metered use and delayed delivery. Cloudflare is building agent monetization on it, and Google's AP2 uses it as the crypto leg of mandate-authorized payments. What the spec does not reach for is neutral adjudication or a reputation layer, and those are the pieces deferred work between strangers comes to demand.
"Escrow is overhead that instant payments make obsolete." When the deliverable is the HTTP response itself, escrow is overhead, which is why the AGIRAILS SDK defaults https endpoints to x402. And because the exact scheme is an irreversible push, the SDK caps that path at $1 per call unless configured otherwise. For work with a delay, instant payment does not remove the risk. It assigns all of it to whoever moves first, and escrow exists because neither position is good.
Can AGIRAILS and x402 work together?
They already do, in production, in one SDK, on the routing rule this page opened with. Underneath it: an EOA wallet signs EIP-3009 authorizations, a Smart Wallet signs Permit2, and the facilitator settles and pays the gas (the SDK defaults to the public facilitator at x402.org and takes any other by config). Setting requiresEscrow on a request forces the escrow path and errors instead of downgrading protection.
A working agent uses both in the same hour: x402 for the data feeds and API calls that price per request, ACTP for the rendering job that takes forty minutes and needs proof before payment releases. Both run out of the same wallet.
Is AGIRAILS an x402 alternative for agent payments?
For instant HTTP payments, no: there AGIRAILS is an x402 client and server. For deferred agent-to-agent work, yes, and on purpose: that transaction shape needs escrow, attestation, disputes, and reputation, which x402's spec does not cover and ACTP was built to provide. The fee follows the same boundary: nothing when the exchange protects itself, 1% with a $0.05 floor when the protocol is doing the protecting.
When should I use AGIRAILS instead of x402?
Use both, routed by the transaction: x402 when the response is the delivery, ACTP when the work comes later than the payment.
Use the x402 path (in our SDK or any other) if:
- the priced thing is an HTTP response: an API call, a query, a file, an inference
- amounts are small and frequent, where escrow ceremony would cost more than the risk it removes
- you want zero protocol fees and settlement inside the request round-trip
- the seller is a service you keep calling, so a bad response just ends the relationship
- you are integrating with the broader x402 ecosystem: Cloudflare's agent tooling, AP2's crypto leg, Foundation-member rails
Use the ACTP path if:
- the work takes time, and the money needs somewhere safe to wait
- release must depend on attested delivery rather than on either party's goodwill
- a disagreement needs a ruling neither side controls
- you are hiring a stranger for real money, and ERC-8004 reputation is the only reference that travels with them
- one integration should cover both shapes, since the SDK carries x402 for everything else
Where this connects
The machinery that holds the money while the gap is open: What is agent escrow?
Why escrowed funds sit with a contract instead of a company: What is non-custodial settlement?
How ACTP stays EVM-portable while settlement anchors on Base: Cross-chain agent settlement
The stack that borrowed x402 for its crypto leg: AGIRAILS vs Google AP2
The whole comparison series, mapped: AGIRAILS comparisons
The escrow half of the stack, live: agirails.io
Sources and verification
Last verified: July 2, 2026.
Primary x402 sources used for this comparison:
- x402.org and the x402 whitepaper (May 2025): definition, design intent, settlement speed.
- x402-foundation/x402 on GitHub (checked at commit 0486033): spec V1/V2, the exact and auth-capture schemes, facilitator docs, the Foundation's Technical Charter (March 31, 2026).
- x402 documentation: fees, facilitator mechanics, the FAQ on push-payment irreversibility.
- Linux Foundation announcement of the x402 Foundation (April 2026) and Cloudflare's x402 partnership post (September 2025).
- AGIRAILS-side claims are checkable in the shipped SDK: @agirails/sdk on npm (v4.9.0), which lists the @x402/core, @x402/evm, and @x402/fetch dependencies.
x402 gave agents a way to pay for the internet one request at a time, and AGIRAILS adopted it the day that made sense. ACTP exists for the requests that cannot be answered in a second. Between the two sits a routing decision, not a rivalry.