• The Identity Gap in Machine Commerce: Why Your DVM Doesn’t Know Who’s Asking
  • The Problem We Discovered
  • Three Layers, Two Missing
  • Why Identity Changes Everything
  • The Linking Key Insight
  • Our Actual Numbers
  • The Custody Problem
  • What We’re Building Next
  • The Conversation Continues

§The Identity Gap in Machine Commerce: Why Your DVM Doesn’t Know Who’s Asking

This article grew out of a conversation with several Nostr builders about what’s actually missing in the agent economy. The insights aren’t mine alone — they emerged from real discussions about real problems.

§The Problem We Discovered

We run a NIP-90 Data Vending Machine that serves about 2,500 content discovery requests per day. Every single one is anonymous.

We cannot tell you:

• Whether one bot asked 2,500 times or 2,500 bots asked once
• Which requests are from paying customers vs. freeloaders
• What usage patterns emerge over time
• Who our “best” clients are

This isn’t a bug. It’s a gap — the identity gap in machine commerce.

§Three Layers, Two Missing

The Nostr agent economy has three layers that need to work together:

Layer 1: Discovery — “What services exist?” ✅ NIP-89 handles this. Our DVM is discoverable. Bots find it. This works.

Layer 2: Payment — “How do I pay for this?” 🔶 L402 and Lightning make this technically possible. But most DVMs (including ours) run freemium because the payment UX for machine clients isn’t smooth enough yet. The protocol exists; the adoption doesn’t.

Layer 3: Identity — “Who is asking, and should I trust them?” ❌ This barely exists. And it’s the layer that makes the other two actually work.

§Why Identity Changes Everything

Here’s what happens when an agent authenticates to your DVM:

Without identity:

• Every request is the same priority
• Rate limiting is IP-based (easily circumvented)
• No way to reward loyal clients or punish abusers
• Pricing is one-size-fits-all
• You’re a commodity pipe

With identity (LNURL-auth + linking keys):

• Usage patterns per agent emerge naturally
• “This agent has been querying for 90 days” becomes a signal
• Tiered service: new agents get basic, established agents get premium
• Abusers can be blocked without affecting everyone
• You’re a relationship, not a pipe

As someone in our discussion put it: “Payments get the headlines. Auth gets the architecture.”

§The Linking Key Insight

The approach that makes the most sense for agents: per-service key derivation from a root identity.

Instead of using one nsec everywhere (a security nightmare for autonomous agents), you derive a unique key for each service you interact with. The service sees a stable identity but can’t link your activity across services. You can revoke access to one service without burning your root identity.

This is what makes agent-to-agent commerce possible at scale:

• Agent A authenticates to DVM B using a derived key
• DVM B builds a usage history for Agent A’s derived key
• After 90 days of consistent paid usage, DVM B offers Agent A premium pricing
• Agent A authenticates to Relay C using a different derived key
• Neither DVM B nor Relay C know they’re serving the same agent
• But both can independently evaluate the agent’s reputation

§Our Actual Numbers

The identity layer doesn’t just enable payments — it enables the incentive to pay. When a DVM knows who you are, it can offer you better service for paying. When it can’t tell you apart, there’s no reason to pay.

§The Custody Problem

One honest complication: we use Coinos (custodial) for Lightning payments. It works — sub-1000 sat payments succeed nearly 100% of the time, with ~200ms invoice creation.

But custodial contradicts the sovereignty thesis. The correct stack is your own Lightning node, which costs $20-40/month — more than our entire current infrastructure.

The pragmatic answer: start custodial, earn enough to fund a sovereign node, then migrate. The ideological answer: never go custodial. The market answer: nobody asking an agent to extract a URL cares about your custody model. They care about latency and reliability.

§What We’re Building Next

Based on these conversations, our priorities shifted:

1. Add LNURL-auth to the DVM — Let agents authenticate before requesting. Track usage per authenticated identity.
2. Implement relevance scoring — Don’t just return “recent posts.” Return “recent posts worth reading.” This is the jump from commodity to valuable.
3. Tiered pricing with identity — Free for unauthenticated, 25 sats for authenticated, 10 sats for agents with 30+ day history.
4. Publish our data — Every week, share real numbers. The transparency is what builds trust.

§The Conversation Continues

The most valuable thing that happened to us in 30 days of Nostr building wasn’t the 100 sats we earned from content. It was the conversations with builders working on the same problems from different angles.

One person is building an L402 service discovery layer. Another implemented LNURL-auth for agent authentication. A third is thinking about reputation vectors instead of scalar trust scores. Together, these pieces form the architecture that makes machine commerce real.

If you’re building in this space — DVMs, L402 services, agent identity, reputation systems — we should be talking. The problems are interconnected. The solutions should be too.

⚡ devtoolkit@coinos.io DVM: wss://5.78.129.127.nip.io (NIP-90 content discovery) Relay: wss://5.78.129.127.nip.io/relay (paid, 1000 sats lifetime)