Eleven months ago, x402 was a spec and a handful of TypeScript packages on Coinbase’s GitHub. Today, it sits under the Linux Foundation with Google, Microsoft, AWS, Visa, Mastercard, Stripe, and Shopify as founding members. It has processed over 250 million transactions across seven chains. That trajectory alone tells you something important: the protocol has crossed the line from experiment to infrastructure.
We saw this coming. That is why Vitwit built x402-go, the first open source Go library for multi-chain x402 payment verification and settlement, and why we are inviting every protocol team to use it.
This post covers why x402 matters, where it is headed, and what we have shipped to make it accessible to the broader ecosystem.
What x402 Actually Does
If you have been building anything that touches APIs, data feeds, or compute services on-chain, you have probably run into the same wall: how do you charge for access in a way that is native to the web, works across chains, and does not require users to go through a checkout flow designed for humans?
x402 solves this at the HTTP layer. When a client hits a protected endpoint, the server responds with a 402 status code and a payment requirement. The client (usually an AI agent or automated service) signs a stablecoin payment, attaches it to the request header, and the server verifies and settles it before returning the response.
No redirect. No session. No payment gateway middleman. One round trip.
The protocol borrows the same mental model that made HTTP work for information exchange and applies it to value exchange. A server declares what it costs, a client pays, and the transaction settles on-chain. That simplicity is the whole point.
The Numbers That Got Our Attention
We started tracking x402 seriously in late 2025 when Cloudflare shipped native support in Workers and the AI Agents SDK.
Within weeks, Base was seeing 500,000 x402 transactions in a single week, a 10,000% month-over-month jump. By November, daily peaks were hitting 3 million transactions. By February 2026, a single day saw 3.8 million transactions and roughly $2 million in on-chain volume.
These are not speculative numbers on a testnet.
This is production traffic, mostly from AI agents paying for API access, data retrieval, and compute.
The macro picture is even more compelling. McKinsey projects $3 to $5 trillion in agentic commerce by 2030. Gartner expects 90% of B2B buying to be AI-agent intermediated by 2028. Stablecoin volume already crossed $33 trillion in 2025, and real-world payments still represent roughly 1% of that total. The headroom is massive.
When you put the protocol-level traction together with the macro opportunity, the conclusion is straightforward: x402 is not a niche tool for crypto-native developers. It is a foundational payment rail for the next generation of internet services.
Why Go, and Why Now
Most of the early x402 tooling was written in TypeScript. That made sense for the initial wave of builders working with Node.js servers, Next.js frontends, and Cloudflare Workers. But large parts of the blockchain infrastructure world run on Go. Cosmos SDK chains, Ethereum execution clients, validator infrastructure, indexers, relayers, and a huge chunk of backend services across DeFi are all Go codebases.
If you wanted to add x402 support to any of these systems, you had two options: wrap a TypeScript library in a subprocess, or write the verification and settlement logic from scratch. Neither is a good answer.
That is exactly why we built x402-go. It is a clean, minimal Go library that handles the core x402 workflow: verifying signed payment headers, settling transactions on-chain, and enforcing payment requirements via HTTP middleware. It ships with built-in support for EVM chains (Base, Ethereum, Polygon), Solana, and Cosmos chains (Cosmos Hub, Osmosis, Neutron, Celestia). And it is designed to be extended, so any team can plug in their own chain by implementing a simple provider interface.
The architecture is intentionally modular. Your application owns the HTTP server, the key management, and the lifecycle. x402-go provides the verification engine, the settlement logic, and the middleware. You wire it in and move on.
Here is what integration looks like in practice:
evmProvider, _ := evm.New(evm.Config{
Networks: []string{evm.NetworkBaseSepolia},
RPCEndpoints: map[string]string{evm.NetworkBaseSepolia: "https://sepolia.base.org"},
PrivateKeyHex: os.Getenv("FACILITATOR_KEY"),
})x := x402.New(x402.Config{Logger: slog.Default()})
x.RegisterNetworkProvider(evmProvider)http.Handle("/api/resource", x.Handler(x402.HandlerConfig{
Accepts: []x402.PaymentOption{{
Scheme: x402.SchemeExact,
Network: evm.NetworkBaseSepolia,
Amount: "1000000",
Asset: "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
PayTo: "0xYourAddress",
}},
SettleOnVerify: true,
}, myHandler))That is it. Your Go service now accepts stablecoin payments at the HTTP layer. No external payment service. No webhook integrations. No waiting for confirmations in a separate flow.
The Gap We Saw in Cosmos
We wrote about this in detail on the Cosmos Hub Forum back in February. The short version: every major chain ecosystem was racing to support x402. Base had it from day one. Solana ran a dedicated hackathon. Celo integrated it at the protocol level. Google’s A2A protocol adopted it. World (Sam Altman’s project) launched AgentKit with x402 and World ID baked in.
Cosmos had none of this. No native facilitators. No SDK support. No middleware. No analytics tooling. The x402 V1 spec relied heavily on Ethereum standards like EIP-3009 that Cosmos tokens do not implement. Cosmos stablecoins, whether USDC on Noble or IST on Agoric, were not plug-and-play for x402.
This was a problem because Cosmos positions itself as the Internet of Blockchains, and the fastest-growing payment protocol on the internet had zero Cosmos support. If you were a developer evaluating where to build an AI-agent-facing service, Cosmos was simply not in the conversation.
x402-go changes that. The library includes a Cosmos provider that handles bank module MsgSend transactions for payment verification and settlement. It supports Cosmos Hub, Osmosis, Neutron, and Celestia out of the box, with a registration mechanism for adding any Cosmos SDK chain at runtime.
This is the kind of infrastructure that needs to exist before the application layer can take off. You do not get AI agent services on Cosmos without payment rails. You do not get payment rails without libraries and tooling that speak the protocol.
What Comes Next
The x402 Foundation, moving under the Linux Foundation in April, was a turning point. This is now governed by the same organization that oversees Linux, Kubernetes, and Node.js. The membership list reads like a who’s who of global payments and cloud infrastructure. That level of institutional backing means the protocol is not going away, and the ecosystem around it is going to grow fast.
For Vitwit, x402-go is not a side project. It is the foundation for a broader stack of tools we are building around agentic payments. We see a world where every API, every data feed, every compute service can be monetized at the HTTP layer with a few lines of code. Getting there requires reliable infrastructure that protocol ecosystems tend to underinvest in.
We built x402-go because we needed it, and because we think every Go-based blockchain project will need it too. The library is MIT-licensed and fully open source. Fork it, extend it, build on it. If your chain or protocol wants to support x402, this is the fastest path.
The repo is at github.com/vitwit/x402-go. Issues, PRs, and feedback are welcome.
Vitwit is a blockchain infrastructure company that has been building in the Web3 ecosystem since 2019. We focus on validator infrastructure, developer tooling, and protocol-level contributions across multiple chains.
Why We Bet on x402 (And Built the Go Stack for It) was originally published in Vitwit on Medium, where people are continuing the conversation by highlighting and responding to this story.