What to Do if Your Seed Phrase Is Exposed
Learn what to do when a seed phrase may be exposed: how to prioritize moving funds to a new wallet and which changes do not revoke its keys.
If you typed a seed phrase into a website, sent it in a chat, photographed it with a connected device, or suspect that someone else saw it, treat it as compromised. Changing a device PIN or an app password is not the response: those controls can block local access, but they do not replace keys that can already be reconstructed from the copy. The decisive step is to prepare a new wallet with a new backup and move the funds from a verified environment.
What an exposed phrase means
A BIP39 phrase is a backup that can reconstruct a binary seed and, from it, the keys of a deterministic wallet. The BIP39 specification separates mnemonic generation, which is meant to carry computer-generated entropy, from the later conversion to a seed. A readable copy can therefore be enough for someone to attempt restoring the same wallet in another device or application.
A hardware-wallet PIN, an application password and a seed phrase have different jobs. Changing the PIN may stop someone from using the device in front of you, but it does not invalidate a copy that already left it. Changing an account password does not rotate self-custody keys. An additional BIP39 passphrase is a separate input: the mnemonic combined with the correct passphrase derives a distinct wallet. If only the mnemonic was exposed and the passphrase remains secret, the risk depends on keeping that passphrase secret and strong; if both were exposed, that wallet is compromised. Adding a passphrase later does not protect addresses already used.
What to do first
Move in order and avoid creating another leak while addressing the first one.
- Stop entering the phrase. Close the page, chat or application that requested it. Do not paste it into an online checker, support ticket, screenshot or “recovery” tool. If the computer or phone may contain malware, use another device you can verify and update or reinstall software from its official source.
- Assess the situation without revealing the secret. You can watch public addresses or balances from a watch-only wallet, but do not type the phrase again to “confirm” that it works. List the assets and networks that must move without copying recovery words into your notes.
- Create a new wallet. Use an application or device obtained from its official source and a random-entropy generation process. Write the new backup offline, verify that its documented recovery procedure works, and store it privately. Do not reuse the exposed phrase, a variation of it or a password derived from it.
- Verify each destination before sending. Show the full address on the device that controls the new wallet and confirm the network and asset type. Follow the official transfer procedure; a public address copied from a message or a network mismatch can send funds elsewhere.
- Retire the old root. A copied BIP39 phrase cannot be invalidated by changing a local setting: its derived accounts remain controlled by the same keys. After checking every asset, network and pending or locked position that depends on them, stop using every account derived from the exposed backup, not just one receiving address. Do not wipe or discard the old signer or backup yet; keep it until that review is complete, then follow the manufacturer’s instructions to wipe or retire it.
The Trezor guide to moving crypto to a wallet with a new backup recommends treating a suspected backup leak as a compromise and moving funds promptly, because delay gives an attacker more time to drain them. The exact sequence depends on the device and network, so use the provider’s documentation to confirm each step and destination.
If incoming funds disappear immediately or you suspect an automated sweeper, do not top up the compromised account with ETH or another token just to pay gas: the bot may spend it instantly. MetaMask explains this pattern and its limits; consult network-specific documentation or experienced technical help before attempting an urgent operation, and do not improvise scripts that promise rescue.
Changes that do not revoke exposure
These mistakes are especially common:
- Changing an app password or device PIN protects a session or device, but does not change the seed or the keys that can already be derived.
- Restoring the same phrase on another device creates another copy of the same secret. It can restore access, but it cannot repair a compromise.
- Creating another account with the same phrase still uses the exposed backup and, with the same passphrase, the same key root. It is not an independent new wallet.
- Changing SeedAddress inputs creates another deterministic derivation, but does not make the old phrase safe. If the old wallet holds funds, move them first to a new wallet initialized with random entropy and verify the destination backup.
SeedAddress’s specific boundary
SeedAddress derives a mnemonic in the browser from selected coordinates, a password, language and word count. Its v1 implementation uses a precision-9 geohash and an HMAC-SHA-256-based derivation. The public place adds no fresh random entropy, and SeedAddress produces only the mnemonic: it does not create private keys, xpubs or receiving addresses.
If a SeedAddress phrase is exposed, preserving the exact coordinates, language, word count and password may help reproduce it, but it also makes clear why the phrase must be treated as a compromised secret. Changing any input may produce another phrase; a small coordinate change can even leave it unchanged when it stays in the same geohash cell. No input change revokes the first phrase or moves its funds. For incident response, the guide to moving from a deterministic wallet explains how to move to a new wallet with random entropy; the SeedAddress recovery guide explains input compatibility, not a reason to keep an exposed phrase holding funds.
SeedAddress has no validator or importer for existing phrases and cannot repair an exposure. Test the flow only with valueless inputs and keep any important backup offline. The guide to checking a BIP39 backup without exposing it explains the limits of online checkers and the role of a trusted recovery process.
Final incident checklist
Before considering the incident closed, confirm that:
- the new backup was generated from random entropy and is stored offline;
- you can restore it with the official procedure without publishing the words;
- you verified addresses, networks and balances in the new wallet;
- no funds remain dependent on the exposed phrase;
- you stopped using its addresses and removed the cause of the leak.
If you cannot complete a step, do not send funds to an unverified destination or improvise recovery scripts: consult the official documentation for the relevant device or network. Do not send the phrase to someone who promises to recover funds: asking for the secret expands the incident.