We Deleted Our Own API: Why Onchain Diary Went All-In on Education

This summer we did something that looks bizarre from the outside: we took a working API, one with real endpoints and real payments wired up through x402, and deleted it. On purpose. No acquisition, no pivot-for-survival drama. The API worked. We just asked ourselves what it was actually worth, and didn’t like the answer.

This post is the decision log. Not a retrospective dressed up as a victory lap, but the reasoning at the moment of choice, written for anyone weighing the same trade.

What we had

Onchain Diary started as a risk-intelligence tool. The pitch was straightforward: paste a wallet address or a token contract, get back a risk score. Address scoring pulled from risk feeds, explorer labels, and community blacklists. Token checks looked for honeypot patterns, hidden taxes, and rug-pull vectors. Coverage spanned Ethereum, Base, Arbitrum, Optimism, Polygon, BSC. There were calculators too — gas, vesting, impermanent loss. Payments ran through x402, the HTTP-native payment protocol: a cent per address check, a couple cents per token, settled on-chain, no accounts needed.

By every internal metric, it was a real product. And that’s exactly what made the question hard to dodge.

Reason one: the tool layer is crowded, and we were building wheel number forty

Spend a week in this niche and the picture gets uncomfortable. Wallet security dashboards, browser-extension risk warners, token scanners, on-chain forensics platforms. Several of them are excellent. Some have teams that have done nothing but this for years, incident databases going back further than our project exists, integrations in every major wallet.

We looked at our roadmap honestly and found mostly replication. A better UI on someone else’s data. A slightly different scoring weight. Another badge on the same signals. Every feature we could think of shipping, someone had already shipped, and in most cases maintained it longer than we could promise to.

“Build it anyway and compete on execution” is a fine answer when you have a structural edge. Which brings us to reason two.

Reason two: aggregation is a liability wearing a moat costume

Here is the uncomfortable truth about our API: not one signal in it was ours. Every input came from upstream providers. That means the product’s ceiling was set by other people’s roadmaps, and its floor was set by other people’s rate limits.

We had already felt this. An upstream changes a response format, and your scores go stale silently. A provider tightens limits, and your paying users get errors. You wake up to maintain code you didn’t write against services you don’t control. The more successful the API got, the more of this maintenance it would generate.

Maintenance that scales with success isn’t a moat. It’s a tax. And the education layer, by contrast, had the opposite shape: an article we write once keeps answering people’s questions for years, at zero marginal cost, with no upstream that can break it.

Reason three: the layer nobody was building

The more time we spent in crypto communities, the clearer the gap became. People kept asking the same questions. How does a wallet drainer actually take my funds? Why is this signature dangerous and that one fine? What does liquidity locked even mean?

Tools answer is this address dangerous. Nobody was answering why is it dangerous, and how does the whole attack work — at least not in language a normal person could read, in one place, without a security background.

That’s the bottom layer. Education. And it happens to be the layer where an independent researcher has a real advantage: we spend our days reading drainer campaigns and tracing stolen funds. Turning that into plain language is work we’re uniquely positioned to do. Turning it into a faster API than incumbents was not.

What we built instead

The pivot happened in one day. Every tool page, API doc, and payment endpoint came down. What went up:

• 77 deep-dive articles — attack anatomies, verification checklists, chain-specific token safety guides
• A 220-term glossary, every entry a self-contained plain-language definition, fully bilingual (English and Chinese, natively written, not translated)
• The Onchain Anti-Scam Yellow Paper — a free manual covering scam taxonomy, forensics basics, and layered defense checklists, with a 48-question test where every answer is grounded in the paper itself
• A security persona test — 16 real-world scenarios, 16 personas, one safety score

One technical artifact did survive the pivot, in a new form. The old API let machines query our risk scores. The new one lets machines read our knowledge: a read-only MCP server that exposes every article and glossary term to AI assistants, so when someone asks an AI about address poisoning or wallet drainers, the answer can come from the actual research instead of a forum thread. Same idea, inverted. We stopped selling signals and started giving away understanding.

What we’d tell anyone at the same crossroads

Three questions, in order. Ask them before sentiment attaches you to a working thing.

1. Is your data yours? If every input is someone else’s API, you’re renting your product. Rents go up.
2. Does maintaining it scale worse than it grows? If success mostly buys you more upstream breakage to chase, you’re running to stand still.
3. Is there a layer under your layer that nobody is building? Crowded markets usually mean the adjacent underserved thing is close enough to see.

Killing the API cost us a product. It bought back every hour we were spending on other people’s breaking changes, and pointed all of it at the thing only we could do.

That trade keeps looking better every week.

Discuss this on X @jask_don, or read the result at Onchain Diary.