What Is an HD Wallet? How One Seed Phrase Controls Many Addresses

An HD (hierarchical deterministic) wallet is a wallet that derives every private key and address it will ever use from one master secret, so a single 12- or 24-word seed phrase backs up every account on every supported chain. BIP-39 turns those words into a master seed, BIP-32 grows a reproducible tree of child keys from it, and BIP-44 standardizes the derivation path — coordinates like m/44'/60'/0'/0/0 that say which purpose, chain, account and address index a key belongs to. Because seed plus path always produces the same key, any compatible wallet can rebuild the whole tree from the words alone; it is also why the same seed can display different addresses in two wallets that default to different paths. WATS is a fully non-custodial HD wallet: one seed covers Ethereum, Arbitrum, Optimism, Base, Polygon and BNB Chain — which share a single EVM branch — plus Solana and TON on their own branches, and WATS never holds a key.

One backup, many accounts

Early crypto wallets kept a loose bag of random private keys — lose the file, lose the coins, and every new address meant a new backup. Modern wallets solved this with a deceptively simple idea: generate every key you will ever need from one master secret, deterministically. That is the HD wallet — hierarchical deterministic — and it is why a single seed phrase written on paper can restore dozens of accounts across multiple blockchains, years later, in software that has never seen them before.

From words to master seed: BIP-39

The seed phrase itself comes from a standard called BIP-39. The wallet draws random entropy, maps it onto a fixed wordlist, and hands you 12 or 24 words with a built-in checksum. Run through a key-stretching function, those words become a large binary master seed. Two properties matter: the words are not the keys — they are the recipe for them — and the process is one-way and reproducible. Any BIP-39 wallet, fed the same words, computes the same master seed, forever. That is what makes the phrase a complete backup, and why protecting it is the core habit of self-custody, as covered in the WATS guide to seed phrases.

One detail is easy to miss: BIP-39 also supports an optional passphrase, sometimes called the 25th word. It is mixed into the key-stretching step, so the same 12 words plus a different passphrase produce a completely different master seed and therefore a completely different set of accounts. It is not a password on an existing wallet — it selects a different wallet entirely, and losing it loses those funds as surely as losing the words.

The derivation tree: BIP-32

From that master seed, BIP-32 defines how to grow a tree of keys. The master key deterministically derives child keys, children derive grandchildren, and every branch is reproducible from the root. The hierarchy is what lets one secret serve unlimited structure: separate accounts for saving and spending, a fresh receive address for every payment, entire chains on their own branches — all recoverable from the same 12 or 24 words, with nothing new to back up, ever.

BIP-32 also distinguishes hardened from non-hardened derivation. Hardened steps (the ones marked with an apostrophe in a path) require the parent private key, which walls off a branch: with non-hardened derivation, a leaked child private key plus the parent extended public key is enough to reconstruct the parent private key, and hardening removes that shortcut so an attacker cannot climb back up the tree. That is why the account levels of a standard path are hardened and only the last two levels are not.

Derivation paths: the address of an address

A derivation path — the cryptic string like m/44'/60'/0'/0/0 you may have seen in advanced settings — is simply directions through that tree: which purpose, which coin, which account, which index. BIP-44 standardized the layout, and a shared registry (now maintained as SLIP-44) assigns coin numbers so an Ethereum branch and a Solana branch never collide. One consequence surprises people: every EVM chain reuses coin type 60, so Ethereum, Arbitrum, Optimism, Base, Polygon and BNB Chain are not separate branches at all — they derive the same key and show the same address, which is why one address holds different balances on each network. Different ecosystems also use different signature schemes under the hood — Ethereum and other EVM chains sign on the secp256k1 curve, while Solana and TON use ed25519 — but the principle holds across all of them: seed plus path equals key, every time.

What an xpub reveals

The tree has one more trick: extended public keys. An xpub lets software derive all the public addresses of a branch — but none of the private keys. That enables watch-only portfolio views and receiving addresses generated on an offline device's behalf. The caveat is privacy, not security: anyone holding your xpub can see every address in that branch and link them together. Share it the way you would share a full statement of that account, because functionally it is one.

Worth knowing: this is a secp256k1 feature. On ed25519 chains such as Solana and TON, derivation is hardened at every level, so there is no public-key-only branch to hand out — watch-only tooling there works from the addresses themselves rather than from an extended public key.

Same seed, different addresses?

A classic support mystery: you import your seed into another wallet and the balance looks empty. Almost always, nothing is lost — the second wallet is walking a different path through the same tree, or deriving for a different chain by default. The funds sit exactly where they always were, at the branch the original wallet used. This is also the honest caveat about "universal" backups: the seed standard is shared, but path conventions vary between wallets, so restoring works most smoothly in the wallet family that created the seed — or one that scans the common paths for you. Before concluding anything is missing, check the derivation path setting and the chain selector, and confirm the address you expect on a block explorer.

Where the keys actually live

Because everything descends from the seed, the only question that matters for security is where the seed and its derived keys are stored — and who can reach them. In a non-custodial wallet the answer is your device, and nowhere else. That distinction is also the right lens for hardware: the WATS NFC Metal Card, for example, does not store private keys. It carries a unique card ID and tap-to-authenticates over NFC to keys that live in the WATS apps, pairing to exactly one device — closer to a physical security key than to a cold-storage vault. Knowing which of your tools holds a key and which merely authorizes its use is the difference between a clear recovery plan and a guess.

How WATS uses this

The HD design is what makes a true multi-chain wallet possible, and WATS leans on it fully: one backup, one identity, with EVM, Solana and TON accounts derived on their proper branches — the experience described in managing Ethereum, Solana and TON in one wallet. WATS is non-custodial end to end: the seed and every key derived from it exist only on your side, and WATS never holds a key. The fee layer is then unified to match: every action — transfers, swaps, staking — is charged in one token, ATS, instead of each chain's native gas, via an ERC-4337 paymaster on EVM and an equivalent fee-payer/relayer on Solana and TON. That is not a discount; it changes which token pays, not what the network charges. ATS is a LayerZero OFT, so a single balance spans all three ecosystems, and collected ATS is burned from a 100M supply toward a 30M floor — mechanics on the ATS fee page.

The practical version of all this is short. Set up WATS once — Chrome Extension, Mobile App or both — write the seed phrase down offline, and from that point every account WATS derives for you across Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON is already covered by the backup you made on day one. That is the whole promise of HD wallets, and it is the reason to treat those twelve words, not the app, as the thing you are really protecting.