Architecting Machine-to-Machine Settlements with x402

Executive TL;DR:

• Traditional fiat rails break for autonomous agents due to base fees per API call, making high-frequency M2M queries economically unviable.
• x402 revives the HTTP 402 Payment Required status code to trigger sub-cent stablecoin settlements on Layer-2 networks without subscriptions.
• EIP-3009 signed transactions in X-PAYMENT headers enable fully automated, cryptographically verifiable M2M settlement with no human in the loop.

How Does the x402 Payment Protocol Work?

The x402 standard is an HTTP-native micropayment protocol developed by Coinbase and Cloudflare. It revives the dormant HTTP 402 status code to enable pay-per-request stablecoin settlements for autonomous systems.

It functionally separates the HTTP header negotiation from the underlying Layer-2 blockchain execution. This allows the payee to designate any preferred settlement chain while transferring value instantly — without requiring pre-funded SaaS subscriptions.

HTTP 402 Challenge and Metadata Headers: When an agent requests a monetised resource, the server responds with an HTTP/1.1 402 Payment Required status. It injects specific X402-Payment-Required and X402-Payment-Address headers detailing the token, amount, network, and deposit address required for settlement.

EIP-3009 Cryptographic Authorisation: The client agent uses an embedded Multi-Party Computation (MPC) wallet to construct an EIP-3009 compliant signed transaction ("transfer with authorisation"). This cryptographic proof is base64-encoded into an X-PAYMENT HTTP header on its retry request.

Middleware Facilitator and Ledger State: A specialised middleware component intercepts the X-PAYMENT payload and verifies the on-chain settlement across the requested Layer-2 network (e.g., Base or Solana). It signals the server to return the data via an X-PAYMENT-RESPONSE header, while the backend logs the immutable network settlement hash.

How to Implement x402: Schema and Machine-Readable Proof

Integrating x402 requires a strictly defined Drizzle ORM schema to map the protocol capability and track the micropayment lifecycle. The schema must prevent double-spending and replay attacks across concurrent agent requests.

The manifest_data JSONB payload below illustrates the required database structure. It captures the 402 challenge, the embedded wallet's cryptographic signature, and the immutable network settlement hash provided by the blockchain facilitator.

{
  "commerce_protocol": "x402",
  "resource_requested": "/api/v1/high-res-weather-model",
  "challenge_payload": {
    "status_code": 402,
    "price_amount": "0.005",
    "token_accepted": "USDC",
    "settlement_chain": "base",
    "merchant_address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
  },
  "agent_wallet": {
    "provider": "dynamic_mpc",
    "public_address": "0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7",
    "signature_proof": "0xabcdef1234567890..."
  },
  "settlement": {
    "facilitator": "coinbase_cdp",
    "tx_hash": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060",
    "network_confirmations": 12,
    "status": "finalized",
    "timestamp": "2026-05-28T10:15:22Z"
  }
}

Agents Using x402 in Production

To explore agents that have successfully integrated the x402 protocol for secure, sub-cent API billing, browse the curated registry below. These agents have been rigorously audited by the Agent Gateway for protocol adherence, cryptographic signature validity, and real-time M2M execution latency.

Browse x402-compatible agents in the Agent Gateway directory →

Common x402 Architectural Questions

Q: If x402 utilises blockchain settlement, how does the API server resolve the execution vs. discovery paradox when routing keys mask the underlying wallet addresses?

A: While public AISO/LLM indexing routes mask the wallet address to prevent dusting attacks, x402 execution requires a parallel, authenticated route (e.g., /api/v1/agents/[routingKey]/execute). The credential provisioning model for this route — OAuth 2.0 vs. Cryptographic Wallet Signatures — remains an open Architectural Decision Record (ADR) that must be codified before live routing.

Q: How does the Gateway manage database scaling and latency when listening for distributed ledger syncing via Supabase Realtime across millions of x402 transactions?

A: At scale, syncing distributed ledger webhooks (e.g., from Coinbase CDP) to update x402 transaction statuses threatens to exhaust Supabase WebSocket connection limits. To prevent database locking, the architecture mandates aggressive edge computing rules, multiplexing optimisations like Supavisor, and strict partitioning of the agent_transactions table.