An autonomous AI agent can now buy our historical Polymarket & Kalshi orderbook archive without a human in the loop and without a checkout page. It hits one URL, gets told the price, pays USDC on Base, and receives the Parquet download — settled on-chain. No card, no account, no "click here to complete your purchase."
This is built on x402, Coinbase's revival of the long-dormant HTTP 402 Payment Required status code as a real agent-payment protocol. We wanted to see whether it actually works for a non-trivial digital good — a $150, 1.1 GB dataset — so we wired it up end to end and put it live.
How an agent buys it
The whole flow is four steps and one endpoint:
- The agent requests the resource:
GET https://zenhodl.net/buy/poly_orderbook_archive - It gets back HTTP 402 with machine-readable payment terms:
$150 USDConbase, our receiving address, the USDC contract. - The agent signs an EIP-3009 transfer authorization (a gasless USDC payment) and re-sends the request with an
X-PAYMENTheader. - Our server hands that to the Coinbase CDP facilitator, which verifies the signature and settles the transfer on Base. On success the agent gets
HTTP 200with the archive and anX-PAYMENT-RESPONSEreceipt.
The buyer pays no gas — the facilitator submits the on-chain transfer. There is no human, no redirect, no hosted checkout. An agent that can read a 402 and sign a payment can complete the purchase on its own.
We proved it on-chain
This isn't a mock. We ran a real settlement on Base (transaction): the buyer's USDC balance dropped, the seller's went up, the agent received the file — all from a single programmatic request. The same code path now serves the live archive.
It's also discoverable: the endpoint is documented in our /llms.txt, in our agent-skills index, and marked for Coinbase's x402 "Bazaar" discovery directory.
Why we did this
We're a data vendor. The thing we sell — score-synced, cross-venue prediction-market orderbook history that the venues never publish and that can't be backfilled after the fact — is a niche research input. (We compared every vendor that sells this kind of data, ourselves included, in an honest buyer's guide.) Its likeliest buyer is a quant or microstructure researcher, and increasingly that person works through an agent: "find me historical Polymarket/Kalshi orderbook data for a backtest." If that agent can discover our endpoint and pay without bouncing the human back to a Stripe page, we capture a sale we'd otherwise lose to friction.
So x402 isn't a gimmick for us — it's removing checkout friction for the exact buyer we have, in the workflow they're moving toward.
The honest part
Two things we won't oversell:
- The product is the data, not the payment rail. The archive is a fixed historical window, sold as-is, with known gaps documented in the schema. x402 makes it easier to buy; it doesn't change what it is. (Prefer a card? It's also on the products page.)
- A payment rail doesn't manufacture demand. Making something agent-buyable is necessary but not sufficient. A bot won't buy this because it's a bot — it'll buy because a human who needed this specific data pointed an agent at it and we made the transaction frictionless. Whether that happens at volume is an open question, and we'd rather state it plainly than pretend the rail is the product.
What we can say is this: the capability is real, it's live, it's proven on-chain, and we're one of very few data vendors you can actually transact with this way today. If you're building agents that acquire data — or you just want the archive — the door is open: GET https://zenhodl.net/buy/poly_orderbook_archive.