What is Address Derivation?

Introduction

Address derivation is the process by which a wallet or protocol turns some underlying cryptographic material into the address a user sees, shares, and receives funds at. That sounds like a formatting detail, but it is not. The way an address is derived determines whether a wallet can regenerate all your accounts from one backup, whether two wallets agree on what your “next address” is, whether a string is valid for one chain but meaningless on another, and how much damage follows if some key material leaks.

The puzzle is that an address often looks like the simplest part of a wallet. It is usually just a string: maybe bc1..., maybe 0x..., maybe cosmos1... . But the address is the visible tip of a longer chain of decisions. Somewhere underneath is a seed, then derived keys, then usually a public key or script payload, and only then the final encoded address. If you miss that layered structure, many wallet behaviors seem arbitrary: why one seed gives many addresses, why restoring a wallet involves “scanning,” why the same mnemonic can produce different accounts on different chains, or why some addresses can be generated from an xpub while others cannot.

The core idea is simple: an address is usually not the key itself, but a deterministic identifier derived from key material according to chain-specific rules. Once that clicks, most of the surrounding machinery becomes easier to reason about. Some systems derive addresses directly from a public key. Others derive a script identifier, a hashed public key, or even a future contract address from deployment inputs. The common structure is the same: take stable inputs, apply a specified transformation, and get an identifier that other participants can use.

How does a BIP‑39 seed and BIP‑32 path become a wallet address?

A wallet does not begin with an address. It begins with entropy: random bits. In many modern wallets, that entropy is encoded as a mnemonic sentence under BIP-39. BIP-39 defines how entropy is turned into a sequence of words, how a checksum is embedded in that word sequence, and how the mnemonic plus optional passphrase is converted into a 512-bit binary seed using PBKDF2 with HMAC-SHA512 and 2048 iterations. That seed is not itself an address and not itself a spending key. It is the root input to deterministic key generation.

From there, standards such as BIP-32 define how one seed becomes a whole tree of keys. BIP-32 derives a master extended private key from the seed using HMAC-SHA512 keyed by the literal string Bitcoin seed, then repeatedly derives child keys using child Key derivation. The important structural fact is that the wallet is no longer “one key, one address.” It becomes one seed, many branches, many child keys, and therefore many possible addresses. A derivation path such as m / 44' / 0' / 0' / 0 / 15 is not an address formula by itself. It is a way of naming which child key in the tree you mean.

Only after a specific child key is selected does address derivation happen in the narrow sense. The wallet computes the child public key from the child private key, or derives a child public key directly in non-hardened branches if it has an extended public key. Then the chain’s address rules take over. On Bitcoin, that may mean embedding a witness program into a Bech32 string. On Ethereum, it may mean taking a 20-byte account identifier and optionally encoding checksum information through letter case under EIP-55. On Cosmos SDK chains, it means deriving 20 address bytes from a public key and then Bech32-encoding them with a role-specific human-readable prefix. The derivation path chooses which key; the chain rules choose how that key becomes an address.

That separation matters because people often conflate key derivation and address derivation. They are related but not identical. Key derivation answers: “From my seed, which key am I using?” Address derivation answers: “Given that key or related payload, how do I compute the user-facing identifier for this network?” If two wallets agree on the BIP-39 seed and BIP-32 path but disagree on the final address encoding or script type, they can still produce different addresses.

Why do wallets derive many receive addresses from a single seed?

At first glance, a wallet could just publish one address forever. But deterministic wallets were designed to avoid exactly that. Reusing one address weakens privacy, makes bookkeeping harder, and does not fit how many chains separate receiving, change, staking, validator, or contract identities. Address derivation exists in part to let a wallet create fresh addresses without asking the user to back up new keys each time.

Here the key invariant is: the wallet can regenerate the same sequence of addresses later from the same root material and the same derivation rules. That is what makes recovery possible. Lose the phone, restore the mnemonic, derive the same seed, follow the same paths, and the wallet can reconstruct the same account tree. This is why conventions such as BIP-44 matter so much. BIP-44 fixes a five-level path structure, m / purpose' / coin_type' / account' / change / address_index, so different wallets can agree about where to look.

