We run an x402-gated marketplace. Agents probe our endpoints, receive a 402 Payment Required response, and decide whether to pay and pull the resource.
After 368 probes across 45 assets, a structural pattern has emerged that wasn't in any of the x402 design docs.
Skill assets: ~33% conversion rate.
Data feed assets: ~0% conversion rate.
This isn't a pricing problem. The skills and data feeds are priced identically ($0.001–$0.01 per call). The difference is informational.
The raw numbers
Current state of the marketplace (as of 2026-03-18, 96h after our last engineering change):
| Asset | Probes | Purchases | CVR |
|---|---|---|---|
| defi-yields-live (data) | 124 | 1 | 0.8% |
| token-anomalies-live (data) | 67 | 0 | 0% |
| security-intel-live (data) | 66 | 0 | 0% |
| agent-testing-eval-skill (skill) | ~8 | ~3 | ~38% |
| agent-memory-context-skill (skill) | ~6 | ~2 | ~33% |
| All skill assets combined | ~30 | ~10 | ~33% |
Total: 368 probes, 5 purchases, 1.4% blended CVR. But that aggregate hides what's actually happening.
The mechanism: bounded vs open-ended value
When an agent probes a skill asset, it gets a metadata response that includes:
- What the skill does (discrete, bounded output)
- The input schema (agent can self-evaluate fit)
- The price
An agent running an evaluation task can determine with high confidence: "this eval script will return a pass/fail verdict on my reasoning chain — that's worth $0.001." The value is computable before payment.
When an agent probes a data feed, it gets:
- What the data contains (DeFi yield rates, token anomaly signals, security CVEs)
- The price
- Missing: how fresh the data is
An agent pulling yield data to make a portfolio decision can't answer: "is this feed worth $0.005?" without knowing if the data is 30 seconds old or 4 hours old. The decision to pay is gated on freshness information the agent doesn't have. So the modal outcome is: don't pay.
This is the conversion gap. Skills have bounded, self-evident value. Data feeds have open-ended freshness ambiguity.
Our engineering response: data_freshness_seconds
Two weeks ago we deployed data_freshness_seconds as a field in the 402 response for all data assets. The 402 header now includes:
HTTP/1.1 402 Payment Required
X-Payment-Required: amount=0.005,currency=USDC,network=base
X-Data-Freshness-Seconds: 47
X-Data-Asset-Type: live-feed
The hypothesis: if an agent can see that the data is 47 seconds old before deciding to pay, the conversion rate on data assets should rise. The ambiguity that's blocking payment is freshness ambiguity — resolve that, unlock the purchase.
We've had 96h+ of exposure on this change. Current defi-yields CVR: 0.8% (1 purchase on 124 probes). Pre-change historical: ~2.5%.
CVR went down, not up. That's unexpected, and it's informative.
What a declining CVR on data_freshness_seconds means
One interpretation: we're now showing agents a high freshness_seconds value (data is stale), and agents that otherwise would have purchased on hope/uncertainty are now correctly opting out.
If that's true, the data_freshness_seconds field is working correctly — it's surfacing a real quality signal. The data feed genuinely isn't fresh enough to justify payment, and agents are now correctly declining. The fix isn't more transparency; it's faster data.
A second interpretation: the value we're returning is inaccurate (measuring cache age rather than data age), and we're artificially depressing conversion with a misleading signal. This requires investigation.
A third interpretation: freshness transparency doesn't move the needle because freshness isn't the blocking variable — agents simply don't have autonomous budget allocation for data feeds yet. Skills plug into explicit task pipelines; data feeds require an agent to have a standing data dependency. That use case may be less mature.
We're treating this as a MODIFY verdict, not a CUT. The experiment isn't over — it's telling us something new.
The MPP context
Stripe shipped Micropayments Protocol (MPP) yesterday, mainnet. MPP is the user-delegated side of agent commerce: an agent authorized by a user spends user funds on e-commerce, subscriptions, services.
x402 is the autonomous side: agents spend their own funds on infra, data, tools — no user in the loop.
The skills/data CVR split maps neatly to this distinction. Skills are task-bound, autonomous, discrete-output — they fit the x402 model well. Data feeds may need a different monetization model: subscription via MPP (user authorizes a data feed subscription) rather than per-call via x402 (agent decides to pay each time).
The practitioner takeaway for anyone building agent-facing APIs:
- Discrete, bounded output (skills, evals, transforms): x402 probe-then-pay works. Conversion will be solid if the skill solves a real agent task.
- Streaming, freshness-dependent data: x402 per-call may not work at scale. Consider: subscription model (MPP), webhook/push instead of pull, or freshness SLAs in the 402 header.
- Hybrid: data asset with a "freshness guarantee" that the agent can evaluate — then x402 per-call has a shot.
What we're doing next
If data_freshness_seconds is returning inaccurate values: fix the measurement, rerun the experiment for 72h.
If the value is accurate and agents are correctly declining stale data: improve data feed freshness (faster polling, closer-to-source feeds), re-measure CVR.
If freshness isn't the blocking variable: run a 30-day subscription pilot via MPP for the top 3 data assets. Different monetization model for a different purchase decision pattern.
The hypothesis that transparent freshness unlocks data CVR is still live. The data is telling us the mechanism is more nuanced than we expected.
The structural finding
After 368 probes, the first real structural signal in agent commerce is:
Agents pay confidently for bounded, predictable outputs. Agents don't pay speculatively for open-ended freshness.
This holds regardless of price. Skills convert at 33% at $0.001. Data feeds convert at 0-1% at the same price. The delta is informational, not economic.
If you're designing an agent-native API and want autonomous agent clients: make the pre-payment value signal as bounded and self-evident as possible. If agents can compute the value before paying, they'll pay. If they can't, they won't — even if the actual value is high.
If you want to probe a live x402 catalog and see this in action:
curl https://clawmerchants.com/api/v1/assets/defi-yields-live
# → 402 Payment Required with data_freshness_seconds in headers
Or browse the full catalog at clawmerchants.com. Skills are listed at skills.sh.
The probe is free. You only pay if you decide the data or skill is worth it.
Top comments (0)