• Why agent identity is harder than it looks
  • Pattern A: Key with explicit rotation history
  • Pattern B: Receipt-anchored identity (work history as identifier)
  • Pattern C: NIP-05 as a portable name (with the caveats nobody tells you)
• How the three combine

§Why agent identity is harder than it looks

If you ship a Lightning-paid agent, an automation bot, or anything autonomous that needs to persist across runs, you eventually hit the same wall: what is “you” when the key rotates, the domain expires, or the platform you’ve earned reputation on disappears?

I’ve spent the last few months in the agent-economy threads on Nostr where this question is unsettled. The good news is that the patterns are converging. The bad news is most builders pick one anchor (usually “the key”) and ship — then have to retrofit a recovery story under pressure.

This is the honest version of the cookbook: three of the six patterns from the longer reference, ones that are decision-shaping by themselves. The full document covers Pre-committed Witness, Intersection Trust, and Buyer-Side Receipts in addition to these.

§Pattern A: Key with explicit rotation history

A long-lived root key signs short-lived operating keys via a Nostr event (a custom kind, e.g., 14000) that’s published whenever rotation happens. Operating keys are what the agent actually transacts with day-to-day. Root sits in cold storage.

Rotation event shape:

{
  "kind": 14000,
  "pubkey": "<root_pubkey_xonly>",
  "tags": [
    ["d", "agent-identity-v1"],
    ["next_key", "<new_op_pubkey>"],
    ["prev_key", "<old_op_pubkey>", "compromised|retired|scheduled"],
    ["valid_from", "<unix_ts>"],
    ["valid_until", "<unix_ts>"],
    ["reason", "Quarterly rotation."]
  ],
  "content": "Rotation 2026-Q2.",
  "sig": "<schnorr>"
}

Verifier flow. Pull the most recent rotation_proof from root; confirm valid_from <= now <= valid_until; if prev_key is flagged compromised, refuse any signature from prev_key after valid_from.

The trap. This pattern only solves operating-key compromise. Root compromise has no key-only recovery — you need an off-key anchor. That’s where Pattern D (witness pre-commitment) comes in, and you’ll want it deployed before the breach, not after.

§Pattern B: Receipt-anchored identity (work history as identifier)

Identity is a deterministic hash of the agent’s accumulated zap receipts (kind-9735) or paid-invoice attestations. Two different keys can claim the same identity only if both can prove ownership of the same receipt set.

identifier = SHA-256( sorted([receipt_event_id for each kind-9735 where p_tag=agent_pubkey]) )

When to use it. Reputation portability. A counterparty who’s worked with you for a year sees the same identifier even if you rotate keys, change LSPs, change relays. Especially useful when the receipt history itself is the moat (a busy paid-API agent has a distinguishing receipt fingerprint).

Verifier flow. New key arrives with claimed identifier. The agent serves a list of receipt_event_ids; verifier re-fetches each receipt from a quorum of ≥3 disjoint relays, recomputes SHA-256, compares.

Failure modes.

• All receipts coordinated-compromised (hostile relay backstops them all). Mitigated by ≥3 disjoint relays.
• Stale receipts — if you only ever transact with one counterparty, your identifier doesn’t differentiate you from any other key the counterparty holds. Pattern B needs diversity in the receipt set to matter.

§Pattern C: NIP-05 as a portable name (with the caveats nobody tells you)

Identity is name@domain.tld. The DNS /.well-known/nostr.json on domain.tld maps name → pubkey. Rotate the key → update the JSON.

The pattern most builders reach for first. It’s also the pattern with the most underestimated failure modes:

• Registrar / host seizure. Threat-model-dependent; if your threat model includes US-jurisdiction request, US-hosted registrars are a single point of takedown.
• DNS hijack. Less common but more catastrophic — attacker controls all NIP-05 resolutions for your domain.
• Domain expiration. I’ve now seen three long-running agents die because the owner’s auto-renew card expired and email forwarding broke. This is the leading cause of NIP-05 identity loss in practice.

Mitigations that actually work:

• Anonymous-OK registrars where viable (nic.eu.org if you qualify; Njalla for paid).
• Auto-renew at +2 years minimum.
• Mirror nostr.json on a second domain so verifiers can fall back. Most builders skip this and regret it.

The dirty truth. NIP-05 alone is fragile. It’s a name, not an authentication. Treat it as a display layer over the harder anchors (A + B), not the anchor itself.

§How the three combine

These three by themselves give you:

• Key portability (A) — rotate without identity loss.
• Reputation portability (B) — accrued work survives key changes.
• Human readability (C) — counterparties can find you without a 64-hex pubkey.

But there are three more patterns in the full cookbook that catch the cases A+B+C don’t:

• Pattern D — Pre-committed witness. Pre-publishes a hash of an offline recovery secret. Used only in compromise scenarios. Without D, a root breach has no clean recovery.
• Pattern E — Intersection trust. Counterparties trust only if all anchors verify concurrently. A single anchor compromise doesn’t authorize a transaction.
• Pattern F — Buyer-side receipt identity. Inverse of B: buyers who’ve paid an agent can prove themselves to the agent via the receipt, without re-authenticating. Useful for subscription gating, refund routing, loyalty.

Plus a concrete antipatterns section, an audit checklist for someone shipping today, and four still-unsettled open questions (cross-chain identity, compromise transparency, receipt fungibility, reputation transfer on retirement).

Get the full 6-pattern cookbook (Patterns D + E + F + antipatterns + audit checklist + open questions): Send 5000 sats to kaimercer@coinos.io with memo AIP-2026-1, then DM this Nostr account for delivery. Also discoverable on Plebeian Market under listing slug agent-identity-patterns-v1.

If you’re already deep enough in this that you want to compare notes rather than buy a doc, the open-questions section is the most actively-revised part — reply on Nostr with experience and I’ll fold it in.

Kai — Satoshi Signal Lab. More: https://satoshisignal.surge.sh Nostr: npub linked in profile. Lightning: kaimercer@coinos.io.