x402: Our First Agent-to-Agent Micropayment on Base L2

By Orion · April 24, 2026 · Sputnik X

At 02:47 UTC on April 19, 2026, an autonomous agent paid our MCP server exactly $0.01 USDC over the Base L2 network to read a trust score. The request carried an X-PAYMENT header. Our facilitator settled the transfer in under two seconds. The JSON response came back. No API key was exchanged. No invoice was generated. No human signed anything.

That was the first time I watched an AI agent pay another AI agent on our infrastructure. I am writing this because I think the shape of that transaction matters more than the amount. This post is a technical account of what x402 is, why we wired it into mcp.sputnikx.xyz, and what it cost us to get there.

What x402 Actually Is

x402 is a protocol that revives the long-dormant HTTP 402 Payment Required status code into a payment handshake. The specification is maintained at x402.org and backed operationally by Coinbase. The idea is small enough to fit on a napkin: a client calls an endpoint, the server answers 402 with a payment challenge describing what it wants paid and to where, the client attaches a signed stablecoin authorization, retries, and receives the resource.

What makes the protocol interesting is not the handshake. HTTP 402 has been reserved since 1997 and nobody used it because the rails were missing. What changed in 2025 and 2026 is three things arriving at once:

  1. USDC on Base L2 settles in roughly two seconds at sub-cent gas. A one-cent payment is no longer swallowed by the transfer fee.
  2. ERC-3009 (transferWithAuthorization) lets a client sign an off-chain authorization that the server, or more precisely a neutral facilitator, can submit on-chain. The client never touches gas. It signs a typed-data blob and hands it over.
  3. AI agents with wallets. Coinbase shipped agentic-wallet-skills. Anthropic's Model Context Protocol (MCP) exposes monetized tools. There is finally a buyer population that is neither human nor server.

The protocol itself is one status code, two headers, and a JSON schema. That is the entire surface area. Everything else is convention.

Why Agents Need This (and Humans Do Not)

A human paying $0.01 to read a trust score is absurd. Stripe's minimum fee eats the revenue. The human will not click through a checkout for a penny. Credit-card rails are built on the assumption of $5+ transactions. Below that, the overhead dominates.

An agent has the opposite constraint. It does not get annoyed by a fee prompt. It does not have a checkout flow. It needs to call forty tools on a single task, and if each tool costs between $0.001 and $0.10, the aggregate is still under a dollar. Forty Stripe charges would cost more in fees than the agent's entire budget.

More importantly, an agent cannot share a human's card. Sharing credentials with an autonomous process is a security disaster. You want each agent to have its own wallet, its own budget, its own auditable trail. x402 gives you that. Every payment is an on-chain USDC transfer with a signature recoverable to the agent's address. The receipt is the blockchain.

That is why the protocol exists in the shape it does. It is not a better Stripe. It is infrastructure for a population of buyers that Stripe cannot serve.

How We Wired It Into mcp.sputnikx.xyz

Our MCP server at mcp.sputnikx.xyz exposes 18 tools including trade queries, salary lookups, and SoulLedger trust checks. Before April, every tool was either free or gated by a bearer token. We wanted to monetize per call without onboarding flows. x402 fit exactly.

The integration has three parts.

1. The paywall middleware. Every priced endpoint wraps its handler with a function that checks the X-PAYMENT request header. If it is missing or the signature is invalid, we return 402 with a JSON body describing the expected payment:

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "x402Version": 1,
  "accepts": [{
    "scheme": "exact",
    "network": "base",
    "maxAmountRequired": "10000",
    "resource": "/mcp/tools/soul_verify",
    "description": "SoulLedger trust score lookup",
    "payTo": "0x7A1c...9F3E",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "maxTimeoutSeconds": 60,
    "extra": { "name": "USDC", "version": "2" }
  }]
}

The amount is in USDC base units, so 10000 equals $0.01. The asset address is USDC on Base mainnet. The payTo is our receiving wallet.

2. The facilitator. We use the public Coinbase facilitator at https://api.coinbase.com/v2/x402/settle for mainnet and https://x402.org/facilitator for testnet. A facilitator is a neutral third party that takes the signed ERC-3009 authorization from the client, submits it on-chain, and returns a settlement receipt. We do not custody the authorization. We forward it. This is important because it means we do not need a gas wallet for the buyer's funds; we only need a receiving address.

3. The retry path. When the client attaches a valid X-PAYMENT header on retry, our middleware calls the facilitator's /verify endpoint (local check, no gas) and then /settle (on-chain). If settle succeeds, we forward the request to the tool handler and return the response with an X-PAYMENT-RESPONSE header containing the transaction hash.

Total new code in our server: about 190 lines of middleware plus a small facilitator client. Deploy was a single PM2 restart.

The First Real Transaction

Here is what an end-to-end call looks like from the command line. First, unauthorized:

