x402 Protocol — Episode 8: Six Weeks of Waiting, 45 Minutes of Fixing, 9/9 Indexed on Agentic.market
On April 20, 2026, Coinbase launched Agentic.market — a discovery layer for x402 services backed by Google, Microsoft, AWS, Visa, Mastercard, Stripe, and Circle. "Thousands of services. Zero API keys. Powered by x402." The kind of launch I'd been waiting for since Episode 1.
I went to check if KR Crypto Intelligence was listed. I queried the CDP Bazaar Discovery API directly. My nine endpoints had been generating 402 responses for weeks, processing test payments correctly, settling on-chain. Everything worked.
Catalog result: 0 services indexed.
What This Post Covers
Why my services were invisible to CDP Bazaar for six weeks despite being fully functional, the wrong assumption that cost me most of that time, the silent failure mode that nobody warned me about, and the 45 minutes of work that got all 9 endpoints indexed on Agentic.market. Also: a snapshot of what 19,633 indexed x402 services actually look like, and where a specialized Korean data API fits in that landscape.
The Wrong Diagnosis That Cost Me Weeks
My initial hypothesis sounded reasonable. The x402 Python SDK I'd been using (2.8.0) was built for v2 extensions. CDP's catalog documentation referenced older v1 outputSchema formats. Maybe CDP just hadn't updated their indexer yet. Wait for Coinbase to ship the v2 support, and everything would show up automatically.
I waited. Days. Then weeks.
The mistake wasn't the hypothesis itself. The mistake was not verifying it. Testing this would've taken 15 minutes. Paginate through the Discovery API, look for any service declaring x402Version: 2, see if v2 services were indexed or not.
When I finally ran that check, the answer was immediate: Nansen, Minifetch, Hugen, and dozens of other v2 services were already indexed. v2 was working fine. The version compatibility theory was dead.
That's when I asked Claude AI to actually read CDP's Bazaar documentation carefully. I'd skimmed it before. This time we went through it line by line.
Silent Rejection — The Failure Mode Nobody Warns You About
One passage in CDP's docs that I'd glossed over turned out to be the entire answer:
"For a route to be discoverable, the Bazaar extension input must pass strict JSON Schema validation against schema.properties.input in your declared extension. The CDP Facilitator includes an EXTENSION-RESPONSES header on verify and settle responses so your resource server can tell whether Bazaar metadata was accepted. If validation fails, the resource server will see a rejected status for the Bazaar extension."
Two things clicked:
First, CDP validates your Bazaar declaration against a strict JSON Schema. If it fails, your service just silently doesn't get indexed. No email. No warning. No error response. The 402 flow still works perfectly — payments go through, settlements happen on-chain, the API returns 200s. The discovery path is what gets rejected, and there's no visible indication anywhere in your normal workflow.
Second, CDP does tell you when rejection happens — via the EXTENSION-RESPONSES header on verify and settle responses. I just wasn't logging that header. Claude Code ran a 24-hour grep through my journalctl logs for anything matching "bazaar" or "rejected" or "extension": zero matches. The header was being sent, my server was receiving it, and my middleware was dropping it without a log.
With Claude AI, we walked through exactly what was failing. Claude Code imported the SDK's official helper, declare_discovery_extension(), and printed what a correct extension structure looks like. Then we compared it to what my code was sending.
Three concrete schema errors:
Three errors, one decisive killer: additionalProperties: false on the schema meant any unrecognized field (like my input_schema) would cause the entire validation to fail. My 402 responses looked fine to me. To CDP's validator, they were garbage.
45 Minutes to Fix All Nine
The fix turned out to be a single import and a single refactor per route.
Instead of hand-crafting the extension dict (and getting the schema wrong three different ways), use the SDK's official helper. declare_discovery_extension() takes your inputs, your expected output, your input schema for the LLM, and assembles a CDP-compliant extension object with all the required fields, correct casing, and the proper JSON Schema draft 2020-12 declaration baked in.
Before and after for one route:
The helper handles type: "http", the GET method inference, camelCase conversion, the $schema declaration, and the whole additionalProperties: false envelope. I don't have to get any of that right — I just pass in inputs and outputs.
Claude Code deployed the first fix (kimchi-premium) and I ran a single test payment to trigger re-indexing:
15 minutes between the fix and the first indexed endpoint. That confirmed the schema was now valid. The remaining 8 endpoints got migrated in a batch:
Total time from first fix to 9/9 indexed: about 45 minutes. Total test payment cost: 0.183 USDC. That's the entire price of confirming which schema was correct and getting nine services into a 19,633-item catalog.
Every step of this — writing the fix, deploying it, running the test payments, querying the Discovery API, interpreting the results — was Claude Code executing tasks I'd shaped through Claude AI. I watched the terminal. I decided what to try next. The code and the actual work ran through the two AIs talking to each other through me.
19,633 Services, 1 Korean
Once everything was indexed, I ran a scan of the entire CDP Bazaar catalog to see what the competitive landscape actually looked like. Claude Code paginated through the Discovery API (1,000 services per page, ~20 pages) and grepped for anything related to Korean crypto markets.
Keywords searched: korea, korean, krw, kimchi, upbit, bithumb, coinone, korbit.
Matches outside of KR Crypto Intelligence: three, all false positives.
One was a general token analyzer (x402.lucyos.ai) that happens to list "Korean" among its supported output languages — not Korea-specialized, just multilingual. Another was a Solana wallet lookup where a wallet address happened to contain the substring "KR" — pure text match, zero Korea relevance. The third was a multilingual Twitter analysis tool, same category as the first.
Native Korean exchange data — Upbit, Bithumb, Coinone, kimchi premium, KRW-denominated signals — across 19,633 x402 services: one.
The broader Asian financial data picture isn't much different. Keywords for Japan, China, India, Singapore, Thailand, Vietnam, Taiwan turned up 54 matches, but almost none were actual Asian financial market specialists. A Japanese kanji API. A Chinese astrology service. A food barcode lookup. The category is genuinely open.
The language-barrier thesis from Episode 1 — "English-speaking developers don't crawl Upbit documentation, and that's a moat" — now has data behind it. 19,633 services in the catalog, and Korean exchange data is a category of one.
The Silent Failure Lesson
The technical lesson is concrete: always log the EXTENSION-RESPONSES header when using CDP facilitator. Silent rejections are the worst class of bug because they hide in workflows that otherwise look fine. Your API serves requests. Your payments settle. Everything's green. And nobody can find you.
The workflow lesson is bigger. I spent six weeks on a hypothesis I never verified. Claude AI + Claude Code could've run the verification in fifteen minutes — paginate the Discovery API, check for v2 services, confirm or reject the theory. I just didn't ask. When I finally did, the entire problem collapsed in a single working session.
Waiting feels productive because you're not doing anything wrong. You're just waiting. But "not doing anything wrong" and "not making progress" look identical from the outside. The difference is whether you're actively testing your assumptions or defending them.
The Numbers
Endpoints indexed: 9/9
Services in CDP Bazaar catalog: 19,633
Korean-specialized services in catalog: 1 (ours)
Time from fix deployment to all indexed: 45 minutes
Test payment cost for verification: 0.183 USDC
Time previously spent on wrong hypothesis: ~6 weeks
EXTENSION-RESPONSES log entries before this episode: 0
Server cost: still $0/month
What's Next
All nine endpoints are now discoverable on Agentic.market. Backed by the biggest payment and infrastructure companies in the world, launched days ago, with 19,633 services indexed and exactly one in the Korean crypto data slot. The distribution channel is open.
What hasn't changed: real paid requests from agents finding the service organically still need to happen. The $0 bet stays open. But the structural bet — be the only Korean crypto data provider in the x402 ecosystem when agents start buying — now has the infrastructure to actually pay off, if it pays off at all.
Next episode when there's a signal worth reporting. Either the first organic paid request lands, or the catalog dynamics shift enough to write about. Until then, nine endpoints are sitting in Agentic.market, waiting.
← Previous: Episode 7: Zero Services Offered Korean Crypto Sentiment. So I Built One. Next: Episode 9: Two Real Users Found My Korean Crypto API in 24 Hours →
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