All posts

Answering the three x402 problems

Double-spend, metered billing and the refund round-trip, answered with a collateral-backed x402 scheme.

Mairon MahzounMairon Mahzoun5 min read
  • 402
  • apify
  • settlement
Abstract impasto painting in green, amber, and cream

At the AI Engineer World's Fair, Jan Čurn, the CEO of Apify, gave a talk titled x402 isn't good (yet). It is the most useful critique of the protocol so far, because it comes from running x402 in front of twenty thousand Actors rather than from a whitepaper. This is a reply with code attached: two of the three answered outright, and the third left where it is, since a cryptographic payment guarantee does not care which protocol carries it.

x402's three problems

Double-spend. Between the moment a buyer signs a payment and the moment it settles, nothing stops the same funds from backing a thousand other signatures. The seller does the work and finds out later.

401 versus 402. MCP authentication wants a 401 first, and x402 wants a 402. Servers end up split into one hostname per payment protocol, "twenty different Amazons".

Metered billing. The upto scheme of x402 double-spends. The workaround is to charge the maximum, do the work and refund the rest: two transactions per job, and the buyer has to trust the seller to send the second one.

What 4Mica changes

The 4mica-credit scheme replaces the transfer authorization with a signed guarantee against collateral the buyer has already deposited with 4Mica.

Lock before work. Each request carries a guarantee for an amount. 4Mica locks that amount from the buyer's collateral at issuance, before the seller starts. Two signatures cannot lock the same dollar, so the thousand-signature attack fails at the facilitator instead of in the seller's ledger.

Same host, same header. 4mica-credit is an entry in the accepts array of an ordinary 402, verified and settled through a facilitator that serves the standard /verify, /settle and /supported. The entry carries its EIP-712 domain in extra, as Apify's exact entry carries its name and version, so a client signs from the 402 and a key and never calls 4Mica. It adds no host, and it does not solve the 401 versus 402 conflict either, but a cryptographic guarantee is indifferent to which encoding advertises it and which protocol (x402, MPP or another) uses it.

Cap at signing, exact at the end. The buyer signs once, for the cap. When the run ends, the seller signs a guarantee back to the buyer for the unused part, under the same domain the cap advertised, and returns it with the result. The buyer holds a collateral-backed refund the moment the response arrives, not a promise of a second transaction. When the cycle commits, 4Mica nets the two guarantees to what the run cost. Nothing expires, nothing is held for fourteen days, and nothing moves on-chain per run. Guarantees then net once per cycle into one on-chain movement per participant: agents paying Apify, Apify paying developers, Actors calling Actors, all in the same netting.

What batch-settlement gives, and what it does not

The talk pointed at Coinbase's batch-settlement as the way out, and it is a real answer: the buyer escrows once, signs cumulative vouchers off-chain, and the server claims them in batches with a settlement override for dynamic prices. That closes double-spend and metering.

Its channel is between one payer and one receiver. A buyer that uses fifty sellers funds fifty escrows, and every seller runs a channel manager, a receiver signer and channel storage. With 4Mica, the buyer's deposit is one position usable at every seller, the seller runs nothing beyond the facilitator calls it already makes, and settlement is one net position per participant per cycle. There is also no approve transaction and no ETH float, which upto needs for its Permit2 allowance.

The demo

The demo is a mock of Apify's Actor run endpoint and an MCP server with one paid tool, both returning Apify's 402 exactly as the live endpoint does today, upto and exact included, with 4mica-credit as a third entry. The buyer is mcpc, Apify's MCP client, on a branch that signs the scheme. Base Sepolia, real collateral, the hosted facilitator.

Two paid run-actor calls through mcpc: a 0.01 USDC cap signed, 0.008 charged for five results, 0.002 refunded as a guarantee back to the buyer, and both wallets' locks before and after

What the recording shows, in order: both wallets' collateral and locks before; the decoded 402 with three ways to pay; one mcpc connect with --x402 4mica-credit; two run-actor calls, each a 0.01 USDC cap, 0.008 charged for five results, 0.002 signed back to the buyer, with the certificate in the result; and both wallets after. The buyer's lock grew by the two caps, the seller's by the two refunds, and when the cycle commits, 4Mica nets the four guarantees to 0.016 USDC in one settlement. Second call, fresh signature: a guarantee's request id is accepted once, so the fork never reuses one.

Notes

In the upcoming 4Mica release 4Mica will count the guarantees a wallet holds as collateral for the guarantees it signs. A seller holding a 1 USDC guarantee from a buyer can sign up to 1 USDC back against it, no deposit needed, and netting collapses the pair to what the run cost. The refund is then the cap's own backing returned, and the seller's balance never enters.

The trust model is the same as upto's: the seller settles any amount up to the cap the buyer authorized. The evidence and dispute semantics on top of that are the conversation we would rather have with the team that owns Apify's ledger than settle on our own.

Settlement latency. Net positions settle about a day after cycle close. Cycle length is per deployment; daily is the default.