JonathanBulkeley

@JonathanBulkeley's bio

bitdevs

When I started building Mycelia Signal — a sovereign price oracle for BTC, ETH, FX, and commodities — I had to decide how to charge for it.

The obvious answer was subscriptions. That's what everyone does. Sign up, enter your card, get an API key, pay monthly. But the more I thought about it, the more subscriptions felt like the wrong model for what I was building. A price oracle isn't a SaaS product. It's infrastructure. The consumers aren't humans logging into a dashboard — they're agents, bots, and protocols making automated requests. Why would a machine need a billing account?

Subscriptions also mean accounts. Accounts mean KYC, or at least email addresses. That breaks the permissionless nature of what I was trying to build. If a developer in Argentina or an AI agent wants to query a BTC/USD price, they shouldn't need to hand over a credit card first.
Lightning fixed this cleanly.

With L402, every API request is self-contained. The client hits the endpoint, gets a 402 Payment Required response with a Lightning invoice, pays it, and re-submits with the preimage as a credential. No accounts. No API keys. No billing cycle. 10 sats per query, settled instantly.
It's a fundamentally different mental model. Instead of "pay us monthly for access," it's "pay per use, right now, with money that moves at the speed of the request." That's what machine-to-machine payments should look like.

A few things I learned building this:

The UX challenge is real for humans, trivial for machines. Human users still find Lightning invoices awkward. But for automated clients, L402 is actually simpler than OAuth — there's no token refresh, no session management, just pay and proceed.

10 sats is essentially free, but it's not zero. That tiny cost filters out noise. Scrapers and bad actors don't bother. Legitimate use cases don't notice.Running your own node matters. Relying on a custodial wallet for production API payments is a bad idea. We run our own Lightning node on the same server as the oracle backends. Payments settle directly, no third party.

We also added x402 (USDC on Base) as an alternative path for clients that can't do Lightning yet — but Lightning is the primary path and the one that actually fits the model.

If you're building an API and considering how to monetize it, I'd encourage you to at least think through whether subscriptions actually match your use case. For anything that's infrastructure, accessed programmatically, by machines — Lightning is a much better fit.

Happy to answer questions about the L402 implementation if anyone's curious.

Mycelia Signal is a sovereign price oracle with cryptographic attestation. Docs at myceliasignal.com/docs

Why I Used Lightning to Monetize My API (And Why Subscriptions Never Made Sense)

Founder of Mycelia Signal and done a few other things along the way