How Bitcoin Wallets Generate Addresses From Seed Phrases

Most people never think about what happens after they write down their 12 or 24 words. They trust that their wallet will somehow turn those words into an infinite supply of Bitcoin addresses, and they never question how it works. That’s unfortunate, because understanding this process reveals why the seed phrase system has become the foundation of cryptocurrency custody — and why it remains the standard after more than a decade.

The process involves three interconnected Bitcoin Improvement Proposals (BIPs): BIP-39, BIP-32, and BIP-44. Each serves a distinct purpose, and the way they work together is worth understanding if you hold any amount of Bitcoin. Not because you need to become a cryptographer, but because knowing how your keys are derived helps you make better decisions about which wallets to use and how to secure your funds.

Before diving into the technical details, you need to understand what these three BIPs actually do. This matters because I’ve seen people conflate them constantly, and that confusion leads to bad security decisions.

BIP-39 defines how your seed phrase is created from cryptographic entropy and how it’s converted into a master seed that computers can actually use. It also specifies the wordlists — the famous 2048-word lists that let you write down your seed in plain English rather than as a string of hexadecimal characters.

BIP-32 introduced the concept of Hierarchical Deterministic (HD) wallets. This allows one master key to generate unlimited child keys. Before BIP-32, wallets had to generate new random keys for every transaction and store them all. HD wallets changed this — you only need one piece of information (the master key derived from your seed) to derive your entire keychain.

BIP-44 established a standardized derivation path structure so different wallets could work together. Without BIP-44, a wallet created by Ledger wouldn’t be able to restore your keys from a Trezor seed, and vice versa. BIP-44 made wallets from different manufacturers compatible with each other.

These three standards build on each other. BIP-39 gives you the seed phrase. BIP-32 explains how to turn that seed into a tree of keys. BIP-44 tells everyone exactly how to structure that tree so all wallets speak the same language.

BIP-39: Turning Randomness Into Your Seed Phrase

Your wallet doesn’t actually use your seed phrase directly. The words are a human-readable representation of something far more fundamental: entropy.

Here’s how it works. When you first set up a wallet, the software generates 128 bits of random data (for 12-word seeds) or 256 bits (for 24-word seeds). This entropy is then run through a hashing function to generate a checksum. The checksum is appended to the entropy, and the combined data is split into groups of 11 bits. Each 11-bit group corresponds to one word from the 2048-word BIP-39 list.

The reason for the checksum is simple: it allows your wallet to detect errors. If you type in your seed phrase and even a single word is wrong, the checksum won’t match, and the wallet will immediately tell you something’s wrong. This is why BIP-39 seeds are self-validating — the math catches typos that would otherwise result in lost funds.

I should mention something that many articles skip over: the BIP-39 wordlists were designed to avoid confusion between similar-looking letters. There’s no “B” that could be confused with “8,” no “1” that looks like “l” or “I.” This matters when you’re handwriting your seed. The designers thought about real-world error modes.

The mnemonic sentence is then converted into the master seed through another hashing process — specifically, PBKDF2 with 2048 rounds of hashing. This slow function exists to make brute-force attacks more expensive. If someone somehow obtains your mnemonic but not the salt (which is optional in BIP-39, though most implementations use “mnemonic” as the salt), they’d need significant computational resources to even attempt cracking it.

What emerges from this process is a 512-bit master seed. This is the actual cryptographic material your wallet uses. The words you wrote down were just the interface.

BIP-32: The Master Key Magic

Now you have a 512-bit master seed. BIP-32 explains how to turn this into your master extended key — typically called the “master private key” in combination with a chain code.

The master seed is fed through HMAC-SHA512. The left 256 bits become your master private key, and the right 256 bits become your master chain code. Together, these form what’s called an extended private key (often represented as xprv in Base58 format).

Here’s where things get interesting. From this single xprv, you can derive any number of child keys. The derivation function takes three inputs: the parent key, the chain code, and an index number. The process is completely deterministic — the same inputs always produce the same outputs. There’s no randomness involved after the initial seed generation.