A concrete example makes this more intuitive. Imagine a Bitcoin wallet generated from a 12-word mnemonic. The words are turned into a seed under BIP-39. The wallet derives the BIP-44 account root for Bitcoin using coin type 0', then the external receiving chain 0, then address indices 0, 1, 2, and so on. The first payment request uses index 0, so the wallet computes the corresponding child key and from that constructs the first receiving address. The next time you ask for a receive address, it moves to index 1. Nothing random is happening at that moment. The wallet is just walking deterministically through a pre-defined branch of a tree.

The recovery side explains why wallets scan for activity instead of simply showing one address. BIP-44’s account discovery model assumes that, after restoring a seed, software derives accounts sequentially and scans external addresses until it finds a long enough run of unused addresses. The default address gap limit is 20. That number is a practical stopping rule: if a wallet sees 20 unused external addresses in a row, it assumes there are no used ones further ahead. This is not a law of cryptography; it is a convention that makes recovery tractable. The consequence is subtle but important: if a user generates many unused receive addresses beyond the expected gap, some software may fail to find later used ones during restore.

What payload (public key, hashed key, or script) is used to form an address?

The phrase “derive an address from a key” is true, but it compresses away a critical distinction: different chains do not all treat the public key as the final identity. They choose different intermediate payloads.

On some systems, the address is derived from a public key hash rather than the raw public key. Cosmos SDK account addresses are a clear example. For standard secp256k1 account keys, the SDK derives address bytes by hashing the compressed 33-byte public key with SHA-256 and then RIPEMD-160, yielding 20 bytes. Those bytes are then encoded into Bech32, typically with an HRP such as cosmos. The address therefore represents a hashed identifier tied to the public key, not the raw key itself.

Bitcoin uses a related but not identical pattern depending on output type. For native SegWit outputs encoded with Bech32, the final address consists of a human-readable part such as bc, a separator, and a data part that includes the witness version and witness program. In the common pay-to-witness-public-key-hash case, that witness program is derived from key material and then converted into 5-bit groups for Bech32 encoding. The important point is that the displayed Bech32 address is an encoding of a script-related payload, not merely a pretty-printed public key. That is why changing script type changes the address even if the underlying key does not.

Ethereum goes in another direction. Externally owned account addresses are 20-byte identifiers rendered as hexadecimal, commonly with an optional EIP-55 checksum. EIP-55 does not change the underlying 20-byte address; it changes how the string is written by uppercasing certain hexadecimal letters according to the keccak256 hash of the lowercase hex text. The checksum therefore lives in the presentation layer. Two strings can represent the same 20-byte address even though one uses canonical checksum casing and another is all lowercase. Mechanically, that is very different from Bech32, where the checksum is built into the encoded string format itself.

This is a good place to separate fact from analogy. An analogy is that an address is like a mailing label created from some internal identity record. That explains why a visible address may be a transformed, checksummed, network-tagged representation of something deeper. But the analogy fails if taken too far, because in many systems the exact transformation affects spendability, interoperability, and recovery. The label is not arbitrary packaging; it is part of the protocol contract.

How do address encodings (Bech32, EIP‑55) affect network, checksum, and UX?

People sometimes treat address encoding as cosmetic. It is not. Encoding is where many chains embed network distinction, checksum behavior, and address type.

Bech32 is a strong example. BIP-173 defines a Bech32 string as a human-readable part, the separator 1, and a data part whose last six characters are a checksum. The checksum is designed to catch common transcription errors; the specification states it detects any error affecting at most four characters and has a very low failure probability beyond that for expected lengths. The human-readable part also matters. In Bitcoin, bc and tb distinguish mainnet and testnet. In Cosmos-family chains, prefixes such as cosmos, cosmosvaloper, and cosmosvalcons distinguish different address roles. So the prefix is not decoration. It helps tell both humans and software what namespace they are in.

