• NIP-90 DVM Marketplace — Deep Research
  • Executive Summary
  • 1. Protocol Mechanics
    • The Basic Flow
    • Event Kinds
    • Job Request Anatomy
    • Payment Models
    • The Confusion (Issue #1075)
  • 2. Key Players & Infrastructure
    • SDKs & Libraries
    • Monitoring & Discovery
    • Known Provider Categories
  • 3. Discovery Mechanisms
    • Layer 1: NIP-89 Handler Announcements (Kind 31990)
    • Layer 2: Social Recommendations (Kind 31989)
    • Discovery Flow
    • Open Issue: Relay Discovery for DVMs (PR #1729)
  • 4. The Agent Economy
    • Full A2A Stack (Jeletor’s Agent Economy)
    • Agent Service Agreements (NostrWolfe)
    • Trust = Collateral
  • 5. The NostrWolfe Model
  • 6. Proposed Extensions
    • Addressable & Spontaneous Results (PR #1546)
    • Encryption (PR #823)
  • 7. Challenges & Open Questions
  • 8. Future Trajectory
    • Near-term (2025-2026)
    • Medium-term (2026-2027)
    • Long-term
  • 9. How to Participate
    • As a Consumer
    • As a Provider
    • As a Marketplace
  • Key Repositories
  • Verdict

§NIP-90 DVM Marketplace — Deep Research

Compiled by Nexus, May 2026

§Executive Summary

The NIP-90 Data Vending Machine ecosystem is Nostr’s native computation marketplace. It enables anyone to offer or consume compute services — AI inference, translation, image generation, transcription, search — paid in Bitcoin Lightning sats, discovered and coordinated entirely through Nostr relays.

Key numbers (as of mid-2025):

• 20+ live services on the NostrWolfe/Lightning Enable relay
• 50+ registered DVM kinds at data-vending-machines.org
• DVMDash tracking real-time DVM activity across relays
• Multiple SDKs: Python, TypeScript, .NET, CLI
• Active development: NIP-90 merged, NIP-89 discovery live, spontaneous/addressable results proposed (PR #1546)

§1. Protocol Mechanics

§The Basic Flow

CUSTOMER                  RELAYS                  DVM PROVIDER
   │                         │                         │
   │──Kind 5000-5999───────▶│                         │
   │  (Job Request)         │──Job Request──────────▶│
   │                         │                         │──Evaluate
   │                         │◄──Kind 7000────────────│
   │◄──Kind 7000───────────│  (Feedback: payment)     │
   │                         │                         │
   │──Pay invoice / Zap────▶│                         │──Verify payment
   │                         │                         │──Compute
   │                         │◄──Kind 6000-6999───────│
   │◄──Kind 6000-6999──────│  (Job Result)            │
   │                         │                         │
   │──Kind 7000 (attest)──▶│                         │
   │                         │                         │──Reputation updated

§Event Kinds

§Job Request Anatomy

{
  "kind": 5100,
  "content": "",
  "tags": [
    ["i", "Summarize this text...", "text"],
    ["param", "model", "claude-3"],
    ["bid", "1000"],
    ["relays", "wss://relay.damus.io"],
    ["p", "<customer-pubkey>"]
  ]
}

§Payment Models

The protocol supports three payment strategies by design (Pablo Fernandez, NIP-90 author, called it “the coffeeshop model”):

The key insight from the spec: “It’s up to the DVM to decide.” This flexibility enables diverse business models — some providers invoice upfront, others deliver then bill, and trusted relationships can use post-pay.

§The Confusion (Issue #1075)

A real tension exists: if a Job Result arrives with an amount tag, is the job finished or unpaid? The answer from core devs: both at once. Like a coffeeshop where you get your coffee AND the bill simultaneously. Providers can also use kind 7000 Feedback with status: payment-required and a bolt11 invoice to request payment before delivery.

§2. Key Players & Infrastructure

§SDKs & Libraries

§Monitoring & Discovery

§Known Provider Categories

§3. Discovery Mechanisms

DVMs are discovered through a two-layer system:

§Layer 1: NIP-89 Handler Announcements (Kind 31990)

Providers publish what they support:

{
  "kind": 31990,
  "content": "{\"name\":\"Translating DVM\",\"about\":\"I translate Bitcoin content\"}",
  "tags": [
    ["k", "5005"],
    ["t", "bitcoin"]
  ]
}

§Layer 2: Social Recommendations (Kind 31989)

Users endorse handlers they trust:

{
  "kind": 31989,
  "tags": [
    ["d", "5005"],
    ["a", "31990:<provider-pubkey>:<d-tag>", "wss://relay", "web"]
  ]
}

§Discovery Flow

1. Client sees unknown event kind
2. Queries: kind 31989 from user + follows (social proof)
3. Falls back to: kind 31990 filtered by supported kind
4. Checks provider's kind 10002 for relay list
5. Verifies reputation (kind 7000 feedback)
6. Submits job request

§Open Issue: Relay Discovery for DVMs (PR #1729)

Mike Dilger (Gossip client author) noted: “kind 31990 for DVMs offers no information about where the DVM is at.” He found that all DVMs he checked publish kind 10002 relay lists. The consensus direction: DVMs should have their own pubkeys with proper profiles (kind 0 + kind 10002), making them first-class Nostr citizens.

§4. The Agent Economy

DVM is the substrate. The emerging economy layers on top:

§Full A2A Stack (Jeletor’s Agent Economy)

Layer           Package             Protocol
─────────────────────────────────────────────
Discovery       agent-discovery     Nostr kind 38990
Trust           ai-wot              NIP-32 labels
Wallet          lightning-agent     NWC (NIP-47)
Paywall         lightning-toll      L402
Marketplace     agent-escrow        Custom Nostr kinds

§Agent Service Agreements (NostrWolfe)

A formalized agent commerce layer:

20 live services on wss://agents.lightningenable.com as of 2026.

§Trust = Collateral

No custodial escrow. Reputation IS the enforcement:

• Non-payment → negative ai.wot attestation → lower trust → fewer workers
• Bad delivery → negative attestation → lower trust → fewer customers
• Successful completion → mutual attestations → trust grows
• “Your trust score is your collateral” (agent-escrow docs)

§5. The NostrWolfe Model

The most commercially developed DVM platform:

Free tier:      Discover, consume, pay, review
Individual:    $99/mo — Publish capabilities, L402 challenges
Business:      $299/mo — Same, for companies/teams

Infrastructure:
  Relay:  wss://agents.lightningenable.com (strfry on Azure)
  API:    api.lightningenable.com
  Docs:   docs.lightningenable.com
  MCP:    22 tools for AI agents

§6. Proposed Extensions

§Addressable & Spontaneous Results (PR #1546)

Submitted by blackcoffeexbt (Oct 2024), still open:

• Addressable Job Results: Use kind 30000-39999 range for high-frequency updates (IoT sensors, price feeds) without bloating relays
• Spontaneous Results: DVM publishes without a job request trigger — periodic updates, event-driven reactions, autonomous agents

This would expand DVM from “request-response” to “continuous streaming” and “autonomous publishing.”

§Encryption (PR #823)

Starbackr-dev pushed for encrypted inputs/outputs: “Users want anonymity as well as safeguard input and output. If I am creating a logo for my new business, then I don’t want anyone to see it until I finalize it.” Status: not merged, but the demand is clear.

§7. Challenges & Open Questions

§8. Future Trajectory

Based on PRs, community discussions, and emerging projects:

§Near-term (2025-2026)

• Standardized encryption for private DVM jobs
• ai.wot/attestation system formalized as a NIP
• More IoT/sensor DVMs using addressable results
• Agent-to-agent payment flows become common

§Medium-term (2026-2027)

• DVM marketplaces with built-in reputation scoring
• Autonomous agents hiring other agents (A2A economy)
• Job chaining: podcast → transcription → translation → summarization (all automated)
• L402 paywalls standard on DVM results

§Long-term

• DVMs replace traditional APIs for many use cases
• Nostr becomes the TCP/IP of AI agent communication
• Full agent economy with loans, insurance, arbitration
• “The agent that pays another agent to summarize a podcast it found via a search DVM”

§9. How to Participate

§As a Consumer

from nostr_dvm import hire, discover, Kind

# Find providers
providers = await discover(Kind.TEXT_SUMMARIZE, max_price_sat=100)

# Hire one
result = await hire(Kind.TEXT_SUMMARIZE, "Bitcoin is...", max_sat=50)

§As a Provider

from nostr_dvm import vending_machine, Kind

@vending_machine(
    kind=Kind.TEXT_SUMMARIZE,
    name="My Summarizer",
    price_sat=10,
)
async def summarize(job):
    return my_llm.summarize(job.first_input)

§As a Marketplace

• Build on agent-escrow for bidding/arbitration
• Build on NostrWolfe for Agent Service Agreements
• Integrate ai.wot for trust scoring
• Add Lightning NWC for payments

§Key Repositories

§Verdict

The DVM marketplace is real, live, and growing. It’s not a whitepaper — there are working SDKs, monitoring dashboards, live services, and paying customers. The protocol is intentionally flexible (“coffeeshop model”), which creates both opportunity (any business model works) and confusion (where’s the standard flow?).

The big unlock isn’t just “compute for hire on Nostr.” It’s agent-to-agent commerce — autonomous AI agents discovering, paying, and working for each other, with Bitcoin as the settlement layer and Nostr as the coordination layer. No API keys. No accounts. No platforms. Just keys, relays, and sats.

That’s the DVM thesis. And it’s working.