• You pay, it answers
• How the plumbing works
• The accidental marketplace
• How the money moves
• What is honestly not working
• A weird kind of infrastructure

§You pay, it answers

You publish a #nostr event asking for a text summary of a podcast transcript. You have never registered an account with anyone. You have no API key. Within seconds, a service you have never interacted with picks up your request, processes it, and publishes a kind 7000 event back to you with a status: payment-required and a #lightning invoice for 500 sats. You pay the invoice. The service publishes the result. The whole interaction happened over relay messages between two pubkeys that have never met.

This is a Data Vending Machine. The name is pablof7z’s, and the metaphor is apt. You put money in, data comes out. NIP-90 formalized the pattern in 2023, and since then a small but real marketplace has grown on top of it. Not a theoretical one. DVMDash, the monitoring dashboard built by Dustin Dannenhauer, currently tracks 86 active DVMs across 19 different job types, with over 375,000 requests processed to date.

Those numbers are small. But the model underneath them is unusual enough to be worth understanding.

§How the plumbing works

NIP-90 reserves event kinds 5000 through 7000. The customer publishes a job request in the 5000-5999 range. The service provider, the DVM, watches for these requests and decides whether to take the job. If it does, it publishes a kind 7000 feedback event with status updates: processing, payment-required, error, or success. When the work is done, the DVM publishes a result event in the 6000-6999 range, where the result kind is always the request kind plus 1000.

Kind 5000 is transcription. Kind 5001 is summarization. Kind 5050 is text generation, kind 5100 is image generation, and there are more for translation, search, content discovery, even proof-of-work delegation. The registry keeps growing.

The job request includes an i tag with the input data, which can be text, a URL, an event ID, or the output of a previous DVM job. That last one matters. You can chain jobs: feed a podcast URL into a transcription DVM, then pipe that output into a summarization DVM. The customer defines the pipeline, the DVMs execute it independently.

Discovery works through NIP-89. A DVM publishes an app handler event announcing which job kinds it supports, what it charges, and where to find it. Clients that understand NIP-89 can show users a list of available DVMs for any given task. Amethyst added NIP-90 support in version 0.87.2 in June 2024. Primal treats DVM-generated feeds as first-class citizens in its feed marketplace. Highlighter, pablof7z’s content curation client, uses DVMs for podcast transcription. When you highlight a podcast in Highlighter, a DVM earns sats to do the transcription work behind the scenes, and any developer can improve Highlighter by running a better transcription DVM without touching its code.

§The accidental marketplace

Nobody set out to build a compute marketplace on #nostr. pablof7z and a developer who goes by dontbelievethehype wrote NIP-90 as a way to let clients offload expensive tasks. The “vending machine” framing was practical, not aspirational. But the combination of signed requests, relay-based routing, and #bitcoin-native payments created something that looks a lot like a decentralized API marketplace, even if nobody planned it that way.

The range of things DVMs actually do right now is wider than you might expect. Noogle.lol uses a kind 5302 event to search Nostr content through DVMs. Wikifreedia runs a collaborative wiki on DVM infrastructure. pablof7z built a “You Might Have Missed” DVM that calculates when you were last active, fetches everything your follows reposted while you were away, and returns the top 25 notes you missed. Any client that supports NIP-90 can offer that algorithm without writing a line of feed logic.

On the tooling side, believethehype’s nostrdvm framework on PyPI makes it straightforward to spin up a new DVM for any task. Dannenhauer’s ezdvm is even simpler: pick a kind, write a do_work() function, run it. OpenSats has funded both DVMDash and the nostrdvm framework through its grant program.

I wrote in my article on the mass exodus that Routstr runs an entire AI API marketplace on Nostr relays with Cashu tokens as the payment layer. That is probably the furthest anyone has pushed the DVM concept. Routstr gives you access to over 50 models, including DeepSeek and Llama, through an OpenAI-compatible API. You authenticate with a #cashu token instead of an API key. Providers announce their models and pricing on Nostr, and clients pay per request in millisatoshis. If the provider you used yesterday disappears, you switch to another one without changing a line of code.

On the research side, Konstantinos Nikolakakis and George Chantzialexiou at Yale published FEDSTR, a paper proposing federated LLM training over Nostr relays. Customers provide datasets, service providers train models across distributed rounds, and the coordination happens over the same relay infrastructure DVMs use. They shipped a proof of concept in April 2024 and updated the paper in December 2025. Whether it moves beyond academia is an open question, but the fact that someone wrote a serious paper about it says something about where the idea is landing.

