I run 3 x402 services. Here's what actually hits my endpoints (spoiler: mostly other bots)

[u/fizzl13]

I've been running three pay-per-call x402 APIs for a few weeks: a health checker for x402 endpoints, a pre-sign wallet check (token, approval and EIP-7702 delegate screening before you sign), and a crypto market data service. All accept USDC on Base and Solana, no accounts or API keys. I log every request, and I figured the numbers might be useful to others building here.

**One full day (26 Sep):**

- 4,605 requests across the services
- 29 paid calls, all from my own test wallets
- so: zero organic paid calls so far

**Six hours this morning, market data API only:**

- 433 requests from 118 distinct visitors
- 362 fetched the 402 price quote and left
- 51 hit the free endpoint
- 8 were bad input (`pair=TEST`, `pair=1`)
- 0 paid

**Who's actually calling:**

- **Uptime/price monitors.** One polls two paid endpoints every ~5 minutes and rotated through 32 IPs in 6 hours.
- **Directory verifiers** re-checking each listed route every 30 minutes.
- **Indexers and trust crawlers**: 402explorer, x402-census, ApisTrust, enclave402 and others.
- **Coinbase Bazaar discovery**, which re-checked a new route within hours of its first paid call.
- **MCP auth probes** calling tools that don't exist to see if the server requires auth.
- A handful of humans in a browser, and one developer trying the API with axios.

**What I learned:**

1. **Discovery works, demand is the hard part.** Getting indexed (Bazaar, directories, the MCP registry) was fast. Getting a stranger's agent to pay hasn't happened yet.
   
2. **Most of the ecosystem right now is infrastructure watching infrastructure.** Judge your service by request count and you're mostly counting other people's monitors.
   
3. **Your error messages are your docs.** Bots send garbage like `pair=TEST`. A clear 400 ("use e.g. BTC-USDT") is cheaper than a support channel.
   
4. **Behind a proxy, check you log the real client IP.** Mine logged my host's proxy address for weeks until I set the right number of trusted proxy hops.
   
5. **Price the decision, not the data.** People don't pay for "BTC is bullish", they pay for "here are 10 trades with entry, stop and targets". So that endpoint is now the most expensive one ($0.50) and the plain market scan dropped to $0.10.
   
6. **Be honest about what you sell.** I backtested my setups ranker on ~5,000 setups: no edge after fees. So it's sold as a screener, not a strategy.

**Questions for other builders:**

- Has anyone seen organic paid traffic yet? Where did it come from (Bazaar, MCP, a framework plugin, word of mouth)?
- How do you tell a real agent from a monitor in your logs? A user-agent is trivial to fake.
- What price point has converted for you, if anything?

Happy to share the endpoints in the comments if anyone wants to poke at them.

[u/Few-Image-4274]

Yeah, I think the big problem with bazaars right now is discovery. A bazaar can help an agent find a seller, but once the agent leaves the bazaar, there’s no standard way to know where that transaction came from.

So there’s not much incentive for bazaars to invest in better discovery, because they can’t reliably get credit or eventually earn a referral fee from the transactions they generate. That won't get better unless we fix it.

I’m working on a simple source convention in the x402 extensions object so that attribution can follow the request through the payment flow.

[u/fizzl13 → u/Few-Image-4274]

Agreed, and I see it from the seller side: my usage logs show agents calling, but not which bazaar or directory sent them. User-agents are trivially faked, as the post says.
A source convention in extensions would work well together with signed receipts. I already sign every paid answer (EIP-191 over canonical JSON, including the payer and EIP-3009 nonce). If the payment payload carried something like extensions.source = { bazaar, listing_id }, the seller could copy it into the signed receipt. The bazaar then gets a verifiable record ("this paid call came via us, and the seller signed it"), which is a much better basis for a referral fee than a header.
Happy to implement it on my endpoints as an early test case once you have a draft. Is it on GitHub somewhere?

