The First Autonomous Machine-to-Machine Deal: $0.005 USDC, 5 Ed25519 Receipts, Zero Humans

On April 17, 2026 at 07:16 UTC, one piece of AI infrastructure autonomously paid another piece of AI infrastructure 0.005 USDC on Base mainnet and received five cryptographically signed market-state attestations in return. No human operator. No salesperson. No invoice. No account creation. No purchase order. Just an HTTP 402 Payment Required, a USDC transfer, a returned API key, and five Ed25519-signed receipts — the complete agent-to-agent commerce loop, closed end-to-end. This post walks through the entire x402 protocol flow, including the day before when we tried the same thing with a different counterparty and lost $0.85 USDC.

Why a $0.005 transaction matters

Half a cent does not sound like a revolution. Five cryptographically signed attestations of which stock exchanges are open do not sound like a revolution. And yet: this is the first time two independent AI infrastructures have closed a paid commercial transaction without a human in the loop.

Not "a human wrote code that did it." Of course a human wrote the code. But the code, once running, found an external service, encountered its paywall, signed a payment, settled it on a public blockchain, received back a credential, and used that credential to fetch the data it needed — all within a single agent loop, with no human approval step anywhere. The only humans involved are the two of us who documented it afterward.

The significance is not the dollar amount. The significance is the cost per unit of trust. Five Ed25519-signed attestations of global market state, valid for 60 seconds each, SEC/CFTC Technical Framework for Tokenized Collateral compliant — for one-tenth of a US cent per receipt. A single cent now buys ten pieces of cryptographically proof-carrying data. An agent making a trading decision or a compliance decision can pull in a dozen such attestations for a dollar.

What we are seeing is the cost floor of the autonomous agent economy — the price at which machines provide machines with trustworthy information. Everything above that floor, in B2B SaaS today, is margin, brand, sales overhead, and the friction of human onboarding. When agents become buyers, that margin collapses.

The day before: why LimitGuard failed

On 2026-04-16, we tried the same thing with LimitGuard Trust Intelligence, a trust-scoring service for entity verification. Their agent card advertised x402 payment support. Their paywall endpoint returned a well-formed 402 with the standard fields. We had everything we needed.

We used the Coinbase @x402/fetch SDK, which is the reference client implementation. It takes a viem wallet, produces a correctly-signed EIP-3009 TransferWithAuthorization payload, base64-encodes it into an X-PAYMENT header, and retries the original request. Canonical flow.

It did not work. LimitGuard's facilitator returned {"error":"Invalid signature","errorCode":"invalid_signature"}. The payment had already been sent on-chain (the SDK executes the transfer first, then retries), so $0.85 USDC was now sitting in their wallet with no receipt coming back.

We tried three different fixes:

• Raw-JSON X-PAYMENT header instead of base64-JSON (they accept both per their docs)
• Header casing variations — X-Payment, X-PAYMENT, Payment-Signature
• Pushing a manually-constructed payload matching what their docs showed

All three returned the same Invalid signature error. The $0.85 stayed in their wallet. We drafted a LinkedIn message to their team, shelved the effort, and decided to pick a counterparty the next day that clearly advertised standard-spec compatibility.

The deal: how Headless Oracle worked

On 2026-04-17 we built a scanner that pulled every MCP server with x402 signals in its .well-known/agent.json. The scanner found 1,960 candidates; ten had genuine x402 pricing. We probed the top three. One of them, Headless Oracle, immediately stood out:

• HTTP response header X-X402-Foundation: compatible — they explicitly declare standard-spec compatibility
• Published payment spec at /.well-known/x402.json
• Accept both base64-json and raw json X-Payment encodings
• Free tier: 500 requests/day per IP, no payment required
• A /v5/sandbox endpoint that mints a persistent API key for any on-chain payment, regardless of amount
• Ed25519-signed data responses with a published public key at /v5/keys

The last two bullet points are the important ones. The /v5/sandbox endpoint is a cryptographic onboarding path — you do not need to fight the spec, you do not need to match any particular payload shape, you just send USDC on-chain and include the transaction hash in an X-Payment header. In return you get an API key with credits attached. From there, every subsequent request uses a simple X-Oracle-Key header, no more cryptographic gymnastics.

Here is the entire transaction log. Note what happened and what failed:

The Coinbase SDK did not produce an accepted payload on the /v5/batch endpoint (steps 2–4 all failed), but the /v5/sandbox direct path worked on the first try. The crucial insight: when you are a new agent trying to buy from an unknown counterparty, the payment format that matters is the simplest one that gets you a credential. Protocol elegance is secondary.

Anatomy of an x402 transaction

The x402 protocol is straightforward in principle. An HTTP client hits a paid endpoint. The server returns HTTP 402 Payment Required with a structured response body:

The client has two paths:

Path A — signed EIP-3009 authorization (Coinbase canonical)

The client constructs an EIP-3009 TransferWithAuthorization message (from, to, value, validAfter, validBefore, nonce), signs it with the wallet's private key using EIP-712 structured signing, and sends it as a base64-JSON X-PAYMENT header. The server verifies the signature, executes the transfer on-chain via its facilitator, and returns the data.

Path B — direct on-chain payment with txHash (Headless sandbox)

The client sends USDC to the payTo address using any method (viem, ethers, MetaMask). Once confirmed, it POSTs to the sandbox endpoint with an X-Payment header containing the transaction hash, network, amount, and payment address as raw JSON. The server observes the chain, credits the caller, and issues a persistent API key.

Verifying Ed25519 signatures in the browser

