Three chains for agent money: Tempo, Kite and Arc under x402

Three blockchains were built specifically so machines could pay each other. None of them appears in the x402 reference implementation's asset registry. That gap is the story.

In 2026 the settlement layer under agent payments stopped being a single question — "which L2 do we use?" — and became three concrete products. Tempo, incubated by Stripe and Paradigm, went to mainnet on March 18. Kite launched its chain and its Agent Passport on April 30. Arc, Circle's L1, has a public mainnet date of September 16 and eleven founding validators that read like a list of the world's clearing infrastructure.

All three describe themselves in the same words: stablecoin-native, sub-second finality, built for payments and for agents. That convergence is real. What is also real, and much less discussed, is that the payment protocol on top — x402 — does not care about any of those properties. It cares about one thing: what the token contract underneath can be made to do with a signature.

We cloned x402-foundation/x402 on 13 August 2026 (HEAD 74038ba) and read the three chains' own documentation. This is what the settlement floor actually looks like.

What x402 requires from a chain

Less than you would expect. The EVM mechanism in the reference implementation does not maintain an allowlist of chains. It registers against the wildcard eip155:* and extracts the chain ID from the CAIP-2 network identifier at call time. Any EVM chain is, in principle, already addressable.

The constraint lives one layer down. specs/schemes/exact/scheme_exact_evm.md defines exactly three ways to move an asset, and a payment can only happen if the token supports one of them:

• EIP-3009 — transferWithAuthorization on the token itself. Marked "Recommended (Simplest, truly gasless)" and used as the default when extra.assetTransferMethod is absent.
• Permit2 — the universal fallback for ERC-20s without EIP-3009, via a one-time Permit2 approval plus an x402 proxy contract.
• ERC-7710 — for smart accounts with delegation support; the only method the spec marks as "one-time use and multi-use".

We covered the EIP-3009 primitive itself in gasless stablecoin settlement, and the per-chain binding documents in fifteen chains, one scheme. The practical filter is the file typescript/packages/mechanisms/evm/src/shared/defaultAssets.ts. It is the map that lets a seller write price: "$0.10" and have the SDK resolve which stablecoin that means. At HEAD it holds 22 eip155: entries — Base, Polygon, Arbitrum, Celo, Flare, XDC, Monad, MegaETH, Mezo, Radius, Igra, HPP, ADI, Stable, and their testnets.

Each entry carries the EIP-712 domain the client must reproduce to sign, and a flag when the token cannot do EIP-3009:

// MegaETH mainnet MegaUSD (no EIP-3009, supports EIP-2612)
"eip155:4326": {
  address: "0xFAfDdbb3FC7688494971a79cc65DCa3EF82079E7",
  name: "MegaUSD",
  version: "1",
  decimals: 18,
  assetTransferMethod: "permit2",
  supportsEip2612: true,
},

Six of the 22 entries carry assetTransferMethod: "permit2". That is the shape of the problem: a third of the registry is already made of chains whose dollar does not implement the recommended path. The fallback is not free — it needs the canonical Permit2 at 0x000000000022D473030F116dDEE9F6B43aC78BA3 plus the x402 proxy at 0x402085c248EeA27D92E8b30b2C58ed07f9E20001, a vanity address made deterministic through Arachnid's deployer 0x4e59b44847b379578588920cA78FbF26c0B4956C. Two contracts that someone has to have deployed on your chain before the first request settles.

Tempo (chain ID 4217), Kite (2366) and Arc testnet (5042002) are not in that file. Not one of them.

Tempo: fast, cheap, and without transferWithAuthorization

Tempo is the most opinionated of the three about payments as a workload. Its connection details give chain ID 4217 for mainnet and 42431 for the Moderato testnet. The performance page promises "guaranteed settlement in half a second", a dedicated payment lane with "reserved blockspace with a separate consensus gas limit", and a fee claim that is unusually specific: "Fees are fixed, not congestion-priced: a TIP-20 transfer stays under $0.001 regardless of network load."

There is no native gas token. Fees are paid in TIP-20 stablecoins and a Fee AMM converts them to whatever the validator wants to hold. For an agent operator this is the single most useful property on the market: the cost of a transfer is quotable in advance, in dollars, without a gas oracle.

Then you read the TIP-20 spec. The function surface is ERC-20 plus four memo variants (transferWithMemo, transferFromWithMemo, mintWithMemo, burnWithMemo, each carrying a 32-byte reference field), a roles module, transfer-policy hooks, system-only fee functions, and EIP-2612 permit with nonces and DOMAIN_SEPARATOR.

What is not there: transferWithAuthorization. TIP-20 has no EIP-3009.

