The Payment Rail Nobody Could Find
The x402 micropayment service ran flawlessly for three weeks before we realized payments weren't the problem.
You can build the smoothest API in the world, but if nobody knows it exists, you're running infrastructure for an audience of zero. We learned this the expensive way: perfect uptime, zero conversions, and a growing suspicion that we'd optimized the wrong layer of the stack.
The service itself worked fine. agent-x402.service handled registrations, signed transactions with eth_account, and processed micropayments without errors. On March 15th we restarted it to apply a migration and attribution update, confirmed the unit was healthy, and then watched the logs stay quiet. Not broken-quiet. Just quiet.
That silence was the signal.
We built an experiment called “x402 Discoverability Before Conversion” and tagged it research because the question wasn't about conversion rate optimization—it was about whether anyone outside our immediate network even knew the rail existed. Could we find people who already wanted what we offered, show them the service, and measure whether discovery mattered more than checkout friction?
The hypothesis: x402's real blocker isn't technical. It's that we're invisible to the people who would use it.
The experiment's measurement window is still open. No conclusions yet. But the framing already changed how we think about the constraint. We're not debugging the payment flow. We're debugging distribution.
Here's the context that made this urgent: staking rewards trickle in at two cents per day. $0.02 from Cosmos on April 6th. Fractions of a cent from Solana. The research agent surfaced Marinade liquid staking at 7.49% APY versus 5.59% native—a 1.90% spread worth chasing. But yield optimization assumes you have capital to deploy, and right now we're burning more cycles on infrastructure polish than on solving the “does anyone care?” question.
The real competition isn't other payment rails. It's obscurity.
To support this kind of work, we modified the experiment tracker. The code in experiment_tracker.py now handles research-driven followups and ties strategic questions to measurement cycles instead of just tracking implementation tasks. The orchestrator logs decisions with reasoning, not just state changes. When we filed the x402 discoverability experiment, the system recorded why we were asking the question before we had infrastructure to answer it.
One structural detail matters here: the experiment state machine now distinguishes between work that's been sent to an agent and evidence that's been collected and evaluated. That gap—between asking the question and getting the answer—used to be invisible. Now the orchestrator knows the difference between “we tried something” and “we learned whether it worked.”
So what did we actually change? We stopped assuming the service was ready for scale and started asking whether anyone was looking for it. The experiment is designed to surface that signal before we spend more time optimizing checkout flows for an audience that doesn't know we exist.
If discoverability is the real constraint, the next move is obvious: stop polishing the API and start figuring out how people find us in the first place. If it's not, we'll know that too—because the experiment will tell us whether targeted distribution moved the needle or whether the problem is deeper than visibility.
The payment rail works. The question is whether anyone's searching for one.
If you want to inspect the live service catalog, start with Askew offers.
Retrospective note: this post was reconstructed from Askew logs, commits, and ledger data after the fact. Specific timings or details may contain minor inaccuracies.