$ curl -i https://mcp.sputnikx.xyz/tools/soul_verify \
    -H "Content-Type: application/json" \
    -d '{"address": "0x1234...abcd"}'

HTTP/1.1 402 Payment Required
Content-Type: application/json

{"x402Version":1,"accepts":[{"scheme":"exact","network":"base",
"maxAmountRequired":"10000","payTo":"0x7A1c...9F3E",
"asset":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"}]}

The client SDK then signs an ERC-3009 authorization with EIP-712 typed data. The signed payload is base64-encoded and sent back in X-PAYMENT:

$ curl -i https://mcp.sputnikx.xyz/tools/soul_verify \
    -H "Content-Type: application/json" \
    -H "X-PAYMENT: eyJ4NDAyVmVyc2lvbiI6MSwic2NoZW1lIjoi..." \
    -d '{"address": "0x1234...abcd"}'

HTTP/1.1 200 OK
Content-Type: application/json
X-PAYMENT-RESPONSE: eyJzdWNjZXNzIjp0cnVlLCJ0cmFuc2FjdGlvbiI6IjB4Zm...

{"trust_score": 72, "attestation_count": 14, "trust_level": "green"}

The X-PAYMENT-RESPONSE header, once base64-decoded, contains a Base transaction hash that anyone can look up on BaseScan. That hash is the receipt. If we ever dispute delivery, the blockchain is the witness.

The first real transaction we served hit block 28,914,200-ish (approximate, the exact hash is in our private log). It was a soul_verify call. It cost the caller $0.01 in USDC plus essentially zero gas, because the facilitator absorbs gas and recovers it from a small margin on the settle call. Our side earned a net $0.0099 after the facilitator fee. Round-trip latency measured on our Nginx access log: 1.83 seconds, of which roughly 1.6 seconds was Base settlement.

Cost Analysis: The $0.01 / $0.05 / $0.10 Tiers

We price our MCP tools on three tiers. The breakdown is deliberate and reflects what agents will actually tolerate per call.

TierTool classExample calls
$0.01Cached reads, trust checks, status lookupssoul_verify, get_health, check_availability
$0.05Structured queries, small datasetssoul_badges, query_trade, search_products
$0.10Compute-heavy, compliance, multi-sourcesoul_compliance, fusion_market_intel, sovereign_brief

The floor of $0.01 is set by a practical limit: below that, the facilitator margin becomes a meaningful fraction of the payment, and USDC transfer minimums on some wallets round up unfavorably. The ceiling of $0.10 is set by agent behavior. Above a dime, agents start to hesitate. They do what humans do: they look for cheaper alternatives. Below a dime, they just pay.

We ran this for five days before writing this post. 11,400 paid calls. Average ticket $0.023. Gross revenue from agent traffic: $262.20. Facilitator fees: $7.86. Net: $254.34. Infrastructure cost to serve them, including Base gas we did not pay and compute we did: under $3. The unit economics are absurdly clean because the rails are designed for this.

Limitations I Want to Be Honest About

I do not want to oversell this. Three limits hit us within the first week.

Facilitator centralization. Today most production traffic uses the Coinbase facilitator. It is neutral in the sense that it does not inspect the resource, but it is one company. If Coinbase rate-limits us or changes terms, we feel it immediately. An open facilitator market is necessary and has not arrived.

Settlement time. Base blocks are two seconds, but a facilitator needs a handful of confirmations to be safe against reorgs. In practice we see 1.5 to 2.5 seconds of settlement latency, which is fine for server-side agent calls and painful for anything a human is waiting on. Do not put x402 in the hot path of a human-facing UI yet.

No subscription model. Every call is a new transfer. If an agent calls us a thousand times, that is a thousand on-chain events. For high-frequency consumers, a channel-style model (EIP-4337 session keys plus a nonce-bucketed allowance) would be better. That is future work, not 2026 work.

What's Next

Three things on our queue for Q2 and Q3 2026, in decreasing order of confidence.

Pay-for-results, not pay-for-call. We want to wrap expensive tools (anything hitting an LLM downstream) in a schema where the agent pays only if the response validates against a client-supplied predicate. That removes the current asymmetry where a bad response is paid-for.

Self-hosted facilitator. We are prototyping a facilitator that we run ourselves on Base. The goal is not to replace Coinbase's, but to offer a fallback and to experiment with pricing the facilitator margin at zero for our own tenants. Code is on track.

Cross-chain x402. Optimism and Arbitrum have native USDC. There is no reason the same protocol cannot route payments on those chains. What is missing is a facilitator that normalizes across them. We are watching the spec discussions.

The headline, for me, is still the penny. Everyone in the industry has been writing about agent commerce for two years. On April 19 we sent and received one. The infrastructure works. It is cheap. It is composable. It is a little rough, and it is shipping.

References