The agent payment wars: x402, MPP, AP2, and where switchboard fits

April 2026 will be remembered as the month the agent payment wars went hot. In the span of four weeks: x402 joined the Linux Foundation, Tempo launched MPP on mainnet, Google released the Agent Payment Protocol (AP2), and Circle shipped nanopayments for USDC. Four different answers to the same question — how does an AI agent pay for things?

We have been tracking this space since early 2025. We mapped all four protocols in an interactive explorer at kcolbchain.com/switchboard/. And we found something interesting: they all solve the easy part. None of them solve the hard part.

The four contenders

x402 is the most elegant of the bunch. It extends HTTP with a new status code — 402 Payment Required, the code that has been "reserved for future use" since 1999. A server returns 402 with a payment envelope. The client signs a transaction, attaches the receipt as a header, and retries the request. Settlement happens on Base (or any EVM chain). It is beautifully simple: every HTTP server becomes a paywall, every HTTP client becomes a wallet. x402.org has the full spec.

MPP (Micropayment Protocol) takes a different approach. Built by Tempo on top of Stripe's infrastructure, MPP uses payment channels to batch micropayments off-chain and settle periodically. The key innovation is session-based billing: an agent opens a session, makes multiple requests, and the channel settles when the session closes or a threshold is reached. This makes sub-cent payments economically viable because you are not paying gas per transaction. The Tempo MPP docs cover the channel mechanics.

AP2 (Agent Payment Protocol 2) is Google's entry. It is the most ambitious in scope — AP2 does not just handle payments, it defines a full agent-to-agent negotiation flow. Price discovery, capability advertisement, SLA terms, and payment are all part of the same protocol. The downside is complexity: AP2 messages are verbose, the handshake has multiple round trips, and the spec assumes you are already inside the Google Cloud ecosystem for identity.

Circle nanopayments is the most pragmatic. It is not really a protocol — it is an API. You call Circle's endpoint with an amount and a destination, and USDC moves. The innovation is that Circle absorbs the gas cost and settles in batches, making payments as small as $0.001 economically viable. The tradeoff: you are trusting Circle as an intermediary. It is not peer-to-peer. It is not permissionless. But it works today, at scale, with one API call.

The comparison matrix

We built a side-by-side comparison at kcolbchain.com/switchboard/ that lets you evaluate each protocol across ten dimensions. Here is the summary:

• Minimum viable payment: x402 is limited by gas costs (roughly $0.01 on Base). MPP can go sub-cent via batching. Circle goes to $0.001. AP2 inherits whatever rail it settles on.
• Latency: Circle is fastest (one API call). x402 requires an on-chain transaction per request unless you layer state channels on top. MPP batches but still has channel open/close overhead. AP2's negotiation phase adds 2-4 round trips before the first payment.
• Decentralisation: x402 is fully on-chain and permissionless. MPP settles on-chain but Tempo operates the channel infrastructure. Circle is centralised. AP2 is decentralised in theory but Google-centric in practice.
• Developer experience: x402 wins here. Return a 402, parse the header, verify the receipt. Three steps. Circle is close — one SDK call. MPP requires session management. AP2 requires implementing a full negotiation state machine.
• Composability with DeFi: x402 receipts are on-chain transactions — they compose with anything. MPP settlements are standard transfers. Circle payments are on-chain after batching. AP2 is chain-agnostic, which sounds good until you realise it means "not natively integrated with any chain."

The gap none of them fill

Here is the punchline, and the reason we are building switchboard.

All four protocols answer the question: "How does payment move from agent A to service B?" None of them answer the question: "How does agent A manage its money?"

Think about what an autonomous agent actually needs to make payments:

• Key management. Where does the signing key live? How is it rotated? What happens when a key is compromised? x402 assumes the client has a key. It does not say where that key comes from or how it is secured.
• Nonce management. On-chain payments require sequential nonces. If an agent is making concurrent requests to multiple services, nonce collisions will cause reverts. None of the protocols address this.
• Gas budgeting. An agent needs to know: how much gas can I spend this hour? This day? This task? If gas spikes 10x, should I pause or proceed? None of the protocols define a budget model.
• Escrow and pre-commitment. When an agent agrees to a multi-step task, it needs to escrow funds so that step 3 does not fail because step 2 drained the wallet. This is wallet-level logic, not payment-rail logic.
• Audit trails. Every payment an agent makes needs to be attributable to a task, a user instruction, and a cost centre. This is not a blockchain problem — it is an indexing and reporting problem at the wallet layer.

This is what switchboard is. Not another payment protocol. A wallet runtime for agents. It sits between the agent's decision logic and whichever payment rail the destination requires. It manages keys via a secure enclave. It sequences nonces. It enforces budgets. It escrows funds for multi-step tasks. And it logs everything in a format that humans can audit.

The integration path

We are not competing with x402 or MPP or any of the others. We are the layer that makes them usable by autonomous agents.

We opened two issues last week:

• Issue #16 — x402 client middleware. Switchboard intercepts 402 responses, checks the agent's budget, signs the payment, attaches the receipt header, and retries. The agent code never touches a key.
• Issue #17 — MPP sessions adapter. Switchboard opens and manages payment channels on behalf of agents, handles session lifecycle, and settles channels when budget thresholds are reached.

AP2 and Circle adapters are on the roadmap. The architecture is pluggable — each payment rail is a driver that implements a common interface: authorize, execute, verify, refund.

The grand vision

The agent economy is coming whether we are ready or not. Within two years, most API calls will be made by agents, not humans. Those agents will need to pay for the services they consume — compute, data, inference, storage, bandwidth.

The payment rails are being built right now, by smart teams at Coinbase, Tempo, Google, and Circle. Good. That is necessary infrastructure.

But rails without a wallet runtime is like having roads without cars. You need something that sits in the driver's seat, manages the fuel budget, picks the fastest route, and keeps a log of every trip.

That is switchboard. An open-source wallet runtime for the agent economy. Explore the interactive protocol comparison and gap analysis at kcolbchain.com/switchboard/.