There are two types of child key derivation in BIP-32: hardened derivation and non-hardened derivation. The difference matters for security.

Hardened derivation (denoted by an apostrophe in the index, like m/0′) breaks the relationship between parent and child keys at the chain code level. This means that even if someone obtains one of your child private keys, they cannot work backwards to discover your parent key or any sibling keys. This is important for wallet security in scenarios where you might need to share a child public key for auditing purposes while keeping your master seed completely secure.

Non-hardened derivation (without the apostrophe, like m/0) allows derivation from the public key directly. This enables what are called watch-only wallets — you can import your extended public key (xpub) into a wallet that can generate receive addresses and monitor your balance without ever being able to spend your funds. Many hardware wallet setups use this: the hardware device holds the private keys (the xprv), while your computer only knows the xpub.

I want to be direct about something that often gets muddled in explanations: hardened derivation should be used for any level where you’re deriving actual private keys that will hold funds. Non-hardened is fine for generating only-public-key derivation paths that you share with other systems, but it’s not appropriate for your main key hierarchy. Most modern wallets get this right, but it’s worth understanding why.

BIP-44: Navigating the Derivation Path

BIP-44 formalized the structure of the key tree using a five-level derivation path standard: m / purpose' / coin_type' / account' / change / address_index.

Each level has a specific meaning:

Purpose (first level): Always 44′ for BIP-44 compliance. This indicates the wallet follows this specific standard.

Coin_type (second level): Different cryptocurrencies have different numbers. Bitcoin is 0′ (with 0′ for mainnet, 1′ for testnet). Ethereum is 60′. This is why your Bitcoin seed won’t accidentally generate Ethereum addresses — they’re on different branches of the tree.

Account (third level): Allows you to separate funds into different “accounts” from the same seed. Many people use 0′ for their main account, but you could create m/44’/0’/1′ for a savings account, for example.

Change (fourth level): This is where it gets slightly confusing for newcomers. The “change” level doesn’t refer to transaction change (the leftover funds sent back to your wallet). Instead, it distinguishes between external chain (receive addresses, denoted as 0) and internal chain (change addresses, denoted as 1). When you send Bitcoin, any change from the transaction gets sent to an address on the internal chain.

Address_index (fifth level): This is the actual counter that increments for each new address. m/44’/0’/0’/0/0 is your first receive address, m/44’/0’/0’/0/1 is your second, and so on.

The derivation path most people encounter is m/44’/0’/0’/0/0 — purpose 44′, Bitcoin mainnet, account 0, external chain, address 0. This is the first address your wallet will generate.

Here’s what surprises many people: BIP-44 is a convention, not a rule. Wallets can technically use any derivation path they want. This is exactly why different wallets can show different addresses for the same seed — they’re using different paths.

The Complete Journey: From Entropy to Address

Let me walk through the entire process step by step, because seeing how these pieces fit together illuminates the whole system.

Step 1: Entropy generation. Your wallet gathers 128 or 256 bits of random data. Modern wallets use cryptographically secure random number generators that seed from system entropy — keyboard timings, mouse movements, and other unpredictable hardware events.

Step 2: Mnemonic creation. The entropy is processed with SHA-256 to create a checksum, the checksum is appended, and the result is split into 11-bit groups. Each group maps to a word from the BIP-39 wordlist.

Step 3: Master seed derivation. The mnemonic (plus optional salt) is run through PBKDF2 with 2048 iterations, producing a 512-bit master seed.

Step 4: Master key generation. The master seed is hashed with HMAC-SHA512, producing your master private key (256 bits) and master chain code (256 bits).

Step 5: Child key derivation. Using BIP-44, your wallet derives through the path hierarchy. For the first Bitcoin receive address, it follows m → 44′ → 0′ → 0′ → 0 → 0.