This is not an oversight. Stripe built a different protocol instead. We audited it in the Machine Payments Protocol: 23 documents, roughly 125,000 words, CC0. Re-reading the specs repo at HEAD f9506cd (7 August 2026), x402 appears exactly where you would expect a competitor to appear — as prior art in the payment-discovery draft, and as a sibling entry alongside tempo and stripe in the methods registry described in STYLE.md. Tempo treats x402 as one method among several, not as the interface it must satisfy.

The other thing worth stating plainly: Tempo's validators are permissioned and whitelisted, and there is no native token. For a payments chain that is a feature, not a flaw — but it means the trust assumption is corporate, not economic.

Kite: the passport is the product

Kite launched its chain and its Agent Passport together on 30 April 2026, with $35 million led by PayPal Ventures and General Catalyst, 90-plus integrated service providers, and stated support for x402, AP2, MPP and MCP. Mainnet is chain ID 2366 with regional RPCs in Virginia, Tokyo and Ireland; testnet is 2368.

The chain is the least interesting part. The identity model is the argument. Kite's whitepaper defines three layers: a user root identity held in a secure enclave and never exposed to the agent; an agent identity whose address is deterministically derived from the user's wallet via BIP-32; and a session identity made of random single-use keys. Identifiers look like did:kite:alice.eth/chatgpt/portfolio-manager-v1 — the delegation chain is legible in the identifier itself.

Sessions are where the money limits live. The docs describe a session as a bundle of total budget, per-transaction limit, duration and permitted destinations, approved once with a passkey. One signature per session, not per transaction. If that sounds familiar it is because it is the same primitive we mapped in account abstraction for agent wallets — session keys, spend permissions, caveat enforcers — with the difference that Kite makes it the chain's headline feature rather than a wallet extension.

Now the audit finding. Kite says it supports x402. Its service provider guide shows what that means concretely, and it is not the v2 spec:

// 402 response, per Kite's service provider guide
{
  accepts: [{
    scheme: "gokite-aa",
    network: "kite-testnet",
    maxAmountRequired: "...",
    payTo: "0x...",
    asset: "0x0fF5393387ad2f9f691FD6Fd28e07E3969e27e63",
    maxTimeoutSeconds: 60
  }]
}

// client retries with a base64 authorization in X-Payment

Three divergences at once. The scheme is gokite-aa, not exact — a custom account-abstraction scheme that is not in the x402 schemes directory. The network is kite-testnet, a bare string rather than the CAIP-2 identifier (eip155:2368) that x402 v2 requires. And the payload travels in X-Payment, the v1 header, rather than v2's PAYMENT-SIGNATURE. Settlement runs through the Pieverse facilitator at https://facilitator.pieverse.io, version 2.0.0, exposing /v2/verify and /v2/settle — the facilitator shape we documented in verify, settle, supported — and the facilitator does call transferWithAuthorization on the token, so EIP-3009 is present at the asset layer even though the envelope is a dialect.

Kite's x402 is x402-flavoured, not x402-conformant. A buyer built against the reference SDK will not pay a Kite endpoint without a custom scheme registration. That is a real integration cost, and it is invisible from the marketing page.

Arc: the dollar is the gas, and the token is a precompile

Arc is the one that has not launched yet. Circle confirmed 16 September 2026 for public mainnet, with founding validators including BlackRock, DTCC, Galaxy, Global Payments, ICE, Mastercard, MoneyGram, SBI Group, Standard Chartered, Sumitomo Corporation and Visa, and more than 100 builders on private mainnet.

The technical profile from Arc's own docs: chain ID 5042002 on testnet, Malachite BFT consensus, roughly 0.48-second testnet block time, deterministic sub-second finality, a Reth-based execution layer at the Osaka EVM fork, opt-in confidentiality through the Arc Privacy Sector, post-quantum SLH-DSA-SHA2-128s wallet signatures, and EURC and USYC as native assets alongside USDC. Gas is USDC, with a base fee updated through a bounded exponentially weighted moving average of block utilisation rather than block-by-block — fee smoothing as a product decision.

The part that will break integrations is smaller and sharper. On Arc, USDC is the native coin and an ERC-20, through a precompile at 0x3600000000000000000000000000000000000000 that forwards calls like balanceOf to the native balance. Circle's own writeup states the trap directly: the native interface uses 18 decimals, the ERC-20 interface uses 6, and 1e18 native equals 1e6 ERC-20.

For x402 the good news is in the contract address reference: canonical Permit2 is already deployed on Arc testnet at 0x000000000022D473030F116dDEE9F6B43aC78BA3, alongside Multicall3 and Circle's GatewayWallet at 0x0077777d7EBA4688BDeF3E311b846F25870A19B9 — the same Gateway contract family behind the batched nanopayment flow we took apart in nanopayments and batched x402. The Permit2 fallback is therefore available on day one. What Arc's documentation does not state is whether the USDC precompile implements transferWithAuthorization. Until that is confirmed on mainnet, the recommended EIP-3009 path on the most USDC-native chain in existence is an open question.

The comparison that actually matters