Ethereum’s EIP-55 reveals a different tradeoff. The ecosystem wanted a checksummed format without changing the basic 0x plus 40-hex-character style. So instead of adding new symbols or new length, EIP-55 uses case as checksum information. That preserved broad compatibility with existing parsers, but with weaker error detection than a dedicated check code. The specification estimates roughly 15 effective check bits on average and a random mistype acceptance probability around 0.0247%. This is useful, but it depends on software actually validating mixed-case checksums rather than normalizing case away.

The broader lesson is that an address is both a cryptographic derivation result and a human-interface object. Good address formats try to balance machine determinism, error detection, and user recognizability. Different chains make different choices because their constraints differ.

How do xpubs and hardened vs non‑hardened derivation change address generation and risk?

Address derivation becomes especially interesting when a wallet does not want to expose spending keys but still wants to generate receive addresses. BIP-32 enables this through Extended public keys. An extended key is not just a key; it is a key plus a 32-byte chain code. For non-hardened branches, BIP-32 defines CKDpub, which allows a child extended public key to be derived directly from a parent extended public key.

That is why an xpub can power a watch-only wallet, a merchant checkout system, or accounting software. The system can derive fresh child public keys and thus fresh receive addresses without ever holding the private keys. Mechanically, this works because non-hardened child derivation uses the parent public key and chain code as inputs. But the security boundary is delicate. BIP-32 explicitly warns that knowledge of a parent extended public key plus any non-hardened descendant private key is equivalent to knowledge of the parent extended private key. In other words, public derivation is convenient, but it creates a linkage that hardened derivation intentionally avoids.

This is why standards place hardened boundaries where compromise would otherwise spread too far. BIP-44 uses hardened derivation for purpose', coin_type', and account', then non-hardened derivation for change and address_index. The idea is that a shared account-level xpub can safely derive receiving and change addresses for that account, while leaks from a lower non-hardened branch do not jump upward across the hardened account boundary.

If that sounds abstract, think of the hierarchy as a system of sealed rooms connected by hallways. Non-hardened derivation leaves a hallway from public parent to public child, which is useful if you want observers to walk the receive-address branch. Hardened derivation bricks up that hallway. The analogy explains isolation, but it fails in one respect: cryptographic leakage is not physical movement. The actual risk comes from the algebraic relationship between parent extended public data and descendant non-hardened private keys.

How does address derivation differ between Bitcoin, Ethereum, Cardano, Solana, and Polkadot?

The most common misunderstanding is to assume there is one universal address derivation recipe. There is not. There are recurring patterns, but each chain chooses its own identifiers, key curves, hashing steps, path conventions, and display format.

Cardano is a useful example because it looks superficially familiar and yet differs in a fundamental way. Shelley-era Cardano wallets standardize on CIP-1852 with path m / purpose' / coin_type' / account' / role / index, where the purpose is 1852', not BIP-44’s 44'. More importantly, Cardano does not use standard BIP-32 over secp256k1. It uses BIP32-Ed25519, and the CIP explicitly mandates the Icarus sequential style for interoperability. So even when the path shape resembles BIP-44, the derivation primitive underneath is different.

Solana differs again. Its account model defines each account by a unique 32-byte address that is either an Ed25519 public key or a Program Derived Address. The visible lesson is that an “address” can be a raw public-key-based account identifier, but the system also supports program-derived identities that are not just ordinary user keys in another encoding. The meaning of “derive” therefore expands beyond “hash a public key” into “compute a valid protocol-recognized account identifier from structured inputs.”

Polkadot introduces still another angle. User-facing explanations describe the address as the public part of an account and emphasize that the same mnemonic can generate public keys usable across parachains under a unified address format. The broad takeaway is not the exact encoding detail; it is that ecosystem architecture influences address derivation. When many chains share a broader environment, the address scheme may be designed to reduce cross-chain UX errors rather than merely minimize bytes.

