From a wallet seed to an Ethereum address

The real pipeline behind an Ethereum wallet — BIP-39, BIP-32, BIP-44, secp256k1, Keccak-256 and EIP-55 — computed live in the browser, with the statistical side of hashing.

Inputs

Mnemonic, passphrase and path

This runs entirely in your browser, but never type a seed phrase that protects real funds into a webpage. Use the built-in test vectors or generate a throwaway one.

Test vector

Derivation path (BIP-44)

Mnemonic phrase (12–24 words)

Optional BIP-39 passphrase ("25th word")

Quick paths:

The last chip is a Bitcoin path: the derivation is standard, but the address below is still the Ethereum-style Keccak/EIP-55 one — other chains encode addresses differently.

The pipeline, step by step

Each stage shows the live value flowing through it. Click a stage for what it does and why.

Mnemonic phrase BIP-39

BIP-39 turns random entropy into a human-friendly sentence and then into a binary seed. 128–256 bits of randomness plus a checksum are mapped onto 12–24 words from a fixed 2048-word list (chosen so each word's first four letters are unique). This is key generation: the phrase is the backup, and everything below derives from it.

—

Seed BIP-39

The mnemonic is stretched with PBKDF2-HMAC-SHA512 (2048 iterations), salted with the string "mnemonic" plus an optional user passphrase, producing the 512-bit seed. A different passphrase yields a completely different wallet from the same words.

—

Private key BIP-32 / BIP-44

BIP-32 builds a tree of keys from the seed: each node is a private key plus a chain code, and children come from HMAC-SHA512, so one seed deterministically regenerates every key. BIP-44 fixes the shape m / purpose' / coin_type' / account' / change / address_index (here 60' = Ethereum). An apostrophe marks a hardened child. This is key derivation: many keys, one backup.

—

Public key secp256k1

secp256k1 is the curve y² = x³ + 7 over a 256-bit prime field. The private key is multiplied by the fixed generator: Q = kG. That is public-key cryptography — the pair used for ECDSA signatures — and it is one-way thanks to the ECDLP, exactly the mechanism of HW1 at full scale.

—

Uncompressed public key (65 bytes, 0x04 prefix):

—

Address Keccak-256

Keccak-256 is a cryptographic hash. Ethereum hashes the uncompressed public key (64 bytes, the 0x04 prefix dropped) and keeps the last 20 bytes as the address. This is hashing: a one-way, fixed-size fingerprint that shrinks a 64-byte key into a 20-byte identifier.

— —

Checksummed address EIP-55

EIP-55 encodes a checksum in the capitalisation of the hex letters: hash the lowercase address with Keccak-256 and uppercase each letter when the matching hash nibble is ≥ 8. A single mistyped character almost always breaks the pattern. This is a checksum for error detection — not a security mechanism.

—

Derivation paths (BIP-44)

The address_index at the end of the path selects which address you get. Incrementing it walks down the same account, producing a fresh, unrelated-looking address each time — all recoverable from the one seed.

First addresses of the current account

Path	Address

EIP-55 in action

Checksum playground

Address (0x + 40 hex chars)

The mixed-case form is the checksum. Change one letter's case and re-checking the checksum rejects the address — which is how a mistyped address is usually caught before you send funds.

Keccak-256: statistics of a hash

Unlike scalar multiplication, a cryptographic hash is expected to behave like a random function. These two experiments show the properties that are meaningful for a hash — and that HW1's curve arithmetic does not have.

Avalanche effect

Message

Distribution of flipped output bits (out of 256) after toggling one input bit. A good hash centres sharply on 128 ≈ 50%.

Example — differing characters highlighted:

— —

Output uniformity

Message prefix

Frequency of the 256 possible output-byte values over many inputs. Flat ≈ each value equally likely.

Context and distinctions

Chronological context

1977

RSA — public-key cryptography goes mainstream.

2001

SHA-2 / SHA-512 — standardised hash family.

2012

BIP-32 — hierarchical deterministic wallets.

2013

BIP-39 — mnemonic codes for deterministic wallets.

2014

BIP-44 — multi-account derivation paths.

2015

SHA-3 — standardised by NIST, based on Keccak.

2016

EIP-55 — mixed-case checksum addresses.

Who does what

Concept	Role in the pipeline
Key generation	BIP-39: entropy → mnemonic → seed. Creating the root secret.
Key derivation	BIP-32 / BIP-44: one seed → a deterministic tree of private keys.
Public-key cryptography	secp256k1: Q = kG, the key pair and ECDSA signatures.
Hashing	Keccak-256: one-way fingerprint, public key → 20-byte address.
Checksum	EIP-55: mixed-case letters, catches typos in an address.
Encoding	hex / Base58 / Bech32: how bytes are written down for humans.

SHA-2 vs Keccak / SHA-3, and why so many algorithms

SHA-512 and Keccak are both cryptographic hashes but built differently. SHA-2 uses a Merkle–Damgård construction; Keccak uses a sponge. After a public competition, NIST selected Keccak as the basis of SHA-3 (2015). Ethereum, though, uses Keccak-256 with the original padding, which is not the same function as the standardised SHA3-256: the final domain-separation/padding byte differs, so the digests differ. Same permutation, different padding — a classic gotcha.

Why not one algorithm for everything? Each primitive answers a different question and fails in different ways. BIP-39/32/44 handle key management (one backup → many keys); secp256k1 provides the public/private relationship and signatures; Keccak-256 compresses a key into a short collision-resistant identifier; EIP-55 adds cheap error detection. Keeping them separate keeps each concern auditable and lets any one layer change without breaking the others.