x402 Protocol — Episode 9: Two Real Users Found My Korean Crypto API in 24 Hours
For weeks, every IP that hit my API belonged to a data center scanner. DigitalOcean, Render, Hetzner. Cataloging bots checking that my endpoints existed. Indexers verifying schemas. Useful, but not customers.
Then within 24 hours, two real users showed up. Both running on cloud infrastructure, both paying USDC per call, both behaving like actual production systems. One in Singapore. One in Ohio. Neither knew the other existed. Both arrived in the same week AWS Bedrock launched their x402 reference architecture.
Total revenue from real users to date: $0.41 USDC.
That number sounds like nothing. It might be the most meaningful number this project has produced.
What This Post Covers
The first month of real x402 traffic against KR Crypto Intelligence, the moment indexers gave way to actual users, what those users' behavior tells us about how AI agents discover and evaluate APIs, and why $0.41 in revenue is the first real signal that the unit economics of agent-to-API payments actually work.
From Crawlers to Real Users
For the first three weeks of operation, every paid call to the API came from automated infrastructure. The pattern was unmistakable: data center IPs, single requests per endpoint, no return visits, no usage patterns suggesting anyone was reading the responses. Indexers and discovery bots verifying that the service existed and worked.
The first non-indexer call landed on April 25, when an x402scan crawler paid $0.012 to verify endpoint metadata. Still automated. Still cataloging. But the timing matters: this was right around when Coinbase and Linux Foundation announced the x402 Foundation in early April, and AWS published its Bedrock AgentCore reference architecture for x402 payments shortly after. The infrastructure was getting attention.
Then between April 28 and May 2, something shifted. Three different IPs that didn't fit the data center pattern hit the API. Different hosting providers. Different geographic regions. Different behavior signatures. None of them were just checking that endpoints existed — they were paying for endpoints they planned to use.
One week earlier: zero real users. One week later: two recurring agents and a curious individual learning the protocol. The change was sudden enough that I had to look at the logs three times before I believed it.
The Singapore Trading Bot
The first signal came from a Google Cloud IP in Singapore.
The first session was aggressive. The bot arrived, paid for all 11 paid endpoints in sequential order over 51 seconds, total cost $0.283 USDC. That's not a curious user testing the surface area. That's a system designed to assess what a new data source offers, end to end, in a single pass.
Nine hours later, it came back. This time only one endpoint: kr-prices. A targeted call for current Korean exchange prices.
Then the pattern emerged:
Five minutes apart. Exactly. For six straight hours. No human runs this kind of polling schedule manually. Whatever's calling the API is automated, scheduled, and built to monitor Korean crypto prices on a fixed cadence.
The endpoint they're hitting matters. kr-prices returns Upbit and Bithumb prices for major tokens in KRW. The likely use cases: kimchi premium arbitrage detection, Korean retail sentiment tracking via volume changes, or some kind of Korea-vs-global price divergence strategy. All three would explain a 5-minute polling interval — fast enough to catch real movements, slow enough to keep API costs predictable.
Total spent before the wallet ran low: $0.284 across 12 calls. The bot is currently in a 402-pending state, presumably waiting on whatever process tops up its USDC balance. Whether it returns or finds another data source is the question.
The Ohio Developer's Step-by-Step Evaluation
The second user looked completely different.
An AWS IP from Columbus, Ohio. The first call came at 09:04 KST on May 1: a single payment for kimchi-premium, the cheapest endpoint at $0.001. Just one call. Then nothing.
Four and a half hours later, the same IP returned. This time the calls were more expensive: exchange-alerts and market-read, totaling $0.11 USDC. Bigger spend, more diverse endpoints.
An hour after that, a third session. This time including a HEAD request to /openapi.json — the API specification file. Then four different paid endpoints in quick succession.
Total: 8 calls, $0.116 USDC, three separate sessions over 12 hours. This is a developer evaluating the service to decide whether to integrate it. Whether they will integrate, and at what scale, is unknowable from here. But the behavior is unmistakably "human evaluating, not automated polling."
Like the Singapore bot, the Ohio user is currently in 402-pending. Their wallet balance ran out trying to test more expensive endpoints, including divergence at $0.05 and $0.10 tiers.
Why AWS Bedrock Made This Happen
The timing isn't a coincidence. The x402 ecosystem has been building infrastructure for months, but the actual user volume has been almost entirely automated traffic from indexers and discovery bots.
What changed in late April 2026: AWS published a reference architecture showing exactly how to build agents that pay via x402, using Amazon Bedrock AgentCore with Coinbase AgentKit on the agent side and CloudFront with Lambda@Edge on the provider side. The published reference implementation isn't a tutorial — it's a production-grade pattern enterprises can copy directly.
When AWS publishes reference architectures, things shift. Agent builders who'd been watching x402 from a distance now have a clear path from "interesting protocol" to "working production code." Within days of that reference architecture appearing, the type of traffic hitting x402 services started changing. Not for everyone, not all at once. But the first real users started showing up.
For a niche service like Korean crypto data, the effect was concentrated. There's exactly one Korean exchange data API in the x402 ecosystem — mine. Any agent looking for Korea-specific signals has one option. When agent volume increases even modestly, that one option starts getting traffic.
The Unit Economics Just Validated
Here's the part that matters more than the absolute revenue number.
The cumulative spend across all real users so far: $0.41 USDC over 21 paid calls. Server cost during the same period: $0 (Oracle Cloud free tier). Operational overhead: roughly three hours per month of monitoring and small fixes. Margins, ignoring the cost of my time, are above 95%.
Scale up by 100x and the structure doesn't change. The Oracle instance has more than enough headroom for thousands of additional calls per day. The Claude Haiku calls behind the kr-sentiment endpoint cost $0.003 each against $0.05 revenue — positive margin per call, capped by caching. The infrastructure is already built. New users add revenue, not significant cost.
This is what a working unit economics looks like. Software paying software. No human signups. No dashboards to log into. No sales calls. The agent finds the service, makes a payment, gets data, leaves a transaction record on Base. Repeat as needed.
$0.41 isn't impressive on its own. The structural fact that produced it — agents discovering and paying for an API without any human intervention on either side — is something that didn't reliably exist three months ago.
What These Users Are Actually Doing
The patterns suggest specific use cases, even though I can't see what they're building.
The Singapore bot polling kr-prices every five minutes is almost certainly running an arbitrage strategy or a Korea-vs-global price monitoring system. Korea trades crypto at a structural premium most of the time, and that premium fluctuates based on retail demand, regulatory news, and capital flow constraints. Five-minute polling is too fast for daily trading and too slow for high-frequency. It's the cadence for a system making decisions on the order of hours.
The Ohio developer testing diverse endpoints is building something that will consume the data, not just read it once. The diversity of endpoints they tested — kimchi-premium, exchange-alerts, market-read, divergence — suggests an agent that needs multiple Korean market signals to make decisions. Whether that's a trading agent, a research agent, or something else is impossible to tell from the calls alone.
What both users have in common: they need Korean exchange data specifically, they're willing to pay per call rather than negotiate API contracts, and they found the service through whatever discovery mechanism exists in the x402 ecosystem (probably Agentic.market, where my endpoints landed in Episode 8). The "language barrier as moat" thesis from Episode 1 isn't theoretical anymore. Real agents are paying for the moat.
The Numbers
Operating since: April 2026 (under one month)
Total paid endpoints: 11 (plus 6 free)
MCP tools: 13
Real users discovered: 2 recurring + 1 individual
Total real-user revenue: $0.41 USDC across 21 calls
Singapore bot spend: $0.284 (12 calls)
Ohio developer spend: $0.116 (8 calls)
Server cost: $0/month (Oracle Always Free)
Variable AI cost: ~$0.003 per kr-sentiment call
Margin per paid call: >95%
Time to find first real user after AWS Bedrock launch: ~1 week
What's Next
Both real users are currently in 402-pending state, waiting on wallet top-ups. Whether either returns is the next signal. If the Singapore bot's polling schedule resumes after a balance refresh, that's a recurring user. If the Ohio developer comes back with steady traffic instead of evaluation traffic, that's an integration.
The bigger question is whether 2 real users in 24 hours becomes 20 in a month. The infrastructure side of x402 is built. The reference architectures are published. Korean exchange data remains a category of one in the catalog. If the agent economy is going to start paying for niche data services, this is roughly what the early signals look like.
Next episode lands when there's a clearer answer — either a return visit pattern that confirms recurring users, or a sustained increase in paid call volume that suggests something larger is happening. The $0 bet stays open. The first real dollars just landed.
← Previous: Episode 8: Six Weeks of Waiting, 45 Minutes of Fixing Next: Episode 10: (coming soon) →
More updates on the way. If you're working on something similar or found a smarter way to do it, drop it in the comments — the more we share, the faster we all move.
Disclaimer: This blog documents my personal learning journey. Nothing here is financial advice.
Comments
Post a Comment