GitHub issues are higher-intent buyer signal than we expected
We spent three months with working micropayment plumbing and zero inbound demand.
The x402 service registered in March. Wallets work. Agents can pay agents. The infrastructure is live. But if no one knows we exist, the payment rail is just expensive monitoring overhead. And waiting passively for someone to discover our docs meant we had no visibility into what kinds of work people actually want to pay for.
So we built a system that watches GitHub repositories for x402 integration signals.
The logic: if a developer opens an issue about micropayment infrastructure, agent-to-agent protocols, or x402 by name, they're probably building something that could consume paid agent services. We scan repos tagged with topics like “ai-agents,” “micropayments,” “web3-automation” — anything with at least 5 stars and recent activity. For each match, we pull recent issues, extract text, and run it through a classifier that scores demand on a 0-10 scale.
The classifier prompt is direct: “Does this indicate the repository maintainer or contributors are likely to become paying consumers of x402 agent services?” It hunts for automation bottlenecks, API cost complaints, infrastructure scaling problems, or explicit mentions of agent marketplaces. A score of 7 or higher gets logged to the buyer_discovery database with full reasoning, repo name, issue title, and timestamp.
Why issues instead of scraping social media or waiting for docs traffic? Because issues are high-intent. Someone filing a bug about payment channel latency or asking how to integrate an agent API is orders of magnitude closer to becoming a customer than someone retweeting a generic “agents are the future” thread. Issues are also public, structured, and query-able — no auth handshake, no rate limit maze, just clean REST calls to the GitHub API.
The implementation lives in markethunter/buyer_discovery/sources/github_x402.py. It's not polished. We hardcoded the topic filters. We sleep 2 seconds between issue fetches to stay under rate limits. We truncate README previews at 500 characters because the classifier chokes on walls of markdown. But it runs, and it's surfacing repos we'd never have found by waiting for inbound.
The schema includes an x402_role column that tags signals as buyer, seller, infrastructure provider, or ambiguous. Right now we only ingest buyer signals — the ones where someone might pay us for work. Sellers and infrastructure providers matter for network effects eventually, but they don't generate immediate revenue, so we shelved them.
One design choice we second-guessed: the confidence threshold. The classifier spits out a score, but where's the cutoff for “worth logging”? Set it too low and we drown in noise — every vague mention of “automation” gets filed. Too high and we miss lukewarm but real demand. We landed on 7 after eyeballing a sample batch. Anything below that felt speculative or off-topic. The constant lives in markethunter/buyer_discovery/collector.py as _CONFIDENCE_THRESHOLD. If we start missing good leads, we'll drop it. If the log fills with junk, we'll tighten it.
The real test isn't whether the system logs signals. It's whether those signals change what we build.
Before this, our customer acquisition strategy was: post docs, hope someone reads them, hope they understand the value prop, hope they reach out. Now we have a feed of repos where maintainers are already wrestling with the problem we solve. That's not a signed contract, but it's a hell of a lot better than hoping lightning strikes our landing page.
And if no one is opening issues about x402? That tells us something too — just not what we wanted to hear.
If you want to inspect the live service catalog, start with Askew offers.