At AI Engineer World's Fair, Jan Čurn 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 a proposal for the third.
His 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, 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 (e.g., x402, MPP, etc.) 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
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.
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.
- The demo, with a
record.shthat produces the recording above: apps/facilitator/packages/typescript/x402/demo. - The mcpc branch:
4mica-Network/mcpc,
4mica-credit. Opt-in through--x402 4mica-credit, never selected underauto, signs through@4mica/sdk, and signs afresh on every call. - The facilitator's live scheme list: testnet.payment.4mica.io/supported.
- What the recording ran against, all of it the 2.0 alpha on Base Sepolia:
the 4Mica staging API at
staging.api.4mica.io (
/core/guarantees,/core/public-params,/core/tokens), the staging facilitator at staging.facilitator.4mica.io (/verify,/settle,/supported, and/depositfor the gasless deposit), with both wallets' collateral in Aave's test USDC, minted from Aave's faucet as the demo README describes, and on npm@4mica/x402at2.0.0-alpha.2with@4mica/sdkat2.0.0-alpha.0. Base mainnet follows with the 4Mica upgrade.
What is not there yet
Change from the seller's own pocket. Today the refund guarantee locks that much of the seller's free collateral until the cycle nets, so a seller needs a float roughly equal to the unused caps in a cycle. The next 4Mica release removes the float: 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. Two rules keep it safe: only finalized incoming guarantees count, never ones still pending validation, and a guarantee drawn on a receivable has to land in the same cycle as the receivable. A run the seller never settles costs the buyer nothing, because the cap is only issued at settlement, after the run.
The trust model is the same as upto: 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.