NIP-90: Data Vending Machine
Nostr can broadcast work requests as well as social posts
The Data Vending Machine idea is attractive: a user publishes a request for computation, service providers compete or respond, and the result returns as another signed Nostr event. The job might be transcription, translation, summarization, search, image processing, model inference or anything else a provider can sell.
NIP-90 reserves kind ranges for this market. Requests live in 5000-5999. Results live exactly 1000 kinds higher, in 6000-6999. Feedback uses kind 7000. Tags describe inputs, outputs, bids, parameters, relays and chosen providers.
It is one of the most ambitious app-layer NIPs because it turns Nostr into a discovery and coordination bus for paid work.
Job requests, job results, feedback and bids
A job request can include i tags for input data, output tags for expected format, param tags for model or job-specific controls, bid tags in millisats and relays tags telling providers where to respond. A customer can name preferred providers with p tags.
The NIP also describes encrypted parameters, job feedback, payment-required responses and result events. Separate job-kind definitions live in the data-vending-machines repository rather than in the main NIP file.
The warning at the top now matters more than the mechanics: NIP-90 is marked unrecommended, with the note that it got out of control and use-case-specific microstandards are preferred.
A big idea that became too broad for one standard
NIP-90 has been edited repeatedly since the DVM wave began, with link fixes, formatting and kind-registry adjustments across 2024 and 2025. On May 31, 2026, fiatjaf added the unrecommended tag and warning to NIP bodies, including NIP-90.
The ecosystem around it is real. The nostr-protocol/data-vending-machines repository documents DVM kinds. Pablo Fernandez published a simple service-provider implementation. The nostr-dvm package advertises itself as a framework for building NIP-90 DVMs.
The fair article has to hold both facts: people built around the idea, and the canonical NIP now tells new implementers to prefer narrower standards.
Use existing DVM work carefully, but do not hide the warning
A product using NIP-90 needs to show the user what provider is being asked, what data is sent, whether the request is encrypted, what the bid means and where results will be returned. Computation markets can leak sensitive prompts or files if the UI treats every job like a public note.
Service providers need clear result semantics. Some historical discussion around DVMs has focused on confusion between feedback, invoices and final results. A user needs to know whether an event is a quote, a request for payment, a partial result or the finished output.
For new product work, use NIP-90 as history and ecosystem context, then check whether a narrower standard exists for the exact job type.
Generic compute markets can leak data and expectations
The biggest risk is treating a broad market protocol as if it solved product trust. Providers can return bad output, keep inputs, delay jobs or spoof usefulness. Payments and privacy need explicit design.
Because the NIP is unrecommended, a page that presents it as the current best path would mislead builders. It is more accurate to present it as an influential experiment and compatibility layer.
Read NIP-90 in the wild
NIP-90 describes data vending machines: signed requests, bids and results for jobs that can be done by services. AI tasks are the obvious example, but the pattern is broader.
The trust question is output provenance. Who did the job, what input did they see, what result came back, how was payment handled and can the result be verified?
What changes when you actually use it
For you, NIP-90: Data Vending Machines is felt at the moment value moves or appears to move. The interface may show a zap, offer, wallet connection, token, invoice or result, but the source terms kind 5001, kind 6001, kind 5000, kind 6000, kind 7000, kind 5 decide what can actually be proven. Read the money path before the visual reward path.
What changes for builders and operators
For builders, NIP-90: Data Vending Machines means separating money truth from social display. Budgets, invoices, mints, wallet services, receipts and settlement need their own status language. A delightful payment animation is harmless only after custody, limits and revocation are legible.
What the official file makes concrete
The official file is organized around Kinds, Rationale, Actors, Job request (kind:5000-5999), Encrypted Params, Job result (kind:6000-6999), Encrypted Output, Job feedback. Inspect kind 5001, kind 6001, kind 5000, kind 6000, kind 7000, kind 5, unrecommended, draft because these are the pieces most likely to surface as product behavior. Read it beside NIP-04, NIP-89 before treating it as isolated.
NIP-90: Data Vending Machines needs sharper warnings than a normal social feature. Custody, invoices, receipts, budgets, mints and settlement determine whether money really moved.
Where it breaks
The failure mode in NIP-90: Data Vending Machines is believing the social signal more than the payment proof. A zap can be visible while settlement is incomplete, a wallet connection can outlive trust, a mint can fail, and a listing can look professional without escrow or reputation.
Where this appears outside the markdown
In the ecosystem, NIP-90: Data Vending Machines sits near wallets, Lightning, Cashu, offers, receipts, jobs, goals or marketplaces. These features are exciting because value becomes visible inside social context, but they are also unforgiving. A page about value has to separate the social object from the financial fact before the design turns trust into decoration.
The nearby-standard trap
The nearby-standard trap in NIP-90: Data Vending Machines is calling every money-adjacent event a payment. Zaps, wallet connections, Cashu proofs, nutzaps, offers, orders, goals and data jobs each prove different things. Read NIP-04, NIP-89 before a UI turns a signal into an accounting claim.
Language that keeps the feature honest
Good product copy for NIP-90: Data Vending Machines names the money state. It separates request, invoice, payment, receipt, token, mint, budget, listing, order and settlement. That is how a delightful wallet or marketplace surface stays honest.
What this page does not promise
NIP-90: Data Vending Machines does not turn a social signal into settled money by itself. A zap, wallet connection, listing, token, receipt or job request can be displayed beautifully while custody, settlement, refund, invoice expiry or mint risk remain unresolved. Read NIP-04, NIP-89 before trusting any value flow that hides who controls funds or which proof actually exists.
Read it as a field test
Start NIP-90: Data Vending Machines with the money state, not the animation. Identify whether kind 5001, kind 6001, kind 5000, kind 6000, kind 7000, kind 5 represent a request, permission, invoice, token, receipt or listing. Then read the nearby standards and source links so custody, settlement, budget and proof are not collapsed into one cheerful payment label.
Where the standard earns trust
The source links give you places to test the interpretation in public: data-vending-machines repository, Simple DVM service provider, nostr-dvm on PyPI, NIP-90 job result confusion. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-90 source is the anchor for exact wording, and NIP-90 commit history shows how that wording moved over time. The strongest secondary clues here are data-vending-machines repository, Simple DVM service provider, nostr-dvm on PyPI. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-90: Data Vending Machines: first the human promise, then kind 5001, kind 6001, kind 5000, kind 6000, kind 7000, kind 5, then the implementation record, then the real-world failure case. That order keeps NIP-90 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- What is being proven: a request, invoice, payment, receipt, token, listing, wallet permission, mint promise or job result?
- Who can spend, revoke, refund, censor or lose the funds if the service disappears?
- Does the product separate social visibility from financial settlement before you trust the flow?
What to verify before you rely on it
- Find
kind 5001,kind 6001,kind 5000,kind 6000,kind 7000in the official file and check where the UI exposes the same concept. - Read NIP-04, NIP-89 as context before treating NIP-90 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-90: Data Vending Machines in that order: Official NIP-90 source for the current wording; NIP-90 commit history for the change record; data-vending-machines repository, Simple DVM service provider, nostr-dvm on PyPI for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
