Your node's seed & entropy

Think of the seed as an acorn. Every branch of the tree — your identity, your wallet, your mesh radio's name — grows from it in a fixed, repeatable pattern. Plant the same acorn on new hardware by typing your 24 words and the same tree grows back, branch for branch. That is why those words are the most valuable thing your node ever shows you, and why anyone who copies them owns your tree.

Linux kernel CSPRNG  (interrupt timing, jitter, CPU RNG)
      │
      │  getrandom(2) — via an explicitly named OsRng, nothing else allowed
      ▼
32 bytes raw entropy ──▶ degenerate-draw check ──▶ refuse & wipe if suspicious
      │
      │  BIP-39 encoding
      ▼
24-word recovery phrase  ←── the only form you ever see or back up
      │
      │  PBKDF2-HMAC-SHA512 × 2048
      ▼
64-byte master seed      ←── lives only in RAM, never written to disk
      │
      ├─ HKDF "archipelago/node/ed25519/v1"    ──▶ Node identity key + DID
      ├─ HKDF "archipelago/nostr-node/…/v1"    ──▶ Node Nostr key (npub)
      ├─ HKDF "archipelago/fips/secp256k1/v1"  ──▶ FIPS mesh transport key
      ├─ HKDF "archipelago/identity/{i}/…/v1"  ──▶ Personal identities
      ├─ BIP-32 m/44'/1237'/0'/0/{i} (NIP-06)  ──▶ Personal Nostr keys
      ├─ HKDF "archipelago/lnd/entropy/v1"     ──▶ Lightning entropy → aezeed
      └─ BIP-32 m/84'/0'/0'                    ──▶ Bitcoin xprv (dormant)
                  │
                  │  and from the node key, second-order:
                  ▼
      ├─ Reticulum / LXMF mesh identity
      ├─ Message-store + contacts encryption
      └─ Credential-store key

One rule to remember

If it is on the diagram above, your 24 words rebuild it from scratch, on any hardware, forever. If it is not on the diagram — session tokens, app passwords, WireGuard keys, Lightning channel state — it is independent randomness, protected by other backups.

Computers cannot invent randomness — they collect it. The Linux kernel constantly harvests unpredictable physical noise (the exact nanosecond a network card interrupts, timing jitter between CPU cores, the CPU's hardware random generator) into a cryptographic pool. Archipelago rolls its dice by asking that pool directly, and only that pool. There is deliberately no blending of other sources: a single, named, well-studied source is auditable, whereas a blend is a place for bugs to hide.

let mut entropy = [0u8; 32];
crate::entropy::draw_key_bytes(&mut rand::rngs::OsRng, &mut entropy)?;  // guarded draw
let mnemonic = bip39::Mnemonic::from_entropy(&entropy)?;                // → 24 words
entropy.zeroize();                                                       // wipe raw bytes

1. First boot: a placeholder. A freshly flashed node boots with a random temporary identity key so services can start. It is not seed-derived and is about to be thrown away.
2. Onboarding: the real draw. At the "Recovery phrase" step, the seed.generate RPC performs the guarded 32-byte draw and shows you the 24 words.
3. Derivation. Node key, DID, Nostr key, FIPS mesh key and your first identity are derived and written to /var/lib/archipelago/identity/ at mode 0600, overwriting the placeholder.
4. Password setup: the backup is sealed. The words are encrypted under your login password and stored as master_seed.enc, so you can reveal them again later.

Generation is idempotent for 10 minutes and serialised behind a lock: a browser refresh returns the same words rather than minting a second seed.

Why so paranoid about one function?

In 2026 a well-known hardware wallet shipped a bug where a refactor quietly switched seed generation to a predictable random source — no error, no warning, and seeds that looked perfectly normal. Predictable randomness is invisible: the words look random, the wallet works, and months later someone who can predict the generator drains it. Archipelago's answer is to make that entire class of bug impossible to compile, and to log the health of the random pool at the moment your seed was created.

The raw seed never touches disk

What is stored is the encrypted words and the derived keys. The 64-byte master seed is recomputed in RAM from the words when needed and wiped afterwards.

login password ──▶ Argon2id (memory-hard) ──▶ 256-bit file key
                       ▲
               16-byte random salt

24 words ──▶ ChaCha20-Poly1305 (authenticated, 12-byte random nonce)
                       │
                       ▼
     ┌───────────┬────────────┬───────────────────────────┐
     │ salt (16) │ nonce (12) │ ciphertext + auth tag     │  = master_seed.enc
     └───────────┴────────────┴───────────────────────────┘

Your words are locked in a digital safe whose combination is your login password, run through a deliberately slow, memory-hungry grinder (Argon2) so guessing billions of passwords per second is impractical even for someone who steals the file. The authentication tag means the safe also notices tampering: a modified file fails loudly rather than yielding wrong words.

The node never uses the master seed directly as a key. It uses HKDF — think of a locksmith who, given one master blank and a label ("node key", "mesh key", "Lightning entropy"), cuts a completely different, unrelated key for each label. Knowing one cut key tells you nothing about the others or about the blank. The labels are fixed strings baked into the code, which is what lets the identical tree regrow on new hardware.

master seed ──HKDF──▶ 16 bytes ──▶ LND generates its own "aezeed" ──▶ wallet
                                              │
                                              │  ⚠ one-way: the aezeed cannot be
                                              │    recomputed from your 24 words
                                              ▼
                              captured ONCE at init, stored encrypted as
                              identity/lnd_aezeed.enc

Back up the Lightning seed separately

Your 24 words restore your node identity and on-chain derivations, but not an already-initialised Lightning wallet, and never off-chain channel balances (those need channel backups, as Lightning requires by design). Treat the aezeed in the Lightning backup screen as a second phrase worth writing down. It restores into LND-based wallets such as Zeus, Blixt or another Archipelago node — hardware wallets cannot import it.

The one true single point of failure is you

Every software failure above fails safe. The only unrecoverable scenario is losing the 24 words and the node's disk together. Write the words down, store them offline, and never type them into anything except a node you are restoring. Anyone holding them can rebuild your entire identity tree — which is exactly what makes them a perfect backup and a perfect target.

1. Gate check. Restore only proceeds on an un-onboarded node. This gate is load-bearing and runs before anything else.
2. Validation. Exactly 24 words, checked against the BIP-39 wordlist and its checksum — a typo is caught here, before anything is written.
3. Identity regrowth. Node key, DID, node Nostr key and FIPS mesh key are re-derived byte-identically, because the HKDF labels are fixed.
4. Personal identity #0. The index resets to 0 and your default identity (Ed25519 + NIP-06 Nostr key) is recreated. Further seed-derived identities re-derive as the index walks forward, but their names and avatars were metadata, not key material.
5. Mesh reactivation. FIPS auto-activation starts in the background; the Reticulum identity re-derives from the restored node key, so your LXMF address returns too.
6. Password and re-seal. Setting the new login password re-encrypts the words into a fresh master_seed.enc, so Reveal works on the restored node.

The whole story in one paragraph

Your node asked the Linux kernel for 32 bytes of hardware-grade randomness through a single, named, compiler-enforced channel; refused to proceed unless the bytes looked alive; wrote down the health of the random pool as evidence; turned the bytes into 24 words it showed you exactly once; locked an encrypted copy behind your password; and then grew every identity and key it owns from those words along fixed, versioned, independently verifiable paths — so the words in your drawer are, and will remain, a complete blueprint of who your node is.