“Very soon there are going to be more AI agents than humans making transactions. They can’t open a bank account, but they can own a crypto wallet.” — Brian Armstrong, March 2026
By then, 140 million agent payment transactions had already been completed onchain, at an average of $0.31 each. That is a volume legacy rails cannot process profitably. The minimum viable credit card transaction runs around $1.00 after fees.
The economics are forcing a migration. Gartner projects $15 trillion in AI-intermediated B2B spending by 2028. Bloomberg estimates $56 trillion in stablecoin payment flows by 2030. Binance founder Changpeng Zhao has predicted that AI agents will make “one million times more payments than humans, using crypto.” Sam Altman describes a future where “companies will purchase units of intelligence the same way households buy electricity or water.” That future needs a payment rail built for machine-scale commerce. One has emerged.
x402 is the Standard, and has Already Shipped
On April 2, 2026, the x402 Foundation launched under Linux Foundation governance. Its founding coalition spans legacy finance and the decentralized economy: Google, Visa, Mastercard, Stripe, Cloudflare, Anthropic, AWS, Microsoft, Circle, Solana Foundation, Shopify, and more.
The protocol revives the HTTP 402 “Payment Required” status code, defined in 1997 and left unused for over thirty years. A client requests a paid resource. The server responds with 402 and payment terms. The client signs a token transaction and retries. The server verifies, settles, and serves. One round-trip. No API keys, no subscriptions, no accounts.
Over 100 million payments have been processed since launch. Cloudflare serves over a billion HTTP 402 responses daily. Stripe added x402 integration for USDC agent payments on Base. CoinGecko serves market data at $0.01 per request.
Every Payment Is a Public Broadcast
In its current form, x402 settles via standard ERC-20 transfers. Every transaction is publicly visible onchain: asset, amount, sender, receiver, timestamp. Anyone with a block explorer can see it all.
For an API provider, that creates a business intelligence problem that would be unacceptable in any other context. A competitor watching the chain can learn exactly how much each of your customers pays per call, whether you charge different customers different rates, how usage trends over time, which new clients are ramping up, and what your daily revenue looks like broken down by account.
This isn’t theoretical; onchain analytics is a mature industry, and the tooling to build these profiles is already sold as a product. Pricing, volume commitments, customer relationships: information B2B companies have always treated as confidential becomes a public record the moment a relationship moves to x402.
This isn’t a Crypto Edge Case, B2B Pricing is Confidential by Default
The business world has always treated pricing as sensitive information, not out of paranoia but strategy. 40% of B2B SaaS companies above $10M ARR don’t publish pricing at all. 85% use usage-based or hybrid models with individually negotiated rates. Bloomberg’s Data License has never published a rate card.
In 2025, 72% of B2B SaaS companies changed pricing or packaging, and teams with real-time competitor pricing alerts achieved a 26% higher win rate than those doing quarterly manual audits. Pricing is intelligence. Exposing it means conceding advantage.
Consider what happens when these relationships move to x402. The negotiated rate a data provider charges an enterprise client, the rate that took months to finalize, becomes a public onchain record. Any competitor can benchmark against it. Any client can prove they’re paying more than another client for the same API. For any provider doing volume-based, tiered, or negotiated pricing, that is a dealbreaker.
Others See the Gap, but the Tradeoffs Are Hard
Privacy for x402 is a recognized problem. Vitalik Buterin has called privacy “one of the largest remaining challenges in the Ethereum ecosystem.” a16z lists it as one of four trends reshaping DeFi in 2026. Several teams are working on it, each with different tradeoff decisions.
Some approaches use heavyweight ZK backends that achieve strong privacy at steep cost. Onchain proof verification can run ~2.4 million gas, exceeding the $0.31 average agent payment just for the privacy layer. Proof generation takes seconds, not milliseconds, disqualifying for real-time micropayments.
Others propose payment channel models: pre-funded channels with off-chain receipts and batch settlement. This solves a different problem (“allocate $100 across 10 agents, settle later”), not per-request HTTP payments.
FHE-based approaches offer strong theoretical privacy but remain computationally expensive. Whether FHE can meet the latency and gas constraints of production x402 is still an open question.
The core constraint is narrow: a privacy layer for x402 must fit inside an HTTP request-response cycle. The client must receive content with sub-second latency, without waiting for onchain finality. ERC-20 settlement on existing chains. Composability with standard x402 middleware.
How Merces Solves This
Merces is our confidential token transfer system. We integrated it into x402 as a new confidential payment scheme, a drop-in alongside the existing “exact” scheme. Same HTTP 402 flow, same facilitator architecture, new cryptographic layer underneath.
Phase 1: Discovery. The client requests a protected resource. The server responds with 402 advertising scheme: "confidential" plus the MPC network’s public keys.
Phase 2: Payment Construction. The client generates a Groth16 zero-knowledge proof (~400ms). The proof simultaneously demonstrates that a Poseidon2 commitment correctly encodes the payment amount, that additive 3-of-3 secret shares sum correctly, that each share is encrypted to the corresponding MPC operator’s BabyJubJub key, and that the amount fits within 80 bits. The client signs an EIP-712 payload binding the payment to sender, receiver, and nonce.
Phase 3: Verification. The facilitator verifies the ZK proof off-chain via ark-groth16 library in Rust (~3ms) and simulates the onchain verification of the payload, including nonce checking, amount-commitment validation against the actual claimed amount, and a few other key verification steps, to have confidence in the client’s payload before posting onchain and saving potential loss in resources.
Phase 4: Settlement. The facilitator calls transferFrom() on the PrivateBalance contract. The contract verifies the Groth16 proof on-chain (~300K gas) and enqueues the transfer. The MPC network decrypts shares, updates balance commitments, and generates its own proof of validity.
Phase 5: Content delivery. Content delivery can be configurable by the resource server. The resource server can choose to wait for full settlement from the MPC network to release contents, or to act more optimistically and deliver contents once the transferFrom() call has successfully completed. The optimistic scenario reduces the overall round trip time by a multiple of about 3 or 4 times compared to the full settlement option. Upon successful verification, regardless of which option is chosen, the resource server returns 200 OK with the requested content.
The payment amount never appears onchain. Only cryptographic commitments are stored.
What Changes, and What Doesn’t
| What | Standard x402 | Confidential x402 (in Merces) |
|---|---|---|
| Transfer amounts | Plaintext onchain | Poseidon2 commitment onchain. Real amount secret-shared with MPC |
| Account balances | Public via balanceOf() | Commitment only. Actual balances known only to MPC network |
| Spending patterns | Full payment history enables behavior profiling | Only who interacted with whom. Amount-based profiling blocked |
| Price discrimination | Onchain proof of what each user paid | No onchain evidence, can’t prove different users paid different prices |
What’s Protected Today, and What’s Next
The current integration hides transaction amounts and account balances. Sender and receiver addresses remain visible onchain, along with payment frequency and timing. An observer can still see that Agent A paid Server B fourteen times on Tuesday. They cannot see how much.
That is the right tradeoff to ship first: it solves the commercial privacy problem (hidden pricing, protected usage patterns, no onchain evidence of price discrimination) without adding the complexity of a fully encrypted transaction graph. The next step, fully private transactions with encrypted sender, receiver, and amount, is already working in our broader Merces stack. Extending it to x402 is a matter of engineering, not research.
Try Now
The confidential x402 demo is live on Base Sepolia. Clone the repo, generate wallets, and watch an agent make ZK-proven private payments in real time.
Merces integrates as a standard x402 scheme via @x402/evm. Adding confidential payments is a scheme registration, the same way you register “exact.” It is also compatible with AgentKit, so proof-of-human and confidential payment ride the same HTTP round-trip.
If you are building on x402 and want confidentiality in your stack, get in touch about a Merces design partnership.
In our next post, we go deeper: the full protocol walkthrough, ZK circuit architecture, privacy analysis, and a head-to-head comparison of every approach to x402 privacy we have found.
