The Missing Key to x402
x402 is the right base layer for machine-native payments. It’s here, and as of 04/02, it’s part of the Linux Foundation.
But it ships without the one thing every production system needs: a key and session story. That’s the layer to build.
What is x402?
x402 is an open protocol that builds on top of a more than twenty year old IETF standard: HTTP’s 402 Payment Required status code.
x402 is good because it is boring in the right way. It is simple, neutral, and very easy to explain.
The whitepaper’s pitch is straightforward:
Enable machine-native processes (e.g. AI agents, Web Services, etc.) to autonomously pay for API access, data, and digital services by leveraging the HTTP 402 ”Payment Required” and internet-native payment rails (e.g. stablecoins, blockchains, etc.).
Having spent years deep in the crypto industry, one of the most important lessons I learnt is that simple protocols get adopted, while overdesigned protocols get discussed. That is the tradeoff. In my opinion, it’s why Bitcoin took off. It remains one of the most approachable whitepapers I’ve ever read. Just re-read it a handful of times and you’ll understand it.
How does x402 work?
The full x402 story is very easy to explain:
- A client asks for a resource; such as a PDF.
- The server replies
402 Payment Required; including a price and a destination address for payment. - The client pays; along with the crypto digital equivalent of a signed check.
- The server returns the resource; after validating and setting the check.
That is the perfect base layer. It can’t be any simpler.
However, in the same way that the OSI Model needed a mature and ever-evolving Application Layer on top of the Transport Layer, x402 will need a mature and ever-evolving Key Management Layer on top of the Payment Layer.
The last page of the x402 whitepaper touts the following benefits:
- Instant, low-cost transactions.
- No API keys, no subscriptions, no middlemen.
- AI-first, developer-friendly, and blockchain-agnostic.
So what is x402 Missing?
Something I’ve learnt in the world of software development is that rewrites almost never work. You have to meet the world where it is, integrate with existing systems, and incrementally build towards the future you want to see. That is the only way to get from “this works on paper” to “this works in production.”
It’s been decades, and we still haven’t reached 50% IPv6 adoption as of writing this post.
If you want this to work in real systems, you need to account for how existing systems work, including things like:
- Scoped access keys
- Sessions keys
- Rotation and revocation of keys
- Admin key management
Then, the moment you enter the world of crypto, you learn that “custody hot keys” is a setup for a nightmare. You start to learn about multi-sig, hardware wallets, ring signatures, and we haven’t even gotten started with smart contracts.
What does it look like?
The missing key to the puzzle is not a change to the protocol, but building infrastructure on top of it that makes it usable with where the world is today, not where it’s going to be.
In fact, I really want the protocol to stay small and simple. It enables the ecosystem to introduce small, composable, layered primitives.
What’s the takeaway? In addition to enabling permissionless purchase of resources on the internet, enabling permissionless purchase of API keys is the next logical step. It is the missing piece that turns a one-off payment into an ongoing relationship with an existing service.
It doesn’t feel as “pure”, but it works. Keys are not a cop-out. They are the mechanism that turns a payment event into an ongoing service relationship.
This enables lots of different paradigms:
- Authenticate: Establish identity once per session instead of re-signing a payment on every call.
- Authorize: Scope each key to the minimum access it needs.
- Rotate/Revoke: Kill compromised keys in seconds without touching the protocol.
- Delegate: Hand scoped, short-lived keys to sub-agents without exposing the root wallet.
- Meter & Throttle: Attribute usage, enforce quotas, and flag abuse using existing observability and rate-limiting stacks.
- Integrate: Plug payments and top-ups into existing balance and billing systems.
Buying keys with x402 doesn’t have to be limited to API Keys. This could extend to session keys, license keys, support JWTs, or even just a more traditional pay-per-use model. The point is that the key management layer is what turns the protocol from a one-off payment into an ongoing relationship with a service.
Those are the boring parts that make a system shippable. And boring is good here.
How are others solving it?
First, what is the core problem of using off-the-shelf x402 for real systems? Hyperscale.
When you’re servicing millions of requests per second, you can’t go through a signature ceremony with every request. There’s a long list of problems to solve including, but not limited to, rate limiting requests, verifying payments, preventing abuse, protecting against denial-of-service, etc.
Two of the biggest efforts in the space targeting this problem are:
Circle has a very simple solution built on top of x402: batch thousands of nano transactions into one x402 transaction. It’s not a new protocol, it’s a Gateway based approach to solving this problem.
Stripe has a more ambitious solution, also built on top of x402: MPP. It gets real things right, most notably sessions: “A streaming payment over a payment channel. Use for pay-as-you-go or per-token billing with sub-cent costs and sub-millisecond latency.” Payment channels for machine-to-machine billing are a genuinely useful primitive.
The question isn’t whether those primitives are needed. They are. It’s whether they belong in a protocol, or in an SDK on top of one.
MPP bundles them with a new protocol, first-class support for its own blockchain, and its card network:
In the same way Cloudflare shipped Pay Per Crawl as a product and not a protocol, a lot of MPP could live as an SDK on top of x402. That’s the unbundling I’d want to see.
x402 feels pure and neutral, like Bitcoin, Ethereum, or Zcash. MPP solves real problems, but bundles them in a way that blurs the line between an open protocol and a product offering.
If you’ve been in crypto long enough, you’ve seen this pattern: a vendor ships an SDK that quietly becomes the de facto protocol, and composability pays the price.
Where do we go from here?
We find a delicate balance between building, waiting, and seeing what is a real problem that needs solving.
Stablecoins are here to stay. Agents will become more prevalent on the internet. The real work is distinguishing signal from noise about where the market actually is today. Big players can afford to fund speculative bets long past the point a thesis pays off, the way Meta has with the Metaverse. Smaller companies have to follow the customer that comes back.
At Grove, we shipped a wallet-first Linktree that is ready on the API and skills front for when the agents arrive. When we started, our thesis was that agents will pay humans. In reality, if you dive deep into x402scan.com or agentic.market, you’ll find a lot of tinkering, but not a market yet. If we had visibility into the numbers behind projects.dev, I’m sure we’d find the same thing.
To summarize, I’m extremely bullish on everything above. x402 will proliferate. MPP will be a great product. Agents will be consuming resources on the internet. I simply want to call out that in order to move the needle, we need to introduce layers that integrate the old system with the new, because it’ll be a while. That is the missing key to x402.
The open question: does the key layer belong in x402 itself, in an SDK ecosystem around it, or in a product like MPP? I believe the middle path wins.
If you’re building on top of x402, I’d love to hear what you think. In addition, not instead.