We Made Our Data Archive Buyable by an AI Agent (x402 on Base)

Update 2026-09-27. The endpoint has moved to x402 v2: the payment goes in a PAYMENT-SIGNATURE header, not the launch-era X-PAYMENT header that the four steps below show. The current instructions are in /llms.txt.

New x402 purchases can be paused, and the endpoint always says which state it is in. An unsigned GET https://zenhodl.net/buy/<product_id> answers HTTP 402 with the payment terms while new purchases are open. While they are paused it answers HTTP 503 with error x402_new_purchases_paused: no HTTP 402 payment challenge is issued, and a new payment signature is refused without being sent for settlement. The machine-readable status is agent_purchase.status in /.well-known/data-products.json. The archive is also sold through the normal checkout on its product page (card payment through Stripe): zenhodl.net/polymarket-historical-data. Existing paid buyers can retry the same GET https://zenhodl.net/buy/<product_id> with their original PAYMENT-SIGNATURE plus the X-ZenHodl-Download-Token from their first paid download (sent back as a request header of the same name) to download again; do not pay again. If that retry fails or the token was lost, email [email protected] with the transaction hash.

The rest of this post is the June 2026 launch write-up, kept as it was. Its "it's live" and "the door is open" statements hold only while new purchases are open.

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:

1. The agent requests the resource: GET https://zenhodl.net/buy/poly_orderbook_archive
2. It gets back HTTP 402 with machine-readable payment terms: $150 USDC on base, our receiving address, the USDC contract.
3. The agent signs an EIP-3009 transfer authorization (a gasless USDC payment) and re-sends the request with an X-PAYMENT header.
4. 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 200 with the archive and an X-PAYMENT-RESPONSE receipt.

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.

Update 2026-09-27: that request answers HTTP 402 with the payment terms while new x402 purchases are open, and HTTP 503 x402_new_purchases_paused while they are paused (see the note at the top). The archive is also sold through the card checkout on the product page.