The right flow is simple. Three steps:

1. Agent states what it wants
2. Platform provides a quote
3. Agent pays or moves on

That framing came out of a thread with Kevin (@kleffew94) — co-author of the x402 whitepaper, now building agent payments at Coinbase — on agents buying data on demand. Andrew (@andrewhong5297), co-founder of Herd and formerly Headmaster at Dune, pushed on the opposite failure mode: unknown costs up front.

If price isn’t agreed before a transaction, someone is likely to lose. For any ordinary purchase we expect terms before the deal. Restaurants don’t prepare meals hoping someone will buy them, and nobody orders food without knowing what it will cost. Agents should get the same courtesy.

If a price isn’t adjusted for an agentic transaction, it can be economically irrational. Most x402 offerings today fall into that category.

Most “agent-native” x402 deployments still fail that test in one of two ways:

• Work first, settle later: run the job, then figure out the bill.
• Wrong grain: the rail is right, but the cost is way off.

Work first, settle later

In that thread, Andrew clearly states the problem: for a SQL query you may not know the cost until it finishes, so do you make the agent put up an escrow and refund the surplus?

At first glance this appears rational. In fact, it’s a vendor shortcut disguised as payment UX.

A vendor should be able to figure out what a job will cost to run with relative accuracy. Not revealing a job’s price until after the job is complete puts the agent in a terrible position because it can’t say “no” before committing. At the outset, the escrow has to be considered the cost of the job. A refund is a bonus.

Dune provides a concrete example. Dune doesn’t use x402 — but it is the canonical version of the pattern that x402 offerings often copy. Its credit system bills from actual compute after the query runs. Processing, data scanned, and engine time are all taken into account. Dune’s own FAQ is blunt: “Will I see the cost before running a query? You’ll see costs after execution.” They don’t publish a single per-query price because usage depends on real-time factors. You can set a per-query credit cap and a monthly extra-credit limit, but those are ceilings on a bill you still get after the work.

Wrong grain

The unit of settlement is coarser than the unit of work.

Even when the quote is clear, the unit is often still wrong.

The Graph’s Studio (designed for humans) meters GraphQL queries: 100,000 free per month, then $2 per 100,000 queries, about $0.00002 per query.

The agent x402 path on the same network is still per GraphQL query. Official Graph docs describe the flow, not a price. They leave that to the ecosystem clients. PayQL’s live gateway preflight returns USDC 0.01 per paid gateway query.

Same data network. Same query grain. $0.01 per agent query vs. $0.00002 per Studio query — a 500x difference. Agents inherited human GraphQL metering and a cent-scale floor. The reason is almost certainly technical:

• Settling a transaction lower than $0.01 isn’t economically viable, even on chains with very low fees.
• Batching small transactions until settlement becomes economically viable is complicated. x402 supports it, but the needed escrow contracts aren’t available on most chains.

What Testril does instead

The fix is not a nicer checkout. It is a quote primitive.

Two problems to fix: price before work, and prices in line with actual work.

Quote first

Same three-step loop for every paid request:

1. Unpaid call returns soft payment_required on the success path: quote_id, line items, amount.
2. Agent calls pay_quote({ quote_id[, payload] }) if it accepts.
3. Same verb again with payment_id only.

quote_id freezes the work for 120s (an eternity for agents). After that, re-quote. You buy what was quoted. No Dune-style “cost after execution.”

Batch micropayments

Settling every agent hop on-chain at a cent is expensive. Settling below a cent needs batching.

Testril uses two settlement schemes on accepts:

• Exact: one EIP-3009 USDC transfer per quote (payload required) for work at or above the floor (currently $0.01).
• Batch-settlement: buyer deposits USDC into an x402 batch escrow, then signs vouchers for later quotes. Each later quote is a new voucher, not a new transfer. Testril accumulates vouchers until they reach an aggregate amount worth settling.

In future, the settlement floor may change, but the settlement mechanism won’t. It’s difficult to imagine a time when settling USDC 0.000001 becomes viable.

The real UX is the quote

x402 is not interesting because it lets software pay a web server. That part is plumbing.

The interesting part is what the payment flow teaches the agent before it commits.

For agents, price is not a checkout detail. It is part of the interface. A usable agent service needs to answer three questions before work begins: what will you do, what will it cost, and what exactly am I buying?

If the answer comes after execution, the agent cannot be a rational buyer. If the unit is wrong, the price is only technically correct. A one-cent floor on a query that should cost a thousandth of a cent is not micropayment infrastructure. It is human-era pricing dragged onto an agent rail.

The right abstraction is quote-first, settle-later. Give the agent a firm price, freeze the work long enough to accept, and batch the tiny units until settlement makes economic sense. The chain should clear value. It should not force every useful action to become a standalone financial event.

That is the UX standard x402 has to meet. Not “can an agent pay?” but “can an agent decide?” Agents need to compare, refuse, route around, and optimize. They need prices in the same place they need schemas, latency, and quality signals: before the call.

Payment rails matter. But agent-native commerce starts at the quote.

Here's the core problem: agents are being forced to download a mountain of data to derive answers the data source should have provided directly.

We did an experiment to show how serious this problem is.

The experiment

We used a Mycelium network (an experimental data layer that returns derived stats instead of raw rows) to run these tests.

Imagine an AI agent that needs one career baseball stat. Hank Aaron's career home runs or Nolan Ryan's ERA, WHIP, or strikeouts per nine.