Strip away the throughput numbers and three questions decide whether a chain can carry x402 traffic tomorrow.

Can the buyer sign a payment instead of sending one? Tempo: no, not through TIP-20's native surface — EIP-2612 plus Permit2 only. Kite: yes, its facilitator calls transferWithAuthorization, but through a non-standard envelope. Arc: unconfirmed for the precompile, with Permit2 deployed as a fallback.

Is the network identifier something an x402 client can parse? Tempo and Arc are plain eip155: chains, so yes. Kite ships kite-testnet, so no — not without mapping.

Who deploys the missing pieces? On every chain without EIP-3009, someone must deploy the x402 Permit2 proxy and someone must add three identical registry entries across the TypeScript, Go and Python SDKs, as DEFAULT_ASSETS.md spells out. That is unglamorous integration work, and its absence is precisely why none of these three chains is in the registry today.

The pattern underneath is worth naming. The chains optimised for the wire — finality, fee predictability, blockspace reservation — because that is what a payments company measures. x402 optimised for the signature — what a buyer can authorise without holding gas. Those are different axes, and being excellent on the first buys nothing on the second.

What it means for LLM4Agents

LLM4Agents settles agent inference against stablecoins over an OpenAI-compatible gateway. The chain is an implementation detail of the settle step — right up until it is not.

The first consequence is that chain support is a token question, and our answer should be written that way. Adding a network is not "does Tempo work" but "does the dollar we would accept on Tempo expose transferWithAuthorization, and if not, is the Permit2 proxy deployed and who pays for the buyer's one-time approval". On an EIP-3009 chain a new buyer's first paid request costs them one signature. On a Permit2 chain it costs a signature plus an approval, and if the token has no EIP-2612, that approval costs gas the agent may not hold. That difference belongs in our pricing and onboarding docs, not in a footnote.

The second is that Kite is a threat and an opportunity in the same object. The Agent Passport competes with part of what a gateway does: it holds the funds, enforces the budget, and issues the receipts. But it also solves the delegation problem — user root, agent identity, session key, on-chain receipt linking all three — better than an API key ever will. A gateway that accepts a Kite-authorised session as an identity, while remaining the place the model call is priced and routed, gains more than it loses. The engineering cost is bounded and known: register the gokite-aa scheme, map kite-testnet to eip155:2368, accept the X-Payment header.

The third is Arc's date. September 16 puts a chain with Visa and Mastercard as validators, USDC as gas, and sub-second finality into production six weeks from now. If our facilitator path is ready when it opens, we are settling agent traffic on the most institutionally legible rail available. If it is not, we integrate it in November alongside everyone else. The dual-decimal precompile is the one landmine, and it is documented — there is no excuse for shipping a 10¹² error.

The fourth is defensive. Two of these three chains ship a payment protocol that is not x402 — MPP on Tempo, a custom scheme on Kite. Betting the settlement layer on a single protocol is now a real concentration risk. The scheme abstraction in x402 v2 exists exactly so a gateway can hold several of them behind one interface, and that is how we should hold them.

Staying on the frontier

Concrete, in order.

One. Publish a per-network capability matrix and keep it generated, not written: for each chain we accept, the asset address, the EIP-712 domain name and version, whether EIP-3009 is present, whether Permit2 and the x402 proxy are deployed, and the buyer's first-request cost in signatures and gas. This is a ten-line script against defaultAssets.ts plus three eth_calls per token. It becomes the honest answer to "which chains do you support".

Two. Build the Arc path before 16 September against testnet 5042002 today: price parsing pinned to the ERC-20 interface at 0x3600...0000 with decimals() read at startup, a probe that calls transferWithAuthorization on the precompile and records the answer, and the Permit2 route wired as fallback. If the EIP-3009 probe comes back positive, we ship the simplest possible integration on day one.

Three. Treat scheme registration as a first-class capability of the gateway, not a fork. Kite's gokite-aa is the first non-foundation scheme we have found in production; it will not be the last. A gateway that can register a scheme, a network alias and a facilitator endpoint through configuration absorbs the next dialect in an afternoon.

Four. Run the Tempo question deliberately rather than by default. If Tempo's sub-$0.001 fixed fee and half-second settlement matter to a workload we serve, the work is an MPP adapter, not an x402 tweak — and it should be scoped as its own protocol integration alongside the x402 one, in the same way we already hold Bearer and x402 side by side in the walk-up decision tree.

Five. Contribute upstream where it costs us nothing. If we do the token-capability work for a chain, the output is exactly what DEFAULT_ASSETS.md asks for — one CAIP-2 key, one address, one EIP-712 domain, one transfer method, replicated across three SDKs. Being the party that adds a chain to the reference implementation is cheap positioning, and it makes our own integration canonical.

The chains got fast. The dollars did not get uniform. For the next year, agent payment infrastructure is going to be won by whoever reads the token contract before believing the launch post.