x402Escrow
Extending the x402 payment protocol with on-chain escrow to enable usage-based, pay-per-token billing for AI services
Accept payments for AI inference
The x402 protocol enables machine-to-machine payments via HTTP 402. Its exact scheme works for fixed-price endpoints, but AI inference costs are unknown at request time with token generation ranging from 1,000 to 100,000 tokens per call.
We introduce a UUPS-upgradeable escrow smart contract between client and server.
Settlement Flow of x402Escrow
Request
Client sends an API request to the MCP server. Server responds through HTTP 402 with max cost, escrow address, and signing parameters.
Lock
Client signs receiveWithAuthorization (gasless EIP-3009 authorization) for max amount to escrow contract. Facilitator callssettle()—USDC is locked in escrow.
Generate
Facilitator forwards request to MCP. Inference executes. Actual token cost is metered.
Release
Facilitator calls release(escrowId, actualCost). Contract pays facilitator and refunds the remainder to client.
Failsafe
If facilitator never calls release(), anyone can call refundAfterTimeout(escrowID) to return funds to client.
Key design decisions
EIP-3009
receiveWithAuthorization
(not transfer)
Only the escrow contract can execute transfers.
→prevents MEV frontrunning
Packed single-slot storage
One 32-byte slot per escrow:
address client (20 bytes) +
uint40 refundAt (5 bytes) +
uint56 amount (7 bytes)
→minimizes SSTORE gas costs
Stateless facilitator
release() pays msg.sender. Any address with FACILITATOR_ROLE can release.
→simplifying facilitator rotation
Universal refund
refundAfterTimeout() callable by anyone, funds always route to the original client
→guarantees recoverability
x402
Compatible
Maintains HTTP 402 semantics
Uses standard headers (PAYMENT-REQUIRED, PAYMENT-SIGNATURE)
Only settlement flow changes (escrow instead of direct payment)
Fully backward-compatible for clients that support escrow parameters
ERC-8183
Complementary
An agent can accept a job via ERC-8183 and then use x402Escrow to pay for the inference it needs to complete that job. The two protocols operate at different layers of the same agentic commerce stack.
ERC-8183
→answers:
"Did the agent complete the job?"
x402Escrow
→answers:
"How many tokens were consumed?"
Security properties
Client protection
Funds lock in the escrow contract
Pay only for actual tokens usage
Automatic refunds
Server protection
Funds are guaranteed locked before inference begins
MEV resistance
Only escrow contract can execute transfers
Reentrancy protection
ReentrancyGuard on all state-changing functions
SafeERC20 for all token transfers
Liveness guarantee
Anyone can trigger refunds → funds never stuck and always route to the original client
x402Escrow wins for AI inference
Fortytwo x402Escrow is built specifically for consumption-based AI billing
See x402Escrow in action