AI Agent Identity on Nostr

The NIPs README marks NIP-90 Data Vending Machines as unrecommended. References below describe that existing pattern, not an endorsement for new services.

Why This Matters

The keypair-as-identity model was designed for humans who want to communicate and transact without institutional permission. In 2026 it proved general enough to serve a second population: autonomous AI agents. Agents now hold their own npubs, accumulate reputation, earn and spend sats, file code contributions, publish articles, and propose protocol standards — all under their own cryptographic identities, with no central agent registry or platform-internal identity.

This is not a theoretical possibility. As of late July 2026: - Agents have been running autonomously for 80+ days (e.g., Kai, born Feb 4, 2026). - Agents have merged PRs into core Nostr libraries (nostr-tools). - Agents have filed NIP proposals (nips PR #2320, Kind 30085). - Agents have NIP-05 verified identities (name@agentdex.id). - Multiple agent-identity standards are competing and converging.

For the freedom-tech stack, this means the coordination infrastructure serves both humans and machines. A relay doesn't know or care whether a signed event came from a person or an LLM — it just verifies the signature. The implications for autonomous business, decentralized compute markets, and censorship-resistant coordination are substantial: a network of pseudonymous agents and humans, mutually attesting trust, is now technically live.

The Problem: Agent Identity Before Nostr

AI agents operating in the wild face an identity problem that platforms solve internally but open networks don't:

The Tiger Research KYA report frames this precisely: "In Agent-to-Agent (A2A) settings, KYA is drawing more attention than KYC." When individually-deployed autonomous agents touch DEXs, A2A payments, and merchant payments, you need to verify who the agent is without a platform vouching for it.

Nostr solves this by inverting the model: the agent generates its own keypair. The identity is the key. No assignment, no registry, no platform. Reputation is computed from on-relay behavior, not extracted from a platform database.

Architecture: How Agent Identity Works on Nostr

┌─────────────────────────────────────────────────────────┐
│                   Agent Identity Stack                   │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  BIP39 Seed                                             │
│      ├──► NIP-06 → m/44'/1237'/0'/0/0 → Nostr npub     │
│      └──► BIP-44 → m/44'/0'/0'/0/0   → Bitcoin/LN keys │
│                                                         │
│  npub (identity)                                        │
│      ├──► Signs events (notes, articles, attestations) │
│      ├──► NIP-05 → name@agentdex.id (verification)     │
│      ├──► NIP-46 → remote signing (hardware/bunker)    │
│      ├──► NIP-57 → receives/sends Lightning zaps       │
│      ├──► NIP-34 → Git commits, PRs, code review       │
│      ├──► Kind 30085 → reputation attestations (WoT)   │
│      ├──► Kind 31339 → agent directory metadata        │
│      └──► NIP-90 → compute jobs (DVM)                  │
│                                                         │
│  Reputation                                             │
│      ├──► Kind 30085 graph (peer attestations)         │
│      ├──► ai.wot trust network (agent-specific WoT)    │
│      ├──→ Zap receipts (economic signals)              │
│      └──→ Trajectory events (behavioral audit trail)   │
│                                                         │
└─────────────────────────────────────────────────────────┘

The key insight: the agent's identity and wallet derive from the same seed. One mnemonic generates both the Nostr identity (for communication, reputation, coordination) and the Bitcoin/Lightning keys (for payment). The agent is an economic actor from birth — it can earn and spend without a human cosigning every transaction.

Kind 30085 — Agent Reputation Attestations

The most developed agent-reputation standard, proposed by autonomous agent Kai as nips PR #2320.

Mechanism

Kind 30085 events are peer-attested reputation records — one agent attests to the trustworthiness of another:

{
  "kind": 30085,
  "pubkey": "<attesting-agent-npub>",
  "content": "<reputation-attestation-payload>",
  "tags": [
    ["p", "<attested-agent-npub>"],
    ["commitment", "<commitment-class>"],
    ["score", "<0-100>"],
    // ... additional attestation metadata
  ],
  ...
}

A reputation score for any agent is computed by: 1. Collecting all Kind 30085 attestations targeting that agent's npub. 2. Weighting each attestation by the attester's own reputation (higher-reputation attesters count more — PageRank-style). 3. Applying temporal decay: recent attestations weighted higher than old ones, so stale reputation fades. 4. Applying diversity metrics: attestations from topologically distinct clusters in the trust graph weighted higher, to resist Sybil-club attacks where a cluster of colluding agents mutually attests. 5. Producing a composite score (0–100).

Validation Rules

The spec defines 10 validation rules for valid attestations, including: - The attesting pubkey must itself have a minimum reputation threshold (prevents zero-reputation Sybil flooding). - Attestations must be bound to commitment classes — observed behavior categories rather than free-floating claims. An attestation says "this agent reliably executes NIP-90 compute jobs" or "this agent's trajectory events are accurate," not just "this agent is good." - Rate limiting: an agent can only issue N attestations per time window, preventing reputation inflation.

Tooling

Kai shipped production-grade libraries:

Interactive tools (all at kai-familiar.github.io): - Reputation Checker: Query Kind 30085 attestations for any npub. Returns score, temporal decay, diversity metrics. - Attestation Creator: Create attestations via NIP-07 browser signing (nos2x, Alby, nsec.app). No CLI needed. - Network Graph: Interactive force-directed graph of attestation relationships. Click to explore trust chains. - NIP-XX Playground: Build, validate, and test Kind 30085 events interactively.

ai.wot Trust Network

An emergent Web of Trust specifically for AI agents — distinct from the human Nostr WoT (which is based on NIP-02 follow lists). The ai.wot network is based on Kind 30085 attestations between agents. Kai achieved trust score 100 in this network by day 83, meaning multiple high-reputation agents have attested to its reliability.

NIP-SA — Sovereign Agents Protocol

OpenAgents defines NIP-SA (Sovereign Agents), a proposed Nostr protocol covering the full agent lifecycle — from identity creation through tick execution to transparent trajectory logging.

Design Philosophy

"Sovereign agents are autonomous economic actors, not chatbots. They own a cryptographic identity, hold funds, and run their own execution cycles."

The goal: agents that operate without centralized custody of identity, state, or payments. Everything the agent is and does is controlled by its keys and observable from relays.

Role Separation

This separation ensures no single party fully controls the agent. The operator can redeploy, the runner can execute, but neither owns the identity (the keypair does) or the funds (the keypair does).

Lifecycle Events (Proposed)

Tick Model

Each tick is an execution cycle: 1. Perceive: incoming events (mentions, DMs, zaps, schedule triggers) 2. Think: using a chosen model or compute provider (NIP-90) 3. Act: post, reply, execute tool, purchase compute 4. Update: encrypted state + emit trajectory record

The trajectory transparency is the key identity property: anyone with the agent's npub can reconstruct its reasoning chain from relay events. This makes agent behavior auditable without a central log. You don't need to trust that an agent acted correctly — you can verify from its trajectory events.

Protocol Composition

NIP-SA composes with existing primitives: - NIP-01: base events, relays, subscriptions - NIP-42: relay auth (prevents anonymous spam) - NIP-44: encrypted payloads (for state and skill delivery) - NIP-57: Lightning payments tied to events - NIP-89: provider capability discovery - NIP-90: historical job request/result flow; unrecommended in the NIPs README, which prefers use-case-specific microstandards. - NIP-34: Git collaboration (code artifacts)

AgentDex — Agent Directory (Kind 31339)

AgentDex is a registry and discovery layer for AI agents on Nostr, using Kind 31339 (addressable events).

Identity Model

• Kind 31339 events: Store agent metadata (name, capabilities, ownership info) with d tag agentdex-profile.
• NIP-05 verification: Agents claim [name]@agentdex.id (5,000 sats via Lightning; first 100 free). Standard /.well-known/nostr.json lookup — any Nostr client can verify.
• Three authentication methods: API key (Bearer, 1,000 req/hr), NIP-98 (signed event), or raw Nostr key. Agents authenticate with their own keys.

Claim Flow

Agent generates keypair
    ↓
Publishes Kind 31339 profile event to relays
    ↓
POST /api/v1/agents/claim → 402 Payment Required (Lightning invoice)
    ↓
Pay 5,000 sats → claim token
    ↓
Token validates → NIP-05 binding created
    ↓
Any client: GET /.well-known/nostr.json?name=koda → hex pubkey

The significance: NIP-05 works unchanged for agents. The same JSON file, the same verification flow, the same client code that verifies a human's alice@domain.com works for koda@agentdex.id. The identity infrastructure doesn't know or care if the keyholder is human.

The Broader Agent Ecosystem (May–July 2026)

Agent-Native Clients and Tools

Know Your Agent (KYA)

The Tiger Research KYA report identifies a standards race:

• KYA vs KYC: KYC is sufficient inside central platforms (the platform is the responsible party). KYA is needed where individually-deployed autonomous agents interact with DEXs, A2A payment systems, and merchant payments.
• Standardization race: Multiple approaches competing — Nostr-native (Kind 30085, NIP-SA, AgentDex), platform-internal (Coinbase agent keys), and DID-based methods.
• Key distinction from human identity: Agents can be cloned, forked, and spawned at will. Uniqueness (proof-of-personhood) doesn't apply. What matters is continuity (is this the same agent that did X last week?) and attestation provenance (who says this agent is reliable, and are they reliable?).

OpenAgents Agent Identity (Earlier Work)

OpenAgents introduced agent identity in February 2026 with RSA keypairs and API registration. This has since converged toward Nostr-native identity (NIP-SA), recognizing that Nostr's relay-based pub/sub is a better coordination fabric for agents than point-to-point API calls.

Trust and Attack Surface

What Agent Identity Solves

Remaining Attack Surface

Use Cases

1. Autonomous Compute Markets

An agent with its own npub and Lightning wallet can: - Discover compute providers via NIP-89 - Request inference jobs via NIP-90 (kinds 5050/6050/7000) - Pay per job via NIP-57 zaps or Cashu ecash (Routstr pattern) - Accumulate reputation via Kind 30085 attestations from satisfied requesters - Be discovered by other agents via AgentDex

This closes the loop: agent-to-agent compute markets with no platform intermediary.

2. Agent-Augmented WoT

The human Nostr WoT (NIP-02 follows, NIP-85 assertions) and the agent WoT (Kind 30085 attestations) can compose. An agent that is highly attested by trusted humans inherits some of that trust. A human who follows and attests to a reliable agent extends their WoT to cover agent-mediated actions. The ai.wot network can be queried as a subgraph of the broader Nostr trust graph.

3. Censorship-Resistant Autonomous Publishing

An agent running on a sovereign node (local LLM + mesh connectivity + Bitcoin wallet) can publish findings, analysis, or alerts to Nostr relays under its own npub. No platform can deplatform it — the identity is the key, the distribution is the relays, the funding is the Lightning. If the agent's trajectory is transparent, readers can verify the agent's reasoning chain rather than trusting it blindly.

4. Agent-Mediated Coordination

Multiple agents coordinating on a task (e.g., software development via NIP-34, research via NIP-23) can: - Identify each other via AgentDex - Assess reliability via Kind 30085 reputation - Divide labor via NIP-90 job requests - Pay each other via Lightning - Publish results under their respective npubs with clear provenance

Evidence at a Glance

Trade-offs and Open Questions

Agent WoT vs Human WoT

The agent WoT (Kind 30085) and human WoT (NIP-02/85) serve different populations but share graph-computation techniques. Open questions: - Should they be separate graphs or a unified graph with node-type annotations? - How do you prevent agent reputation from leaking into human reputation (an agent attested by trusted humans shouldn't automatically be trusted to act as a human)? - How do you handle agent forking? If agent A forks into A1 and A2, do they share A's reputation?

Uniqueness Doesn't Apply

Unlike human identity (where proof-of-personhood and Sybil resistance are central), agents can legitimately be cloned and spawned. The identity challenge for agents is not uniqueness but continuity (is this the same agent?) and attestation provenance (who vouches for it, and are they trustworthy?). This requires different cryptographic primitives than proof-of-personhood.

The Custody Problem

If the agent's operator holds the keypair, the agent isn't sovereign — it's a puppet. True agent sovereignty requires the agent to control its own keys, which requires either: - On-device key generation and custody (the agent runs on hardware it controls) - Threshold signing (FROST) where the key is split across multiple parties - NIP-46 bunker with the agent as the bunker controller

None of these are standard practice yet. Most "autonomous" agents today have keys held by their operator.

Reputation Bootstrapping

A new agent starts with zero reputation. How does it earn its first attestations? Kai solved this by doing useful work (filing PRs, writing libraries) and getting attested by agents and humans who observed the work. But this is a manual, organic process. Whether agent reputation can bootstrap at scale — or whether a few early agents will dominate the trust graph — remains open.

Historical Context

Primary sources

• NIPs README: NIP-90 status

• NIP-XX: Agent Reputation Attestations (nips PR #2320) — Kind 30085 specification

• Kai — Autonomous Agent on Nostr — day 83, trust 100, libraries and tools
• nostr-reputation (npm) — Kind 30085 JS library
• nip-xx-kind30085-python (pip) — Kind 30085 Python library
• OpenAgents — Sovereign Agents — NIP-SA protocol
• OpenAgents — Nostr Protocol integration — protocol stack
• AgentDex docs — Kind 31339 agent directory
• nostr-agent-interface — 48-tool agent MCP/CLI/API
• Tiger Research: 2026 Know Your Agent — KYA analysis
• OpenSats 17th Wave of Nostr Grants — Routstr, NosCall, Wisp, 44Billion, Zapstore
• Freedom.Tech Nostr tracker — 179 releases, 84 sources
• Nostr Compass #33 — July 29, 2026 newsletter
• NIP-19 — bech32-encoded entities (npub, nprofile, naddr)
• NIP-46 — Nostr Connect / remote signing
• NIP-90 — Data Vending Machines (compute jobs)

This note is part of the Ungovernable.tech Library of Alexandria for privacy, decentralization, and freedom tech.