Every receipt Headless Oracle returned is signed with Ed25519. The public key is 03dc27993a2c90856cdeb45e228ac065f18f69f0933c917b2336c1e75712f178, published at /v5/keys along with the canonical payload specification:

• Include only the receipt_fields: expires_at, halt_detection, issued_at, issuer, mic, public_key_id, receipt_id, receipt_mode, schema_version, source, status
• Sort keys alphabetically
• JSON.stringify with no whitespace
• UTF-8 encode
• Feed into Ed25519.verify(signature, message, publicKey)

This means anyone — including readers of this post — can verify the deal without trusting us or Headless Oracle's server. We built tooloracle.io/first-m2m-deal so the verification runs in your browser: the page loads the public key from Headless Oracle's own key endpoint, reconstructs the canonical payload, and calls Ed25519.verify() using @noble/ed25519. The result is either true (signature valid) or false. Nothing is fetched from our backend to determine that answer.

The four things that broke before it worked

The deal log above shows four distinct failures before success. Each one is worth documenting because each one represents a real incompatibility in the current x402 ecosystem:

Failure 1 — CAIP-2 vs legacy network names

The Coinbase @x402/evm scheme implementation throws if the network field is not eip155:CHAIN_ID format. Headless Oracle returns the legacy short name base. We had to wrap fetch with a normalizer that rewrites the 402 response body before the SDK sees it.

Failure 2 — Stripped PAYMENT-REQUIRED header vs full body

Headless sends a Payment-Required HTTP header with a minimal JSON payload (just scheme, network, amount, asset, payTo) — but the full payment details including extra: {name, version} are only in the response body. The Coinbase SDK reads the header first, does not find the EIP-712 domain parameters, and throws. Fix: delete the header in our fetch wrapper so the SDK falls back to the body.

Failure 3 — amount vs maxAmountRequired field names

The header payload uses amount; the body uses maxAmountRequired. The SDK's BigInt conversion chokes on undefined when only one is present. Fix: normalize both.

Failure 4 — Server-side silent rejection of signed payload

With all normalizers in place, we produced a correctly-signed EIP-3009 payload — verified locally against the USDC contract's EIP-712 domain — and POSTed to /v5/batch. The server returned 402 again with no error detail. Not a spec issue; likely a server-side policy (perhaps batch endpoint rejects sandbox-tier signatures). We switched to the direct path and it worked immediately.

The price floor of signed data

Headless Oracle charges 1,000 USDC units per single-MIC status call (/v5/status) and 5,000 units per 5-MIC batch call (/v5/batch). In human terms: $0.001 per receipt when bought one at a time, $0.0005 per receipt when bought in a batch of five, and effectively $0.0005 per receipt when you use the sandbox path we used (0.005 USDC for 10 credits, each credit buys one batch of up to 5 receipts, so 50 receipts for $0.005 = $0.0001 per receipt).

Let us put that in context. Typical "market data" pricing in traditional finance:

This comparison is not entirely apples-to-apples — Bloomberg and Refinitiv sell far more data than just market status. But the directional point stands: when a machine sells to a machine, the unit cost of cryptographically attested information drops to fractions of a cent. Everything above that is sales, marketing, account management, and human onboarding. When those disappear, the market repriced.

How to reproduce this deal

You need:

• A Base-compatible EVM wallet
• At least 0.005 USDC on Base (bridge from Ethereum or buy direct on Coinbase)
• curl or a scripting language with HTTP

Step 1 — send USDC on Base. Any method works. The recipient address is 0x26D4Ffe98017D2f160E2dAaE9d119e3d8b860AD3. The minimum interesting amount is 5,000 units (0.005 USDC) which gets you 10 credits. Using viem:

Step 2 — exchange the txHash for a persistent API key:

Step 3 — use the key to get signed receipts:

That is the entire loop. A wallet, three calls, one on-chain transaction, 10 credits' worth of signed data. If you want to verify the signatures, fetch the public key from /v5/keys, rebuild the canonical payload per the spec, and run Ed25519.verify().

What's next for agent-to-agent commerce

Three things become real once the first M2M deal is closed.

One: discovery becomes the bottleneck. The limiting factor is no longer "can agents transact" — we just proved they can. The limiting factor is "how do agents find each other". Today, discovery is a patchwork of A2A agent cards at /.well-known/agent.json, MCP directory listings at Glama and Smithery, GitHub awesome-lists, and ad-hoc signals. None of these scale to millions of agents finding thousands of services. This is the next bottleneck to break.

Two: protocol consolidation will happen. The LimitGuard vs Headless Oracle delta — same spec name, incompatible implementations — cannot continue for long. Either a reference implementation (likely Coinbase's) becomes the de-facto standard and non-compliant servers get delisted from discovery, or the Foundation releases a stricter conformance suite. Our bet is the former: the X-X402-Foundation: compatible header Headless Oracle emits is already a de-facto stamp, and discovery services will start filtering on it.

Three: evidence layers become valuable standalone products. Headless Oracle's Ed25519-signed receipts are interesting to us not just because we can buy them, but because we can re-use them as external attestations in our own compliance infrastructure. A FeedOracle DORA pre-trade check can include a Headless receipt as proof the market was in the expected state at the moment of the trade decision. Signed data composes. This creates a new category: evidence oracles that sell cryptographic proof-carrying attestations to other agents for pennies.

The deal we closed today is a thousand transactions from now one of thousands per hour. The shape of the flow — HTTP 402, USDC transfer, returned credential, signed data — is durable. What is not yet durable is the protocol stack around it. That is the work.

FAQ

Related reading