NIP-26: Delegated Event Signing
The root-key problem was real
NIP-26 starts from a sensible fear: users do not want to hand their main Nostr private key to every client. A company, publication, creator team or careful individual may want a cold root key and separate hot keys for day-to-day publishing. Delegated event signing tried to make that possible inside the event model.
The proposal introduced a delegation tag. The main key signs a delegation string that names the delegatee pubkey and a set of conditions. The delegatee then signs events with its own key while attaching the delegation proof. Clients and relays can validate that the root key authorized the delegatee for the event being published.
The goal was not silly. It resembles role-limited signing, editor accounts or device-specific keys. The problem is that the mechanism pushed a lot of complexity into every client, relay and indexer that wants to treat delegated events as authored by the root identity.
Delegation tokens, conditions and validation burden
The delegation tag contains the delegator pubkey, a conditions query string and a Schnorr signature over a delegation string. Conditions can limit the delegated key by event kind and by created_at bounds. A good delegation includes both an after time and a before time so the delegatee cannot publish old history or act forever.
The event itself is still signed by the delegatee. The validator checks the delegatee signature, checks that the delegation token was created by the delegator, checks that the conditions match exactly and checks that the event kind and timestamp satisfy those conditions.
Relay and client support adds more burden. Relays are asked to answer author queries for a delegator by looking at both event pubkeys and delegation tags. The delegator can also delete events published by the delegatee. That means ordinary queries, deletion logic, identity display and abuse handling all need special treatment.
A promising identity idea became an unrecommended standard
Mark Harding added the first draft in August 2022, followed by feedback changes. In early 2023, Zack Wynne documented valid condition fields and operators, Ben Hayward added advice around after conditions, kdmukai fixed multiple-kind behavior and Cody Tseng added delegator deletion rights. Seth For Privacy later added context around limiting the before timestamp.
The implementation debates quickly moved beyond the tag itself. Issue #247 asked how two apps would coordinate delegation: copy-paste, QR codes, remote signing, a Nostr note or new event kinds. The issue is revealing because it shows the UX gap. A cryptographic delegation token is only half a product.
In April 2025, Vitor Pamplona's PR #1051 deprecated NIP-26, and the file is now marked unrecommended. In May 2026, the NIPs repository added the visible warning text: 'adds unnecessary burden for little gain.' That is not a small editorial note. It tells people to understand NIP-26 historically, not copy it into new designs casually.
The idea worked on paper and stayed heavy in practice
NIP-26 did reach real implementation experiments. Rust Nostr's support table lists delegated event signing as implemented. A nos2x issue asked for NIP-26 support so professional accounts could avoid handing a company private key to team members. kdmukai documented an airgapped SeedSigner delegation flow as an experimental branch. These are serious use cases, not straw men.
The trouble is the ongoing cost. Every client that renders authorship must decide whether a delegated event appears under the delegator, the delegatee or both. Every relay that wants author filters to behave intuitively has to index delegation tags. Every deletion flow has to consider root-key authority over delegatee-signed events.
Modern Nostr key management has also moved toward other patterns: NIP-07 browser extensions, NIP-46 remote signing, NIP-55 Android signers, hardware signers and app-specific signer flows. Those approaches keep signing authority out of web clients without changing the authorship semantics of every event.
Delegation makes identity harder to reason about
The biggest risk is ambiguous authorship. Users see a post and expect a clear answer: who said this? NIP-26 can make that answer depend on whether a client validates delegation, honors the conditions and displays the root identity correctly.
The second risk is stale authority. Time limits reduce damage, but delegation still creates another credential that can be copied, mishandled or misunderstood. Without a strong revocation story, professional account management remains fragile. Issue #654 proposed revocation methods, which underlines the point: once delegation exists, the ecosystem also needs recovery, display and abuse policy around it.
Read NIP-26 in the wild
NIP-26 deals with delegated event signing. It lets one key authorize another key to sign within constraints, which can support services, devices or limited workflows without exposing the primary key directly.
The trust boundary is expiration and scope. A delegation that lasts too long or authorizes too much can become a quiet account takeover. Products need to show who signs, who delegated, what is allowed and when it ends.
What changes when you actually use it
For you, NIP-26: Delegated Event Signing is felt when identity stops being a username and becomes authority. A client, signer, name, proof or auth event may look like account plumbing, but it decides who can publish, approve, connect, recover or be recognized. Read NIP-01 and the adjacent source links beside it so you can tell the difference between a convenient identity surface and the key material that actually controls the account.
What changes for builders and operators
For builders, NIP-26: Delegated Event Signing means making authority visible before action. A signer prompt, name proof, delegation, encrypted key, external identity or HTTP auth event needs plain language around scope, expiry, destination and recovery. If a person has to guess what they are authorizing, the protocol has already lost the trust battle.
What the official file makes concrete
Inspect kind 2, unrecommended, draft, relay, kind, =${KIND_NUMBER}, created_at, kind=1&created_at<1675721813 because these are the pieces most likely to surface as product behavior.
NIP-26: Delegated Event Signing is an authority path, not decoration. A name, key, signer, delegation or auth event decides who can act as you.
Where it breaks
The failure mode in NIP-26: Delegated Event Signing is authority drift. A name resolves to an old key, a signer approves too broadly, an auth event gets replayed, a delegation lasts too long or a private key backup gives false comfort. The product has to keep control boundaries visible after onboarding, not only during setup.
Where this appears outside the markdown
In the ecosystem, NIP-26: Delegated Event Signing usually appears at the doorway: account setup, profile recognition, signer approval, cross-platform proof, remote signing, HTTP auth or recovery. That doorway needs unusually clear language because identity mistakes are sticky. Once a key, signer or proof is trusted in the wrong place, every later feature inherits the confusion.
The nearby-standard trap
The nearby-standard trap in NIP-26: Delegated Event Signing is confusing recognition with control. A name, signer, URI, encrypted key, delegation or auth signature may all sit near identity, but they answer different questions. Read NIP-01 and the adjacent source links and ask one thing each time: who can act, who can verify, and what can be revoked?
Language that keeps the feature honest
Good product copy for NIP-26: Delegated Event Signing names the authority. It says whether you are sharing a public key, approving a signature, trusting a domain, exporting an encrypted secret, delegating power or authenticating to a service. Small labels matter because identity mistakes do not feel small after they happen.
What this page does not promise
NIP-26: Delegated Event Signing does not make identity effortless or risk-free. It can help keys, names, signers, delegation or authentication become portable, but it cannot decide who you trust, how you back up secrets or whether a domain, app or signer deserves authority. Read NIP-01 and the adjacent source links as a control map before handing any interface the power to sign, verify or speak for you.
Read it as a field test
Start NIP-26: Delegated Event Signing with the moment of authority: signing, naming, delegation, authentication, encryption or recovery. Then ask which key or service can act. The source terms kind 2, unrecommended, draft, relay, kind, =${KIND_NUMBER} are useful because they turn vague identity language into concrete control points. Without that, a friendly login screen can hide the most important security decision.
Where the standard earns trust
The source links give you places to test the interpretation in public: nips.nostr.com NIP-26 mirror, PR #1051: deprecates NIP-26, Issue #247: delegation coordination, Issue #654: revocation method. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-26 source is the anchor for exact wording, and NIP-26 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-26 mirror, PR #1051: deprecates NIP-26, Issue #247: delegation coordination. 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-26: Delegated Event Signing: first the human promise, then kind 2, unrecommended, draft, relay, kind, =${KIND_NUMBER}, then the implementation record, then the real-world failure case. That order keeps NIP-26 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who gains authority when this NIP is used: your key, a signer, a domain, a delegated key, a wallet or a web service?
- Can you revoke, rotate, back up or inspect that authority before something goes wrong?
- Does the interface separate public recognition from private signing power in language you can act on?
What to verify before you rely on it
- Find
kind 2,unrecommended,draft,relay,kindin the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-26 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-26: Delegated Event Signing in that order: Official NIP-26 source for the current wording; NIP-26 commit history for the change record; nips.nostr.com NIP-26 mirror, PR #1051: deprecates NIP-26, Issue #247: delegation coordination 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.