In the traditional raw-data model the agent doesn't get the answer. It gets every season row required to compute the answer itself, dumped as JSON.

In the derivative model the agent asks for the finished number and receives one value.

We ran this on the full historic Lahman baseball database using Hank Aaron and Nolan Ryan. Token counts came from OpenAI's cl100k_base tokenizer on the actual JSON payloads an agent would see. The DIY side only received the minimum columns needed for each calculation. That is the generous case for raw data.

The results were not ambiguous.

The numbers

Same pattern for simple sums, fixed rate formulas, and LLM-derived stats. Ten pre-defined stats cost 6,074 tokens when fetched separately versus 213 tokens when the source returned the finished answers (96% savings). Eight derived stats cost 6,402 versus 182 (97% savings).

The bigger picture

• Separate fetches for all 18 example stats: 12,476 tokens and 439 season rows.
• One derived answer per stat: 395 tokens.
• Savings: 12,081 tokens (97%).

Even a smart client that reuses three shared pulls (Aaron batting + Ryan pitching + Aaron fielding) still burns 3,854 tokens. Mycelium stays at 395. That's still a 90% cut.

And remember, these numbers already give raw data the benefit of the doubt. Full database rows typically cost two to three times more.

Why this matters

Agents can compute batting average or OPS. But they shouldn't have to. When a thousand agents all want the same deterministic result, making every one of them re-download the same rows and redo the same math isn't flexibility. It's pure waste.

Think of it this way: if a robot asks for a screwdriver, handing it a mine, a smelter, and a steel mill is technically complete, but practically insane. Raw records are the ore. Derivative data is the screwdriver.

A serious data source shouldn't stop at exposing raw data. It should also return derivative data that agents request. These derivative results aren't approximations, they are exact, relative to the source records and the derivation logic. A well-designed system can optionally return the provenance so any client can audit the answer.

Traditional data interfaces were built for expensive human analysts. Agents are cheap and they arrive in volume. 97% fewer tokens is not a nice-to-have. It is the difference between a data source that scales and one that quietly bankrupts its clients.

Agents work differently. An agent asks a question, gets an answer, and acts on it. When you hand an agent raw blocks, logs, and traces, you push the pipeline's work into the agent itself. It has to load a large amount of data into context and reason across all of it to reach a single number.

The cost shows up twice

Raw data costs an agent twice. It pays once to read the data into context, and again to reason over that context to produce a result. A question like "how did USDC transfer volume change over the past year" can pull millions of events into the model to return one figure. The answer is slow and expensive, and you cannot reliably reproduce it. Ask the same question twice and you can get two different numbers.

Ask for the answer instead

Testril takes a different approach. You ask a question in plain language over CLI or MCP, and you get the answer back. If we have computed it before, we serve it from cache. If we have not, we compute it on demand. The agent never holds the raw data in context.

This keeps the token cost per answer low, and a single question can span many chains instead of stopping at one. Because every value traces back to the blocks it came from, the agent can also confirm the answer is right before it acts on it.

Raw data is the input to a pipeline. An agent wants the output of one.

That kind of trust does not scale to systems that run on their own. So we made provenance part of every answer instead of a feature you request separately.

What provenance means here

For any value Testril returns, you can ask where it came from. We report the source events, the block range, the transformation we applied, and the latest block the answer reflects. The number and the record of how we produced it stay together.

Why computing on demand helps

Testril computes answers from indexed source data rather than serving tables built in advance. Because we run the computation when you ask, the full path from source block to final value is always available, and we can replay it. Nothing sits between the chain and the result that we cannot account for.

This has a useful side effect. Two agents that ask the same question get the same answer, and both can trace it back to the same blocks.

Verifiable by construction

Self-describing JSON tells an agent the shape of a result. A provenance request tells it where the result came from. Together they let an agent confirm an answer before acting on it. That is the point of giving agents data they can reason about rather than data they have to take on faith.

So Testril quotes the request first.

The quote comes before the work

When you ask Testril for something, it prices the request up front. You see what the data will cost and what it takes to produce before any block is read. Nothing runs until you accept the quote.

For a system that spends its own money, this matters. The agent can weigh the cost against the value of the answer, decide, and only then commit. There are no runaway jobs and no charges for work it did not want.

Paying over the right rail

When the agent accepts, it pays over rails built for software, x402 and MPP, and the data comes back as self-describing JSON. Every step of the exchange is readable by a machine. The agent asks, sees a price, pays, receives the data, and can verify it.

Quoting before computing makes the cost predictable, and it makes per-query data safe to hand to an agent that pays for its own requests.

That only works if the payment rail is built for software.

x402

x402 takes an old idea and makes it usable. The HTTP status "402 Payment Required" becomes a real flow. A request arrives, the server responds with a price, the client pays, and the request completes. There are no accounts to set up and no invoices to reconcile. The payment happens inside the same request and response the client was already making.

For an agent, this fits well. It can learn the price, decide, and pay in one exchange.

MPP

MPP covers the wider path for machine-to-machine payment. It defines how a client settles an agreed amount for a specific piece of work. Combined with an up-front quote, it turns a data request into a clean transaction with an agreed price and a settled payment.

Why per-request pricing fits agents

A subscription cannot say that one specific answer is worth one specific amount. Per-request pricing can. The agent asks, receives a quote, and pays for exactly what it uses. Testril supports x402 and MPP so that exchange works without extra steps, which is why we price every request before it runs.