These differences are why copying habits from one chain to another is risky. A valid-looking string can be wrong in at least three different ways: wrong derivation path, wrong address encoding, or wrong network namespace.

How are smart-contract addresses computed (CREATE vs CREATE2) and why does that matter?

Address derivation is not only about user wallets. Smart-contract platforms also derive contract addresses.

Ethereum shows this clearly. The Yellow Paper defines a standard contract creation address as the rightmost 160 bits of Keccak-256(RLP(sender, nonce)), meaning the deploying account and its nonce determine the future contract address. EIP-1014 introduced CREATE2, which instead computes the address as the rightmost 160 bits of keccak256(0xff ++ address ++ salt ++ keccak256(init_code)). The effect is profound: the future contract address can be known in advance from the deployer address, a salt, and the initialization code hash, without depending on the creator’s future nonce.

Why does that matter? Because some applications need to act as if an address already exists before deployment. State-channel and counterfactual designs rely on the ability to precompute where code would appear if later deployed. Here address derivation is doing more than naming a keyholder. It is naming a possible future account whose code identity is constrained by the derivation formula.

This also shows what changes and what stays invariant. Under ordinary CREATE, changing the creator nonce changes the address. Under CREATE2, the nonce drops out, but the salt and init_code hash matter. The invariant is deterministic reproducibility from specified inputs. The variable part is which inputs the protocol chooses to bind into the address.

What common pitfalls break address recovery, interoperability, or security?

The clean story is: same inputs, same address. The subtleties come from hidden assumptions.

One assumption is that wallet software agrees on conventions. BIP-39 mnemonics are widely used, but not every wallet supports every wordlist equally; the BIP itself strongly discourages non-English wordlists for generation because most wallets support only English. If the mnemonic-to-seed step or normalization rules differ, the whole downstream address tree changes. Likewise, a seed restored in software expecting BIP-44 may not recover addresses generated under another path convention.

A second assumption is that scanning rules match user behavior. BIP-44’s discovery process depends on the gap limit and on transaction history, not just balances. If software stops after 20 unused external addresses but the user generated 50 fresh unused receive addresses before using the next one, recovery may miss funds until the scan range is extended. Nothing cryptographic has failed; the mismatch is between deterministic derivation and practical search heuristics.

A third assumption is that “same address” means the same thing everywhere. It often does not. In Ethereum, a checksummed and a lowercase hex string may refer to the same 20-byte address. In Bech32-based systems, the HRP can make the same data payload belong to a different network or role namespace. In multi-chain wallet contexts, the same seed may intentionally produce distinct subtrees per coin_type', precisely to avoid reusing addresses across assets.

Finally, some security intuitions break if hardened and non-hardened derivation are confused. An ordinary public key can be shared quite freely. An extended public key must be handled more carefully because of the relationships BIP-32 defines. If someone learns a parent xpub and one non-hardened child private key, the damage can extend upward dramatically. That is not an implementation bug; it is a property of the construction.

Conclusion

Address derivation is the rulebook that turns cryptographic roots into usable on-chain identities. A seed becomes a tree of keys, a path selects a branch, and chain-specific logic converts the resulting key material or payload into the address format users recognize.

The detail to remember tomorrow is this: an address is not just “where funds go.” It is the deterministic output of a specific derivation scheme; and understanding that scheme explains recovery, interoperability, privacy, watch-only wallets, cross-chain differences, and many of the errors people make when they assume all addresses work the same way.

How do you secure your crypto setup before trading?

Address Derivation belongs in your security checklist before you trade or transfer funds on Cube Exchange. The practical move is to harden account access, verify destinations carefully, and slow down any approval or withdrawal that could expose you to this risk.

1. Secure account access first with strong authentication and offline backup of recovery material where relevant.
2. Translate Address Derivation into one concrete check you will make before signing, approving, or withdrawing.
3. Verify domains, addresses, counterparties, and approval scope before you confirm any sensitive action.
4. For higher-risk or higher-value actions, test small first or pause the workflow until the security check is complete.