If 98.6% of your payment rail is denominated in a single stablecoin from a single issuer, you do not have a payment rail, you have a Circle dependency. That is where x402 sits right now. In March 2026, AI Monks put the USDC share at 98.6% of settled volume. Three weeks later, a six-hour CCTP delay let an attacker bridge $232M USDC. Those two facts combined are the case for multi-stable settlement. Any one of the following events — Circle outage, Circle freeze on a specific address, CCTP exploit aftershock, USDC depeg — would freeze essentially all agent-to-agent commerce for however long the event lasts.
The fix is not hard. It is also not free. Here is what we built.
A routed-stable settlement treats the stablecoin as an implementation detail of “one dollar paid and received.” At the L4 router, the payer specifies an amount in USD. The router looks at five live parameters and picks a stable:
The router then settles in the best candidate, swaps if necessary, and emits a signed receipt that binds the USD amount to the specific stable actually transferred. The merchant and auditor see “paid $0.42 USD, settled as 0.4199 FDUSD on Base.” The agent does not need to know or care.
We default to five stables across three issuers. That is enough diversification to survive any single-issuer event without being so broad that liquidity dries up on the long tail.
USDC (Circle) // primary, but capped at 60% share
USDT (Tether) // secondary, liquid everywhere
PYUSD (Paxos) // preferred in US-regulated flows
FDUSD (First Digital)// BNB-chain depth
USDS (Sky/MakerDAO) // over-collateralized fallbackWe deliberately exclude algorithmic stables and rebasing stables. The router also supports per-merchant policies — some enterprise merchants want PYUSD-only because of their own banking constraints, others are USDT-first because of Asian-exchange settlement.
The critical piece is a 60% share cap per stablecoin across the router. If incoming flow would push USDC above 60% of the hour’s settled volume, the router deliberately biases new settlements toward other stables — absorbing some modest swap cost to keep the exposure diversified. Caps are enforced at the router level, not at the per-call level, so individual calls can still settle in the agent’s preferred stable; it is aggregate balance that gets steered.
This is the property that x402 cannot have by itself. x402 is a transport, not a portfolio manager. The cap has to live at the layer that sees all traffic.
A stable is considered depegged for routing purposes when its 30-minute median price crosses a threshold — we use ±50bps for the top three, ±100bps for the others. When that trips, three things happen.
The oracle we use is a quorum across three independent price sources. Chainlink, Pyth, and a router-internal volume-weighted price from the DEX pools we bridge through. We wrote about quorum in the free-RPC piece; the same pattern applies.
Circle and Paxos can freeze addresses. This has happened. For a merchant layer, the worst case is that a freeze hits your hot wallet mid-flight. Our defense is three-layered. First, we run Sniper scans against the destination before settling — if the recipient is already flagged, we refuse the settlement and return an error before funds move. Second, we rotate hot wallets frequently so the balance at any single address is small. Third, if a freeze happens, the router can complete open settlements using the other four stables while the frozen wallet is excluded from the pool.
Multi-stable settlement is not free. Swapping between stables via the on-chain liquidity we use costs roughly 5 to 15 basis points on the top pairs. We absorb that cost rather than pass it to the payer, and we offset it via the router’s margin on the call. At current traffic the total swap burn is under 0.3% of gross settled volume. That is cheaper than a single freeze event would be.
We do not fork x402. We speak it. The payer announces which stables they can send in the standard X-Payment-Required-style header. The router responds with the selected stable, chain, and recipient, and includes an attestation hash so the payer can verify the resulting settlement. A plain x402 client that does not understand multi-stable receives the same experience it has today: USDC, unless USDC is unavailable, in which case it gets a clean error and can retry with another stable it holds.
// Request
X-Accept-Stables: USDC,PYUSD,FDUSD
X-USD-Amount: 0.42
// Response (router selected best candidate)
X-Settled-Stable: PYUSD
X-Settled-Chain: ethereum
X-Settled-Amount: 0.4199
X-Receipt-TypeHash: 0x...If you are building on x402 or any agent-payment rail, your production-readiness checklist has to include multi-stable or you are not production-ready. Single-stable concentration is the crypto equivalent of running your business from a single AWS region with no backup. It works until the day it doesn’t, and then nothing works.
The L4 router, the bidirectional bridge, and the PCP economics are all designed around the assumption that the current concentration has to come down. You should assume the same.