Step 6: Address generation. Finally, your wallet takes the derived child private key and runs it through the elliptic curve (secp256k1) to derive the public key. The public key is then hashed with SHA-256 and RIPEMD-160, formatted with version bytes (determining whether it’s a Legacy, SegWit, or Native SegWit address), and encoded in Base58Check or Bech32.

At each step, the process is completely deterministic. Your 12 words always produce exactly the same sequence of addresses. This is the key feature of HD wallets: you carry your entire financial history in those few words.

Why Your Wallet Shows Different Addresses Than Your Friend’s

This is one of the most common questions in Bitcoin, and it trips people up constantly. You and your friend both have 24-word seeds, you both type them into different wallets, and somehow you see different addresses. How?

The short answer is derivation path divergence. Your seeds might generate the same keys internally, but the wallets are looking at different branches of the key tree.

Here’s the most likely scenario: one of you is using a Legacy wallet (producing addresses starting with 1), while the other is using a SegWit or Native SegWit wallet (producing addresses starting with 3 or bc1). Even with identical seeds, these use different version bytes in the address generation step, so the final addresses look completely different even though they’re derived from the same private keys.

Alternatively, one wallet might follow BIP-44 strictly (m/44’/0’/0’/0/0), while another might use a non-standard path. Trezor, for instance, historically used different paths than some other hardware wallets for certain operations.

This is why reputable wallet manufacturers document their derivation paths. If you ever need to recover your funds using a different wallet, knowing the exact path used can mean the difference between recovering your money and losing everything.

There’s also a more subtle point worth understanding: some wallets generate addresses on multiple paths simultaneously. They might show you Legacy, SegWit, and Native SegWit addresses all for the same seed, giving you options for where to receive Bitcoin. This doesn’t mean your seed has multiple copies of your keys — it means the wallet is exploring different branches of the same key tree.

What Could Actually Go Wrong

I’ve spent most of this article explaining how the system works correctly. Let me be honest about where it can fail, because that’s what actually matters for security.

BIP-39 wordlist variations. Not all wallets use the same wordlist. The English BIP-39 wordlist is standard, but there are other language lists, and they’re not all equally well-implemented. If you’re recovering a seed in a wallet that uses a different language wordlist than the original, you need to be careful. The word positions aren’t just translated — different languages have different word counts and different ordering.

Non-standard derivation. Some wallet developers have chosen derivation paths outside the BIP-44 standard. This creates vendor lock-in that can bite you years later if that wallet disappears. I’ve seen people stuck with inaccessible funds because the only way to derive their addresses was through an obscure wallet that no longer existed.

Checksum limitations. BIP-39’s checksum catches single-word errors reliably, but it’s not foolproof. Multiple errors can still result in a “valid” but incorrect seed. This is why you should always verify a restored wallet shows the expected addresses before transferring significant funds.

Seed phrase storage. The seed generation process is mathematically sound, but human behavior introduces weakness. Writing words incorrectly, using the wrong word from the list, storing in locations that degrade — these are the real risks. The cryptography is fine. The humans aren’t.

The reality is that the BIP standards are well-designed and have held up well over more than a decade of use. The failures I’ve observed in practice almost always trace back to implementation bugs or human error, not to fundamental flaws in the derivation process.

Moving Forward

The seed phrase system remains one of the most practical solutions in financial technology. The idea that 12 or 24 words — easily written on paper, easily memorized, easily understood — can represent control over unlimited Bitcoin addresses across multiple generations is genuinely useful.

What I find compelling is that this system emerged from open standards that anyone can audit and implement. There are no proprietary algorithms, no secret formulas — just publicly documented methods that have been reviewed, tested, and refined by thousands of developers over more than a decade.

As you continue holding Bitcoin, the most important thing isn’t memorizing all the derivation paths or understanding every cryptographic detail. It’s ensuring you understand the basic principle: your seed phrase is the master key to your funds, and the HD wallet architecture is what makes that single key infinitely powerful. Treat it accordingly, verify your backups work, and trust the mathematics.