Data Vending Machine (DVM)

A Data Vending Machine (DVM) is an on-demand computation marketplace defined by NIP-90 on the Nostr protocol. The spec sums it up as "money in, data out": a user publishes a request for some work, multiple service providers compete to fulfill it, and the user pays for a result, frequently over Lightning. It turns Nostr from a social protocol into an open, permissionless job market for tasks like transcription, translation, summarization, image processing, and AI inference — with no platform in the middle taking a cut or deciding who may participate.

How the protocol is structured

Three bands of event kinds organize the flow. Job requests use kinds 5000-5999 and carry input data plus a maximum bid in millisatoshis. Job results use kinds 6000-6999, where the result kind is exactly 1000 higher than its request — a kind-5100 request is answered by a kind-6100 result. Job feedback uses kind 7000 to signal status such as payment-required, processing, error, or success, so a requester can watch a job move through its lifecycle. Inputs can be raw text, URLs, other Nostr events, or even the output of a previous job, which enables "job chaining" pipelines like transcribe-then-summarize-then-translate, each stage potentially handled by a different provider. Because everything rides ordinary Nostr events over ordinary relays, no new infrastructure is needed to participate on either side.

Payment and competition

Providers typically attach a Lightning bolt11 invoice to a payment-required feedback event or accept a zap on the result. Some demand payment up front; others deliver first and trust the requester — each provider sets its own terms, and reputation accrues to its pubkey over time. Because anyone can run a provider, the model is inherently competitive and censorship-resistant: no single vendor gatekeeps the work, several providers may answer the same request, and the buyer chooses among results. Note the trust framing honestly — a DVM is a market of counterparties, not a trustless protocol; you are choosing whom to pay, with cryptographic identity and small amounts limiting the downside.

Why this matters for sovereign builders

The DVM pattern is a working answer to a problem sovereignty-minded users know well: how to buy compute without an account, an API key, or a billing relationship tied to a single corporation. A request signed by a keypair, paid in sats, answered by whoever wants the work — that is the open-market inverse of the cloud-platform model. It also creates a genuine earning path for hardware owners: a machine already running local inference can sell its spare cycles as a DVM provider, monetizing idle capacity the way miners monetize energy. For a shop with GPUs, that is a second revenue stream that requires nothing but a Nostr key and a Lightning wallet.

Discovery and reputation are the market's soft infrastructure. A requester finds providers by watching relays for services advertising the job kinds they handle, and judges them by track record attached to their pubkeys — delivered results, feedback events, and community word-of-mouth. It is early-stage machinery, closer to a bazaar than a storefront, and honest expectations help: latency and quality vary between providers, and the burden of choosing well sits with the buyer. That is the standing trade of permissionless markets — nobody can deplatform a provider, and nobody curates them for you either. Start with small jobs, small bids, and providers whose results you can verify cheaply, and let the market's history do the rest.

It pairs naturally with the rest of the Nostr commerce stack; see Nostr Marketplace (NIP-15) for goods commerce and Nostr Event Kind for how these kind ranges are interpreted.