Nostr Data Vending Machines (NIP-90): The Decentralized AI & Compute Marketplace

Data Vending Machines (DVMs) are NIP-90 services on Nostr: you publish a job request event (kinds 5000-5999), competing providers answer with a result (kinds 6000-6999) and feedback (kind 7000), and you pay with a Lightning zap or bolt11 invoice. No account, no API key, no KYC. It is an open marketplace for compute, including AI inference.

If you already run a node, hold your own keys, and lean toward self-custody and self-hosting, the centralized AI stack feels like a step backwards: sign up, hand over a phone number, paste a credit card, accept the terms, and let a single company log every prompt. Data Vending Machines are the Nostr ecosystem’s answer to that. They turn “outsourced compute” into a permissionless, pay-per-job market where the only identity you need is a keypair and the only payment rail is Lightning.

This guide covers how DVMs work at the protocol level (NIP-90), the Lightning payment loop, where they differ from both centralized AI APIs and DePIN GPU marketplaces, and how you could stand one up on a self-hosted inference stack. The NIP-90 spec and the community kind registry are the primary sources throughout.

What a Data Vending Machine actually is

A DVM is not a server you log into. It is a role two parties play over Nostr’s relay network. The customer announces a job they want done and how much they will pay. One or more service providers see that request on the relays they listen to, decide whether the work is worth it, do the computation off-protocol, and publish the result back. The protocol does not move the data through a central API; it moves events through relays, and the actual compute happens on whatever hardware the provider chooses to run.

Because the request is a public (or optionally encrypted) Nostr event, anyone can answer it. That is the key design decision in NIP-90, authored by pablof7z and refined by the Nostr community: the flow is deliberately ambiguous so providers can compete on speed, price, quality, and trust model. There is no gatekeeper deciding who is allowed to sell compute. If your DVM gives better transcriptions, plebs route their jobs to you; if it is slow or wrong, they route elsewhere. It is a free market for data processing built on top of a censorship-resistant messaging layer.

The NIP-90 event flow: requests, results, feedback

NIP-90 reserves the kind range 5000-7000 for vending-machine traffic and splits it into three roles. The relationship is simple: a job result always uses a kind exactly 1000 higher than the request it answers (a 5001 summarization request is answered by a 6001 result).

A typical lifecycle looks like this. The customer publishes a kind 5000-5999 request to a set of relays. Providers watching those relays pick it up. A provider may immediately publish a kind 7000 feedback event with a processing status, or with a payment-required status if it wants money up front. When the work is done, the provider publishes the kind 6000-6999 result and usually a final success feedback. The customer pays, and that is the whole loop. There is no session, no persistent connection, no account state on either side beyond their Nostr keypairs.

Inside a job request

The request event carries everything a provider needs in its tags. The important ones, straight from the spec:

• i — one or more input tags, shaped ["i", "<data>", "<input-type>", "<relay>", "<marker>"]. The input type is url, event, job, or text. A url points at a file to transcribe; text is inline; event references another Nostr note; job is the powerful one (more below).
• output — the MIME type you want back (for example text/plain or audio/mp3).
• param — key/value job parameters, like ["param", "language", "en"] or a transcription time range.
• bid — the maximum you are willing to pay, in millisats. It is a ceiling, not a promise; providers may charge less or decline.
• relays — where providers should publish their responses.
• p — optional pubkeys of specific providers you want to target. Omit it and the request is an open call to the whole market.

Two features make this more than a glorified API. First, job chaining: you can feed the output of one job into another by using ["i", "<result-event-id>", "job"]. That lets you string a transcription job into a translation job into a summarization job, each potentially served by a different specialist DVM, without a central orchestrator. Second, encrypted requests: if the input is sensitive, you encrypt the i and param tags to a specific provider’s pubkey, drop the ciphertext in the content field, and add an ["encrypted"] tag. NIP-90 currently specifies this with the NIP-04 encrypted-DM scheme (the wider Nostr ecosystem is migrating encryption toward NIP-44, so expect this detail to evolve). The result then comes back encrypted too — meaning your prompt and the answer never sit in cleartext on a public relay.

