MyEtherWallet Recovery: Lost Seed & Forgotten Password

What remained was a fragmented memory: pieces of a seed phrase and the surrounding context, deliberately kept vague here to protect the client. The seed itself was gone, along with the BIP-39 passphrase that had protected the wallet since 2017 — a time when losing either meant working it out yourself, with no app and no support line to fall back on.

That fragment turned out to be material. Here is why.

A partial seed is structured, not random

A recovery phrase is not a password that must be remembered exactly or not at all. It encodes entropy in a fixed structure, and the structure narrows the search.

Every word comes from the same list of exactly 2,048, and the phrase carries a checksum computed from the entropy itself — the first ENT/32 bits of its SHA-256 hash. Any reconstruction that does not satisfy that checksum is provably not a real phrase and can be discarded before any key is derived.

There is a second constraint that people rarely know about: the BIP-39 wordlist is built so that the first four letters of every word are unique. We verified this against the published list — all 2,048 words, no collisions. So "I think it started with aban…" is not a vague memory. It is an exact identification of one word out of 2,048.

Between those two properties, a phrase remembered in fragments becomes a constrained reconstruction rather than an open-ended guess.

Finding the wallet, not just a wallet

Reconstructing a valid phrase is only half the work. A valid phrase is a wallet — not necessarily the one you are looking for. In this case, we verified it by deriving addresses and matching the client’s known address.

Ethereum's standard derivation follows BIP-44, which defines the path as m / purpose' / coin_type' / account' / change / address_index, with SLIP-44 registering coin type 60 for Ether. That gives the familiar m/44'/60'/0'/0/0 for a first account.

This matters more than it sounds. Wallets have historically differed in which paths they scan by default, which is why a correctly restored phrase can still show an empty wallet — the funds are sitting at a path the software never looked at. A restored phrase showing zero balance is very often a derivation problem, not a lost wallet.

We rebuilt the phrase from what remained, filtered candidates through the checksum, derived addresses across the standard paths, and compared them against the client's known address until one matched. Access was restored.

What changes the feasibility of a similar case

• No known address. A known receiving address or transaction record makes verification easier. Without one, an address database for a supported blockchain or other usable verification material may still identify candidates; the available evidence has to be assessed.
• A forgotten BIP-39 passphrase. This optional addition creates a different wallet from the same phrase. Useful clues about its spelling or structure can make a targeted search assessable; a long, random passphrase with no clues may be infeasible.
• Memory of the sense rather than the words. "Something about animals and colours" may not narrow the search enough on its own. "The third word began with stad" gives a much more specific clue. Feasibility depends on how many words and positions are known and what other clues remain.

What this means if you are in the same position

Write down whatever you actually remember before it degrades further — partial words, positions, anything. Four letters of a word is a whole word. And find any address the wallet used: an old exchange withdrawal, a block explorer bookmark, a receipt from someone who paid you. A known address gives a direct way to verify candidates. If none can be found, the assessment must establish whether other usable verification material is available.

See the seed phrase recovery service and the recovery methods guide.