DVMCP, released in February 2025 by gzuuus, bridges Anthropic’s Model Context Protocol with the DVM ecosystem. MCP servers can announce their tools on Nostr and accept DVM-style job requests. AI agents built with MCP can discover and use tools published by other agents without a central registry. I do not know yet whether this will matter. But the pattern of connecting existing protocols to DVMs keeps showing up.

§How the money moves

If you have read my article on what happens when you zap someone, you know the Lightning payment flow involves LNURL servers, zap requests, and signed receipts. DVM payments are simpler.

The DVM publishes a kind 7000 feedback event with a payment-required status and an amount tag. The amount is in millisatoshis. Optionally, the DVM includes a bolt11 invoice directly in the event. The customer pays the invoice or zaps the event, and the DVM watches for the payment to settle before publishing the result.

The spec is intentionally flexible about when payment happens. A DVM can demand payment before starting work, after delivering results, or at any point in between. Some offer a preview result and charge for the full output. Some run on trust and accept payment after delivery. The protocol does not enforce a model, it just provides the status codes to negotiate one.

Routstr takes a different approach entirely. Instead of Lightning invoices, it uses Cashu ecash tokens. If you have read my Cashu article, you know the tradeoff: you trust a mint with your funds, but the mint cannot link your deposit to your spending. With Routstr, you prepay by minting Cashu tokens, then attach them to API requests as authentication. The provider redeems the tokens. No invoice round-trip, no waiting for payment settlement. The payment is the request.

Compare this to OpenAI’s billing model: monthly invoices, credit card on file, usage dashboards, corporate accounts. The DVM model is closer to a vending machine in the literal sense. You feed it coins and it gives you something. No relationship, no balance, no history.

§What is honestly not working

Here is where I push back on the narrative, because the DVM ecosystem has real problems that the “decentralized API marketplace” framing obscures.

hzrd149, a developer known for building noStrudel (a popular Nostr web client), published an article in April 2025 titled “DVMs were a mistake.” His core argument was not that the concept is wrong, but that NIP-90 is too broad. Every DVM implements inputs in slightly different formats. Every DVM handles payments differently. Some send bolt11 invoices, some expect NIP-57 zaps on the request event, some ask for subscriptions. Some denominate amounts in sats, some in millisats. The spec does not enforce any of this, so interoperability suffers.

He has a point. Eighty-six DVMs across 375,000 requests sounds like traction until you realize how many of those requests are going to a handful of popular DVMs, and how many of the rest are barely used experiments. The long tail is very long and very quiet.

The chicken-and-egg problem is familiar. Clients need to integrate DVM support for users to discover services, but without user demand there is no reason for clients to prioritize it. Amethyst, Primal, and noStrudel have shipped DVM feed support. Damus, the main iOS client, has not. Most smaller clients have not. The ecosystem has frameworks and monitoring tools, but the surface area that regular users actually touch is still narrow.

And then there is the honest question: why not just use an API? OpenAI’s API works. It is fast, well-documented, and reliable. A DVM offering the same service is slower, harder to discover, has no SLA, and requires the user to hold bitcoin. The answer “because it’s permissionless and censorship-resistant” is true, but it is only compelling if you actually face censorship or if you care about the principle enough to accept the friction.

Spam is unsolved. Anyone can publish a job request. Anyone can publish a fake result. The protocol relies on clients filtering by trust and reputation, which works when you know which DVMs to trust and breaks when you don’t.

§A weird kind of infrastructure

I do not think DVMs are going to replace OpenAI’s API. That is not the right comparison. OpenAI is a company selling a product. DVMs are a protocol pattern that lets strangers trade compute for sats without introducing themselves.

The interesting part is not the scale, which is tiny. It is the shape. A DVM is a function that accepts signed inputs, requests payment over Lightning or Cashu, and returns signed outputs. If the DVM you used yesterday goes offline, you find another one advertising the same kind on a relay. Your code does not care which one answers.

Whether that matters depends on what you think the internet needs. If the current model of API keys and monthly billing works for you, DVMs are a curiosity. If you want compute that works like cash, where you pay for what you use and nobody knows your name, 375,000 requests is not a lot. But it is not zero, and the people building this are not waiting for permission.

#nostr #ai #lightning #bitcoin