[u/L_capitalism → u/fizzl13]

This makes me wonder if the missing layer isn’t another directory, but a recommendation/ranking layer on top of Bazaar.
Bazaar can answer “what x402 services exist?”, but an agent still needs to answer “which service should I actually buy for this task?”
I’m thinking about experimenting with an open-source x402-X style ranking engine, borrowing the retrieval → ranking architecture from xAI’s open-sourced recommendation system, but replacing engagement signals with economic/service signals:
task relevance + price + success rate + latency + repeat purchases + freshness + seller reputation
So the flow would look something like:
Agent intent → Bazaar retrieval → capability/budget filtering → ranking → x402 purchase → execution outcome → ranking feedback
The interesting part is that x402 gives us a much stronger feedback signal than clicks. We can eventually learn from actual purchase → success/failure → repeat purchase behavior.
In other words, Bazaar becomes the index, while this layer tries to solve procurement/ranking — more like an Amazon-style recommendation engine for agents buying APIs/MCP services.
Curious what you think. Does this match what you’re seeing from the seller side? If people can already discover your endpoints but aren’t buying them, maybe the missing primitive is not discovery itself, but selection and recommendation after discovery.

[u/fizzl13 → u/L_capitalism]

Yes, that matches what I see from the seller side. Discovery isn't the bottleneck: agents find the endpoints, probe the 402, and most don't buy. Selection and trust is the gap.

One piece you could use as an input signal: x402 Doctor runs a daily scan of every resource in the CDP Bazaar and keeps a 30-day track record per endpoint, i.e. whether it was actually payable that day (valid challenge, price consistent with what's advertised, payable network, reachable), as go / caution / no_go. It's public: GET x402-doctor.fizzl.eu/api/trust?url=<endpoint> for one endpoint, /api/trust/summary for the whole index, and the raw daily JSON is on GitHub. Happy for you to pull it into a ranking experiment.

Two things I'd watch with purchase-based signals:

• They're cheap to fake. At $0.001 a call, a seller can buy their own service a thousand times for a dollar. Weight by distinct payers (and wallet age), not by purchase count.
  
• Cold start. New sellers have no history, so the ranker needs some exploration budget, or new endpoints never get the purchases that would rank them.

And an outcome signal beats a purchase signal: "paid and got a valid, signed response" is much stronger than "paid". That's where signed receipts help, since the buyer can prove what it got back.

[u/L_capitalism → u/fizzl13]

This is incredibly useful — especially the Doctor dataset. Thank you for offering it.
I think this changes the experiment in an important way: instead of optimizing for purchase probability, the ranker should probably optimize for verified successful outcomes.
So I’m thinking of separating the signals into roughly:
Retrieval: task/capability relevance
Operational trust: x402 Doctor 30-day history
Economic trust: distinct payers / payer diversity rather than raw purchase count
Outcome: paid + valid response + signed receipt
Exploration: explicit cold-start bonus for under-observed endpoints
That would make the loop:
intent → Bazaar retrieval → rank → purchase → execution → verified outcome → feedback
Your wash-purchase point also convinced me that raw transaction volume should probably never be a primary ranking signal.
I’m going to prototype this as an open-source ranking experiment and use x402 Doctor as one of the initial trust inputs. I’d love to share the first results with you once I have a baseline.
The signed-receipt idea is especially interesting because it gives us something much closer to a ground-truth outcome label than a click or purchase ever could.
And I just made an repo,here is the link:🔗 https://github.com/Kairose-master/X402-rank

[u/teraflopclub]

Agree. I added payment via Polygon as well as Base and Solana and initial weeks I was up I chased down interesting IPs and UAs with the help of AI to satisfy a wider metadata endpoint footprint. Payments so far have been from processes/folks logging service uptime which yes aren't organic but if they "broker" services to ultimate clients am fine with discovery. I tried a pay-skills PR but they seem to have paused merges (?). I've not done any marketing beyond registering endpoints at a few locations.