Hacking dynamic pricing into X402

As a premium data layer for AI agents, Kirha’s mission is to connect AI agents to premium data from S-tier providers and let them pay however they want. So we just went live on Coinbase Bazaar where agents discover X402 vendors. Here’s how we did it.

X402 is the new payment protocol from Coinbase that accounts for nearly 20% of Base transaction volume today. It revives the HTTP 402 code to standardize how AI agents can pay using USDC to unlock a resource on a remote server without having to auth. Resource providers can add a decorator to an API route to accept USDC without dealing with blockchain complexity.

X402’s early traction really validates our vision of micropayments for AI agents:

• Subscriptions are a bad model for AI agents
• Blockchain is the transactional ledger for agents

X402 still has important limitations: it only supports USDC today (but agents might want to pay with their own token), gas fees can eat into or exceed small payments (paying 3 cents in gas for a 2-cent resource doesn’t make sense), and it doesn’t allow dynamic resource pricing.

Coinbase temporarily solves the gas fee problem by sponsoring all X402 transactions.

We had to hack a solution for dynamic pricing—because unlike any endpoint serving a static resource, Kirha’s /search price depends on the context required by the agent’s prompt. Fetching the current Bitcoin price is 2 cents, but asking for aggregated metrics like protocol P/S and P/F is 5 cents, and comparing multiple SEC filings can exceed 10 cents. We route your agent to the right context in real-time, which means we can’t know the price upfront.

Ongoing proposals like Cloudflare’s deferred payment scheme are about to unwrap 🥁 and happen to solve this along the way.

The early bird catches the bugs

X402 leverages the dormant HTTP 402 status code to create a native payment layer for the web. The flow is straightforward:

1. Client requests a resource
2. Server responds with 402 Payment Required and a paymentRequirements object describing what it accepts (chain, token, price, recipient address)
3. Client signs a payment payload and retries the request with an X-PAYMENT header
4. A facilitator server verifies and settles the payment on-chain
5. Client gets the resource

The beauty is in the abstraction: resource servers don’t touch wallets or RPCs, clients don’t think about gas. The facilitator handles all the blockchain plumbing. The protocol is token-agnostic by design, but facilitators choose which tokens to support and they start with USDC.

But here’s the limitation we hit. The spec assumes static pricing—you define paymentRequirements upfront, the client picks one, done. But Kirha’s /search endpoint doesn’t work that way. The price depends on what the agent asks for, and we don’t know that until we parse the prompt. We calculate the price on the fly, then return it as a paymentRequirements object.

The problem? When the client sends back a payment payload, it only specifies the scheme and network. There’s no field to link the payment back to the requirements we generated.

Let’s look at what the client actually sends:

{
  "x402Version": 1,
  "scheme": "exact",
  "network": "base",
  "payload": {
    "signature": "0x2d6a75...",
    "authorization": {
      "from": "0x857b06519E91e3A54538791bDbb0E22373e36b66",
      "to": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
      "value": "10000",
      "validAfter": "1740672089",
      "validBefore": "1740672154",
      "nonce": "0xf374661..."
    }
  }
}

No requirementId, no reference to which paymentRequirements the client is fulfilling. Just a signed authorization for a value.

I briefly considered cursed workarounds—obfuscating a payment ID inside the nonce, or encoding metadata in the price decimals. Terrible ideas. The nonce is for replay protection, not data smuggling. And hoping your facilitator doesn’t normalize your cleverly-crafted 10000.000042 into 10000 is not a production strategy.

We needed a cleaner solution.

Computer Science is no Science

Because a picture is worth a thousand words, here’s our workaround architecture while X402 matures.

We store a unique hash of every request in Redis along with its associated price. Interestingly, even though X402 doesn’t require auth, we still route payments through our internal credits system. We use Kirha’s /top-up endpoint to add credits to a pre-registered admin X402 account. This is the same endpoint your agents can use to add credits to your Kirha accounts when needed. They can top up with any currency they like, as long as it’s configured to their account. The only requirement is that their token is listed on a DEX with sufficient liquidity.

Why this matters

While still in its infancy, X402 is a promising innovation that aligns with our vision of micropayments for AI agents. As often happens in crypto, it’s currently being hijacked to avoid fees on mints rather than to power real services.

Kirha delivers the model that X402 was meant to enable. Premium context, on demand, paid per use. The way agent infrastructure should work.