Coinbase has built a store for AI agents. Great.
Agents need somewhere to find things they can buy: data, APIs, tools, whatever.
And Coinbase’s answer is the x402 Bazaar: a directory of services that agents can discover and pay for using x402.
There’s just one small problem.
It’s a dollar store.
Everything has a fixed price.
And if what you’re selling costs less than a penny, you’re going to have a hard time selling it.
Which is a little awkward because tiny, variable-priced transactions are exactly what x402 is supposed to make possible.
First, the good stuff
Let’s start with what Coinbase gets right.
An agent needs to find a service. It needs to know what the service does, what it costs, and how to pay for it.
That’s the Bazaar.
The basic model is sensible: a service gets discovered after it has successfully processed a payment, and Coinbase can use things like call volume, unique payers, recency and metadata to determine which services are active and useful.
In other words, Coinbase isn’t just building a list of URLs. It’s trying to build a marketplace, which is great, because the hard part of agent commerce isn’t really paying. It’s finding something worth paying for.
So far, so good.
Then things get interesting.
Problem #1: Everything has one price
Here’s a service I would like to sell:
Onchain data: $0.00002 per block
Ask for 10 blocks and you pay $0.0002.
Ask for 500 blocks and you pay $0.01.
Ask for 2,000 blocks and you pay $0.04.
That’s how a lot of machine commerce is going to work. The price isn’t really a price. It’s a formula.
And x402 actually has a mechanism for this.
It’s called upto.
The buyer says, essentially:
I’m willing to spend up to $X. Charge me for whatever I actually consume.
That’s a perfectly reasonable way to pay for metered resources: compute, bandwidth, tokens, blocks, data, etc.
But now try putting that on a shelf in the Bazaar.
What price do you write on the label?
$0.00002?
That’s not necessarily the price.
$0.04?
That’s a maximum, not the price.
$0.00?
Also not particularly helpful.
The problem is that the payment protocol understands a pricing function while the marketplace wants a price tag.
And those aren’t the same thing.
The current Bazaar model is much better suited to:
“This API costs $0.01.”
than:
“This API costs $0.00002 per block, but you might request 1,000 blocks, and we’ll charge you for what you actually use.”
That’s not a fatal flaw.
It’s just a very important limitation if we’re serious about machine-to-machine commerce.
Because machines don’t just buy products. They also buy units of consumption.
Problem #2: Nothing under a penny
This one is even more interesting.
Suppose my query costs $0.0004. That’s four-tenths of a cent.
Economically, that’s a perfectly reasonable price for a small piece of data. But if I need to put every $0.0004 payment into its own onchain transaction, I’ve made the transaction more expensive than the thing being purchased.
Luckily, x402 has a solution.
Batch settlement.
Instead of settling every tiny payment individually, you can accumulate payments and settle them together.
Exactly what you would expect.
It’s basically the difference between sending 1,000 letters individually and putting them all in one envelope.
The protocol is smart enough to understand this. But the marketplace doesn’t support this model.
If the individual payments don’t settle individually, they don’t necessarily look like individual marketplace events.
And that’s important because the Bazaar uses successful settlement activity as part of the machinery that makes services discoverable and keeps them alive.
So now we’re in a slightly ridiculous situation.
The payment protocol says:
Don’t put tiny payments onchain individually. That’s dumb.
The marketplace says:
Great. But I really like seeing individual payments.
And the seller is standing there thinking:
So which one do you want me to do?
The irony
This is the part I find most interesting.
x402 has solved the payment problem, but the ecosystem hasn’t quite solved the marketplace problem.
That’s a subtle distinction.
You can build a service that:
- calculates the exact price of every request;
- charges the agent only for what it actually consumed;
- batches microscopic payments;
- settles the aggregate onchain.
Economically, that’s exactly what you want.
But if the marketplace can’t understand that activity, you’ve got a service that works beautifully and is effectively invisible.
That’s not hypothetical either.
There are already reports of services successfully settling through CDP (Coinbase Developer Platform) without appearing in the Bazaar as expected.
Which means we’re starting to see the difference between:
“Did the payment work?”
and
“Did the marketplace understand that the payment happened?”
which are two very different questions.
This matters more than it sounds
It’s tempting to dismiss sub-cent payments as a cute crypto trick, but that’s wrong.
Agents are weird customers.
Humans don’t generally make 500 purchases in order to answer one question. Agents might.
Imagine an agent researching a company:
- It buys a company profile.
- Then financial data.
- Then five pieces of news.
- Then historical pricing.
- Then blockchain activity.
- Then some proprietary dataset.
- Then it does the same thing for 50 companies.
The individual purchases can be tiny. The aggregate bill can be meaningful.
That’s the entire point.
Machine commerce doesn’t need everything to cost a penny.
It needs things to cost whatever they’re worth.
Sometimes that’s a dollar.
Sometimes it’s a cent.
Sometimes it’s 0.2 cents.
And sometimes it’s 0.02 cents.
If your marketplace effectively starts at a penny, you’ve put a floor underneath the economy.
That’s a pretty strange thing to do when you’re building a system specifically intended to remove friction from machine-to-machine payments.
Here’s a very concrete example. The Graph charges $20 for 1M queries. That works out to $0.00002 per query. How can we compete if we charge our customers $0.01 per query?
And then there’s MCP
This gets even more interesting with MCP.
MCP is becoming the plumbing through which agents discover and use tools.
x402 is becoming the plumbing through which they pay for those tools.
That’s a pretty obvious marriage.
MCP tells me:
Here’s a tool that can do X.
x402 tells me:
Here’s how you pay for X.
But there’s still a surprisingly basic question:
How much does X cost?
There isn’t yet one universally adopted way of answering that across the MCP ecosystem.
People invent metadata fields:
price.pricing.- Something else.
And then clients have to figure out what they mean.
This is early infrastructure. That’s normal. But it matters. Because if we’re building a world in which agents autonomously shop for capabilities, price needs to be as machine-readable as the capability itself.
Not buried in a description. Not inferred from an example. Not hidden behind a URL. And certainly not reduced to a single number when the actual price is a formula.
This is how Testril is dealing with this
We’re building Testril to sell blockchain data to agents.
And our problem is exactly this one.
The natural unit we’re selling is a block, or a field. And those are cheap. Very cheap.
Way less than a penny.
So the obvious thing is to quote every request based on what the client (agent) actually asks for.
Then, when the price is below $0.01, batch the settlement.
That’s economically sane.
But it doesn’t fit neatly into the “one service = one price = one settlement” model.
We don’t think that model is where agent commerce is going.
The interesting market isn’t a collection of APIs with $0.01 price tags.
It’s a collection of resources with prices that can change depending on what the agent asks for and what the cost of the resources needed to produce the result.
That’s very different.
So what should Coinbase do?
I don’t think the answer is particularly complicated.
1. Stop thinking in terms of prices. Start thinking in terms of pricing.
A listing should be able to say:
$0.00002 per block.
Or:
$0.001 base + $0.00001 per 1,000 tokens.
Or:
Between $0.0001 and $0.02 depending on usage.
Or:
We’ll let you know once you’ve told us what you want.
The x402 payment machinery can already support this concept. The Bazaar needs to expose it.
2. Count the payments that actually happened
If an agent bought something 10,000 times and those payments were eventually bundled into one settlement, that’s still 10,000 purchases.
The marketplace shouldn’t care that the seller was smart enough not to put 10,000 transactions onchain. In fact, it should probably reward them for it.
Otherwise we’re creating the bizarre incentive to use an inefficient payment mechanism simply because it’s easier for the marketplace to see.
3. Make batch settlement a first-class citizen
If batching is the right answer for sub-cent payments, the discovery layer needs to understand it.
Not as some weird exception.
As a normal part of the economy.
4. Standardize pricing in MCP
An agent shouldn’t need to reverse-engineer somebody’s metadata to figure out what a tool costs.
Tell it:
- what the tool does,
- how it is priced,
- the minimum,
- the maximum,
- how the final price is calculated, and
- how it gets paid.
Then let the agent decide whether it’s worth buying.
That’s a marketplace.
The dollar store isn’t useless
To be clear, I’m not saying Coinbase’s Bazaar is a bad idea.
Quite the opposite.
It’s a necessary piece of infrastructure. Agents need a way to find shops.
But the current implementation feels like we’re still in the first phase of building the mall. Everything has a price tag. Everything is easy to understand. Everything fits neatly on a shelf. And nothing costs less than a penny.
That’s fine.
Until agents start buying things in quantities humans never would.
Then the economics change.
The price of one thing might be $0.0004.
The price of the next thing might be $0.017.
The third might be $0.000003.
The agent doesn’t care.
It just wants to know:
Is this worth what you’re charging me?
That’s the marketplace we need to build.
And the funny thing is, the x402 protocol is already pretty close to being able to do it.
Coinbase just needs to let the Bazaar catch up.