1 Overview
This NIP is unrecommended. The source spec states the reason in one line: prefer a single nsec. Deriving a key from a mnemonic adds a second secret format to protect and does not remove the need to guard the private key itself. New clients should generate and store one private key directly, encode it with NIP-19, and encrypt it at rest with NIP-49 instead of relying on this derivation scheme.
A Nostr identity is one keypair on the curve secp256k1. NIP-01 does not say how a client creates that keypair. A client can generate random bytes directly, but a raw private key is hard for a person to write down, read aloud, or check for copy errors.
This NIP defines an optional way to derive a Nostr keypair from a human-readable backup phrase. It reuses two existing Bitcoin standards instead of inventing a new one. BIP39 turns a list of ordinary words into a binary seed. BIP32 turns that seed into one or more keypairs, following a fixed path.
Because the path is fixed, every client that follows this NIP derives the exact same keypair from the exact same mnemonic. This makes one mnemonic portable between different Nostr apps and wallets.
2 Mnemonic to Seed (BIP39)
A BIP39 mnemonic is a sequence of words drawn from a fixed 2048-word list. The words encode random entropy plus a checksum, so a client can detect a mistyped or mistranscribed word. A mnemonic is normally 12 or 24 words long.
BIP39 defines a function that turns the mnemonic string into a 512-bit binary seed. This NIP does not restate that function; it only reuses its output as the input to BIP32 derivation.
The source spec does not say whether the BIP39 seed function should use its optional passphrase (sometimes called a "25th word") or leave it empty. It also does not say whether the mnemonic must be normalized before hashing. Most known implementations use an empty passphrase and standard NFKD normalization, but this NIP does not state either rule explicitly.
3 Derivation Path (BIP32)
BIP32 turns one seed into a tree of keypairs. A path selects one keypair from that tree. This NIP fixes the path to:
m/44'/1237'/<account>'/0/0
The number 1237 is Nostr's registered coin type on SLIP44, the shared registry that BIP32-based wallets use to avoid path collisions between different coins and networks.
| Segment | Value | Meaning |
|---|---|---|
| purpose' | 44' | Fixed. Marks this as a BIP44-style path. |
| coin_type' | 1237' | Fixed. Nostr's SLIP44 coin type. |
| account' | <account>' | Starts at 0. Increment it to derive another, independent keypair from the same mnemonic. |
| change | 0 | Fixed at 0. Not hardened. |
| address_index | 0 | Fixed at 0. Not hardened. |
The trailing ' marks hardened derivation. A hardened child key needs the parent's private key to compute; it cannot be derived from the parent's public key alone. The purpose, coin_type, and account segments are hardened. The change and address_index segments are not, but this NIP fixes both at 0.
A basic client can use account 0 and derive a single key. A client that needs more than one identity can increment account to derive practically unlimited further keys, all from the same mnemonic. Other kinds of clients may still use other, non-standard derivation paths for their own purposes; this NIP only fixes the default.
4 Worked Example - Test Vectors
The source spec gives two full test vectors. An implementation can run its own mnemonic-to-keypair code against these values to confirm it matches other implementations bit for bit.
Neither test vector states which account index or BIP39 passphrase produced it. By convention, read both vectors as account 0 with an empty passphrase — the same ambiguity flagged in §2.
mnemonic: leader monkey parrot ring guide accident before fence cannon height naive bean private key (hex): 7f7ff03d123792d6ac594bfa67bf6d0c0ab55b6b1fdb6249303fe861f1ccba9a nsec: nsec10allq0gjx7fddtzef0ax00mdps9t2kmtrldkyjfs8l5xruwvh2dq0lhhkp public key (hex): 17162c921dc4d2518f9a101db33695df1afb56ab82f5ff3e5da6eec3ca5cd917 npub: npub1zutzeysacnf9rru6zqwmxd54mud0k44tst6l70ja5mhv8jjumytsd2x7nu
mnemonic: what bleak badge arrange retreat wolf trade produce cricket blur garlic valid proud rude strong choose busy staff weather area salt hollow arm fade private key (hex): c15d739894c81a2fcfd3a2df85a0d2c0dbc47a280d092799f144d73d7ae78add nsec: nsec1c9wh8xy5eqdzln7n5t0ctgxjcrdug73gp5yj0x03gntn67h83twssdfhel public key (hex): d41b22899549e1f3d335a31002cfd382174006e166d3e658e3a5eecdb6463573 npub: npub16sdj9zv4f8sl85e45vgq9n7nsgt5qphpvmf7vk8r5hhvmdjxx4es8rq74h
Both vectors use the same fixed path shape, only the mnemonic changes. Feed each mnemonic through BIP39 to get a seed, then derive m/44'/1237'/0'/0/0 from that seed. The resulting private key must match the listed hex value and nsec.
5 Version History
Notable changes to NIP-06, newest first:
- 20262026-05Marked
unrecommended. A warning was added recommending a single storednsecinstead of mnemonic derivation. - 20232023-11Removed the per-NIP author byline from the document body.
- 20232023-10Added the two worked test vectors (mnemonic, private key,
nsec, public key,npub). - 20232023-04Renamed the fifth path segment from
address_indextoaccount, matching common BIP44 usage; the segment stayed fixed at 0. - Origin2022-05fiatjaf migrated the spec into the dedicated
nostr-protocol/nipsrepository.
Original Proposal - Credits
| Author | fiatjaf |
| First commit | 2022-05-01 — "migrate nips from main nostr repo." |
| Status | draft - unrecommended — kept for compatibility, not recommended for new designs |
| Source | 06.md on GitHub - full change history |
6 See Also
- NIP-01 — the
secp256k1keypair and event model this NIP produces a key for. - NIP-19 — the
nsecandnpubbech32 encodings used throughout the test vectors above. - NIP-49 —
ncryptsecpassword-based private key encryption, a recommended alternative to a mnemonic-derived key. - NIP-07 — a browser extension signer, which keeps the private key out of the web app entirely.
- NIP-05 — a human-readable identifier for a pubkey; unrelated to key derivation but often confused with it by name.