One Seed, Three Chains

When you create a nimimo identity you get three addresses on three chains. They look nothing alike. One starts with bc1, one with 0x, one is base58 with no prefix at all. Two of them sit on different elliptic curves.

All three come from one secret, and the process is entirely standard, the same standards a hardware wallet uses. This post walks the path from that secret to those three addresses, because the whole non-custodial claim rests on it being reproducible without us.

Step one: the entropy

It starts with 32 bytes from the browser's cryptographic random number generator. Not a password, not a hash of your email, not anything derived from information we hold. 256 bits of entropy from the operating system.

Those bytes become a 24-word BIP-39 mnemonic. The arithmetic is worth seeing, because it explains the word count:

256 bits entropy + 8-bit SHA-256 checksum = 264 bits
264 bits / 11 bits per word          = 24 words

Every BIP-39 word encodes 11 bits, which is why the wordlist has exactly 2048 entries. The trailing checksum is what lets a wallet tell you that you mistyped a word instead of silently opening an empty wallet.

Twelve words is 128 bits of entropy and is considered sound. We use 24 because the cost of the larger mnemonic is borne by software rather than by you. nimimo stores and restores it for you, so the usual argument for twelve words, that people have to transcribe them by hand, does not apply.

Step two: mnemonic to seed

The mnemonic is stretched into a 64-byte seed through the BIP-39 key derivation function. From there, BIP-32 turns that seed into a hierarchical tree of keys, where any node can be addressed by a path.

One detail that matters for recovery: what nimimo encrypts and stores is the mnemonic string, not the derived seed. The mnemonic is the more portable artifact. It can be re-entered into any standards-compliant wallet, while a raw seed cannot. Storing the recoverable form is a deliberate choice about who is in control.

Step three: three paths

BIP-44 gives the tree a convention: purpose, coin type, account, change, index. Each chain gets its own branch, so the three keys are cryptographically unrelated in practice even though they descend from one root.

Bitcoin    m/84'/0'/0'/0/0
Ethereum   m/44'/60'/0'/0/0
Solana     m/44'/501'/0'

The second number is the registered coin type. 0 for Bitcoin, 60 for Ethereum, 501 for Solana. The first differs because Bitcoin uses purpose 84 rather than 44, which is the marker for native SegWit addresses.

Step four: three formats

Bitcoin

The public key is hashed, then encoded with bech32 using the human-readable prefix bc. That produces a P2WPKH address, a native SegWit address, the bc1 form. It costs less in fees than the older formats and its checksum catches typos more reliably.

Ethereum

The last 20 bytes of the hashed public key form the address, then EIP-55 checksumming is applied. That is the mixed-case you see in an Ethereum address: the capitalization is not cosmetic, it encodes a checksum that any compliant wallet verifies before sending.

Solana

Solana is the one that breaks the pattern. Bitcoin and Ethereum both use secp256k1; Solana uses Ed25519, a different curve with a different derivation scheme. The path is shorter, stopping at the account level with no change or index component, and derivation runs through the Ed25519 variant rather than standard BIP-32.

The address is then the public key itself, base58-encoded. No hashing step, no separate checksum layer.

The same seed, a second wallet

Because BIP-44 addresses a tree rather than a single key, one seed can produce more than one wallet per chain. Changing the account component of the path yields a completely separate address that is still recoverable from the same 24 words.

primary   m/84'/0'/0'/0/0
sibling   m/84'/0'/1'/0/0

nimimo uses this where funds need to be kept apart from your main balance without asking you to manage a second secret. The sibling is derived on demand, deterministically, from the wallet you already have. Nothing new is generated and nothing extra has to be backed up.

It is a small illustration of why the hierarchy in hierarchical deterministic wallets matters. The tree is not decoration. It means separation of funds costs a path component rather than a whole new backup burden.

Why this is the whole argument

Every step here is a published standard implemented by dozens of independent wallets. Nothing about the path is nimimo-specific, and that is the point rather than a missed opportunity.

If nimimo disappeared tomorrow, your 24 words entered into any standards-compliant wallet would reproduce the same three addresses, holding the same funds. You are not depending on our continued existence, our goodwill, or our servers. You are depending on BIP-39, BIP-32, BIP-44 and BIP-84, which are public documents that do not have a business model.

A proprietary derivation scheme would have been easy to write and would have quietly made you our customer forever. Using the boring standard is what makes the exit door real, and a non-custodial claim without a working exit door is just a slogan.