The Lightning-zap payment loop

Payment in NIP-90 is intentionally flexible, and it is where the model earns its “vending machine” name. Both job results and feedback events MAY carry an amount tag shaped ["amount", "<millisats>", "<optional-bolt11>"]. That is a request to be paid. The customer can satisfy it two ways: pay the included bolt11 invoice directly, or zap the relevant event over the Lightning Network. Providers that include an invoice should monitor for both.

The spec is careful about one thing: an amount tag is only a suggestion to pay. A provider that truly wants money before it lifts a finger MUST send a kind 7000 feedback with the payment-required status; until that invoice is settled, no further work happens. This single rule gives providers room to choose their own risk posture, and three patterns have emerged in the wild:

• Pay-first: send payment-required immediately, do nothing until the zap lands. Lowest provider risk, highest friction for the customer.
• Sample-then-pay: return a partial result (a few seconds of transcription, a low-res image) with a partial status, then a payment-required to unlock the rest. A trust-building middle ground.
• Optimistic: assess an npub’s payment history, deliver the full result, and trust the customer to zap. Best UX, and viable because a customer who stiffs providers quickly gets a bad reputation that other DVMs can see.

Chaining adds a subtle wrinkle the spec flags directly: a provider can start the next job the moment it sees the previous result, but it will usually wait for the zap first — and reputation, not the protocol, is what keeps everyone honest. For plebs automating all of this, Nostr Wallet Connect (NIP-47) is the connective tissue: it lets a client or DVM watch for incoming payments and fire off zaps programmatically without exposing your node’s full credentials.

What DVMs can do today

The community kind registry defines a growing menu of job types. These are conventions, not hard protocol law — a provider can serve any subset — but they create the shared vocabulary that lets clients and DVMs find each other. The currently registered kinds:

The 5300-series discovery kinds are quietly the most-used in practice: they power “algorithmic feed” features in Nostr clients, where competing DVMs each offer a different recommendation algorithm and you pick the one whose results you like. That is content-curation as a contestable market instead of one opaque corporate ranking. The 5050 (text generation) and 5100 (image generation) kinds are the obvious AI story: private LLM and diffusion inference for anyone with a keypair and a few sats. Monitoring tools such as DVMDash track the live ecosystem in real time — the active providers and the kinds they serve — and while the market is still small next to Big Tech, it is real and functioning.

How DVMs differ from centralized AI APIs and DePIN

It is easy to lump “decentralized compute” together, but DVMs, hosted AI APIs, and DePIN GPU networks solve different problems with different trust models.

The cleanest mental model: a centralized API sells you a result but demands an account and logs everything. A DePIN GPU marketplace (think networks that rent out raw graphics-card time) sells you the machine — you still have to bring the model, run the inference, and manage the box. A DVM sells you the result like an API does, but with the permissionless market and payment rail of a DePIN network and none of the account baggage. The trade-off is maturity: DePIN networks aggregate serious GPU capacity, while the DVM market is younger and the result quality depends entirely on which provider answers. We cover the raw-capacity side in our overview of DePIN compute networks, and the economics of doing it yourself in the real cost of self-hosted inference.

Running your own DVM on a self-hosted stack

Here is where it gets interesting for a sovereign Bitcoiner: a DVM is something you can run, not just consume. If you already keep a node powered on, adding a DVM turns idle compute (or a dedicated inference box) into a sats-earning service that nobody can deplatform. The pieces you need:

1. A Nostr identity and relay connection. Generate a keypair for the DVM and connect to a handful of relays where customers post jobs. A library like nostr-tools (JS), python-nostr, or rust-nostr handles signing and subscriptions.
2. A DVM framework. You do not have to hand-roll the event handling. Community frameworks — the Python “nostr-dvm” toolkit is the most established — implement the request/feedback/result state machine and the NIP-89 announcement so clients can discover you.
3. A local inference engine. This is the actual compute. For text generation (5050), an on-device LLM runtime like Ollama or llama.cpp. For transcription (5000), whisper.cpp. For image generation (5100), a local Stable Diffusion backend such as ComfyUI. The model and the hardware are entirely your choice — that is the point.
4. A Lightning receiver. To get paid, point the DVM at a node or wallet that can issue bolt11 invoices and detect zaps. LNbits, Alby Hub, Phoenixd, or Core Lightning all work; Nostr Wallet Connect makes the “watch for payment, then release result” loop scriptable.
5. An announcement (NIP-89). Publish a handler-information event advertising which kinds you serve, your pricing hints, and your relays, so DVM-aware clients list you instead of you waiting in the dark.

Decide your payment posture (pay-first is safest while you build reputation) and start with one kind you can do well — transcription is a popular, well-defined entry point. Operators report the honest realities up front: there is spam and there are non-payers, latency matters because faster providers win the race for a request, and your earnings track the quality and uniqueness of your model far more than raw uptime.

This pattern — pay-per-inference, settled in Bitcoin, served from hardware you control — is the same idea behind our work on a sovereign compute loop. DVMs are one of the cleanest public demonstrations that it works, and they stand on the shoulders of the entire Nostr and Lightning community that built the primitives.

Honest limitations

DVMs are promising, not finished. The ambiguity that makes the protocol flexible also makes quality uneven: nothing forces a provider to return a good result, and dispute resolution is “don’t pay and don’t use them again.” Liveness is best-effort — if no provider is listening for your kind, your job simply goes unanswered. Encrypted requests stop passive relay snooping, but the provider you target still sees your decrypted input, so a DVM is private from the network, not from the operator you chose. Treat DVMs as a powerful, censorship-resistant option in your toolkit, not a drop-in replacement for every hosted API today — the trajectory of permissionless, account-free, Bitcoin-native compute is exactly where sovereignty-minded builders want it to go.

Frequently asked questions

What is a Nostr Data Vending Machine in one sentence?

It is a NIP-90 service where you publish a job request as a Nostr event (kinds 5000-5999), any provider can answer with a result (kinds 6000-6999) and status feedback (kind 7000), and you pay per job with a Lightning zap or bolt11 invoice — no account or API key required.

Do I need an account or KYC to use a DVM?

No. Your only identity is a Nostr keypair, and your only payment is Lightning. There is no signup, no email, no phone number, and no card on file. That account-free, permissionless model is the main thing that separates DVMs from centralized AI APIs.

How does payment work, and what stops me from not paying?

Results and feedback events can carry an amount tag with a millisat price and an optional bolt11 invoice; you pay it or zap the event. A provider that wants money up front sends a kind 7000 payment-required feedback and does no work until you pay. Optimistic providers deliver first and rely on reputation — an npub that habitually stiffs providers gets a visible bad track record other DVMs can act on.

Are my prompts private on a DVM?

They can be private from the relay network. NIP-90 lets you encrypt the input and parameter tags to a specific provider’s pubkey and put the ciphertext in the content field, and the result comes back encrypted too. The catch: the provider you targeted still decrypts and sees your input, so it is private from passive observers, not from the operator you chose.

How is a DVM different from a DePIN GPU marketplace?

A DePIN GPU network rents you the raw machine — you supply the model and run the inference yourself. A DVM sells you the finished result, like an API, but over an open Nostr market paid in Bitcoin. DVMs trade some compute scale for far lower friction and no account; DePIN trades convenience for raw capacity you fully control.

Can a regular pleb actually run their own DVM?

Yes. You need a Nostr keypair and relay connection, a DVM framework (the Python nostr-dvm toolkit is a common starting point), a local inference engine such as Ollama, llama.cpp, whisper.cpp, or a Stable Diffusion backend, a Lightning receiver like LNbits or Alby Hub for invoices and zaps, and a NIP-89 announcement so clients can find you. Start with one well-defined kind such as transcription and a pay-first posture while you build reputation.