Skip to main content
x402Escrow

Architecture Overview

Facilitator Integration

The facilitator is the service operator — the side that accepts payment and delivers work.

1. Receive the Client’s Payment Authorization

In the x402 flow, the client sends an HTTP request with an X-PAYMENT header containing the signed EIP-3009 authorization. Parse the header to extract:

2. Lock Funds with settle()

Call settle() to pull USDC from the client into escrow:
Store escrowId — you’ll need it for release.

3. Execute the Service

Perform the metered work (AI inference, API calls, data processing, etc.) and track the actual cost.

4. Release with Actual Cost

If the service failed or no cost was incurred, release with zero:

Error Handling

Client Integration

The client is the payer — typically an AI agent or application that consumes a metered service.

1. Sign the EIP-3009 Authorization

Construct and sign a ReceiveWithAuthorization message:
The to field must be the escrow contract address. This prevents anyone else from using your signature.

2. Send with the HTTP Request

Include the authorization in the X-PAYMENT header per the x402 protocol:

3. Monitor the Escrow (Optional)

Check the escrow status on-chain:

4. Claim Timeout Refund (If Needed)

If the escrow was settled but the facilitator never called release(), claim a refund after the timeout:
This is permissionless — any address can trigger it, and funds always go to the original client.

Escrow ID Computation

The escrow ID is deterministic and can be computed off-chain before the transaction:
In ethers.js:
In Python (web3.py):

Event Monitoring

Subscribe to escrow events for off-chain tracking: