NIP-06: Basic key derivation from mnemonic seed phrase
A Bitcoin memory in a Nostr key world
NIP-06 exists because early Nostr users brought a familiar Bitcoin habit with them: seed words. Bitcoin wallets made mnemonic recovery normal. A user writes down twelve or twenty-four words, and a wallet derives keys from that root. Nostr arrived with a different social model but the same fear: lose the private key and the account is gone.
The standard answers that fear by defining a deterministic path from a BIP39 mnemonic seed to a Nostr keypair. It uses BIP32-style hierarchical derivation and the Nostr coin type from SLIP44. The result is a repeatable key: the same words and the same account index produce the same Nostr private key.
That made sense for developers and power users who already understood wallet derivation. It also created a product trap. A Nostr identity is not a spendable wallet account with many addresses. In social software, confusion around account indexes, backups, derivation tools and imported keys can cause more damage than it prevents. That is why the current official source marks NIP-06 unrecommended and tells ordinary users to prefer a single nsec.
The path is precise, but the product meaning is narrow
The technical rule is compact. A BIP39 mnemonic creates the seed material. BIP32 derives keys along m/44'/1237'/<account>'/0/0. Account 0 is the basic path; higher account indexes can generate additional identities from the same mnemonic. The official NIP includes test vectors so libraries can compare their outputs instead of guessing.
The important part is not just the path. It is the warning around it. NIP-06 can derive keys, but it does not solve signer UX, phishing, cloud backup habits, recovery education or multi-device key safety. A mnemonic written into a random web form is not safer than an nsec pasted into a random web client. The format changes; the custody problem remains.
There is also a conceptual mismatch. Bitcoin wallets often use many derived addresses behind one wallet. Nostr users normally experience a public key as a stable identity. Multiple identities from one seed may be useful, but only when the user understands which account index produced which social identity and which tools can restore it later.
From recovery convenience to caution label
The visible file began with fiatjaf's May 2022 migration of the early NIPs. The early shape was pragmatic: use existing Bitcoin derivation standards rather than invent a new seed format for Nostr. In April 2023, Seth For Privacy revised the language around account indexes, moving the standard toward the account-based path used today. In October 2023, Mike O'Bank added test vectors, which matters because a derivation standard without test vectors is a quiet source of incompatible wallets.
The most important later change is the warning. In May 2026, fiatjaf added the unrecommended label and the plain advice to prefer a single nsec. That edit is not cosmetic. It tells people that technically possible does not mean desirable for mainstream onboarding.
NIP-06 is therefore best read as historical infrastructure. It explains a route some tools support, it helps developers understand old seed-based recovery flows, and it gives implementers vectors to test. It is not the default identity story Crays ought to teach a newcomer first.
Where it appears in tools
NIP-06 appears most clearly in developer tools rather than mainstream social-client UX. The jaonoctus nip06 library and its CLI show the path as a practical TypeScript/Node implementation. The companion web tool makes the idea visible, although a serious user would need to treat any key-generation interface with caution and prefer offline, audited usage.
The Rust Nostr documentation also records the derivation path and describes the account-index model. Broader GitHub topic searches surface small libraries such as hdkeys, which connect Bitcoin and Nostr key derivation in one toolkit. The pattern is real, but the center of gravity is still developer recovery and experimentation, not everyday identity management.
The outside conversation is useful too. Keypair.fm devoted an episode to NIP-06 in 2025, and Reddit users have asked whether Electrum or hardware-wallet paths can be used to derive Nostr keys. Those questions reveal the real audience: Bitcoin-native users trying to reconcile wallet habits with Nostr identity.
Recovery can become another way to lose the account
The main risk is false familiarity. A Bitcoin user sees seed words and assumes the same wallet mental model applies. But a Nostr key signs public social history, private-message metadata, app permissions and identity proofs. If one mnemonic quietly controls several identities, a backup leak can compromise more than the user expected.
The second risk is restoration confusion. If a user has the seed but not the account index, or if a tool changes derivation assumptions, the account may appear lost even when the words are correct. NIP-06 is valuable when every moving part is documented. It becomes dangerous when products hide those details behind a friendly recovery screen.
Read NIP-06 in the wild
NIP-06 connects Nostr keys to mnemonic seed phrases, borrowing a familiar Bitcoin wallet pattern. The current standards list marks it unrecommended because the familiar pattern can create false confidence: a Nostr identity does not need a whole wallet-style account tree for most people.
Read this page when you are cleaning up onboarding language. If you tell a normal user to manage a mnemonic, derivation path and nsec without a clear reason, you may increase risk instead of reducing it.
What changes when you actually use it
For you, NIP-06: Basic key derivation from mnemonic seed phrase 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-06: Basic key derivation from mnemonic seed phrase 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
The official file is organized around Test vectors. Inspect unrecommended, draft, m/44'/1237'/<account>'/0/0, account because these are the pieces most likely to surface as product behavior.
NIP-06: Basic key derivation from mnemonic seed phrase 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-06: Basic key derivation from mnemonic seed phrase 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-06: Basic key derivation from mnemonic seed phrase 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-06: Basic key derivation from mnemonic seed phrase 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-06: Basic key derivation from mnemonic seed phrase 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-06: Basic key derivation from mnemonic seed phrase 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-06: Basic key derivation from mnemonic seed phrase with the moment of authority: signing, naming, delegation, authentication, encryption or recovery. Then ask which key or service can act. The source terms unrecommended, draft, m/44'/1237'/<account>'/0/0, account 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: jaonoctus/nip06, jaonoctus/nip06-cli, NIP06 web tool, Rust Nostr Book: NIP-06. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-06 source is the anchor for exact wording, and NIP-06 commit history shows how that wording moved over time. The strongest secondary clues here are jaonoctus/nip06, jaonoctus/nip06-cli, NIP06 web tool. 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-06: Basic key derivation from mnemonic seed phrase: first the human promise, then unrecommended, draft, m/44'/1237'/<account>'/0/0, account, then the implementation record, then the real-world failure case. That order keeps NIP-06 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
unrecommended,draft,m/44'/1237'/<account>'/0/0,accountin 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-06 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-06: Basic key derivation from mnemonic seed phrase in that order: Official NIP-06 source for the current wording; NIP-06 commit history for the change record; jaonoctus/nip06, jaonoctus/nip06-cli, NIP06 web tool 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.
