How to move from SeedAddress to a new wallet

Learn how to move funds from a SeedAddress input-derived mnemonic to a new wallet initialized with random entropy, verifying the backup and keeping access throughout the process.

How to move from SeedAddress to a new wallet

Moving from SeedAddress to a new wallet means creating the new wallet with securely generated random entropy, checking its offline backup, and transferring funds afterwards. Do not turn an existing phrase into another one by appending words, or change a SeedAddress password or location while expecting to keep the same wallet: those changes can produce another phrase. Keep the old wallet available until you have confirmed that the new backup restores access and that every balance has reached its new addresses.

Why you might migrate

A new BIP39 wallet should receive entropy from a secure random source. The BIP39 specification describes how that entropy becomes a mnemonic and how the mnemonic can produce a binary seed; security depends on the quality of the initial entropy, not on the result having many words. Many modern HD wallets then derive keys deterministically from that seed: BIP32 describes a key tree from a single seed, which is initially generated from a random source. Deterministic key derivation is different from obtaining the seed from a predictable location or password.

SeedAddress has a different purpose. In the browser, its v1 method derives a mnemonic from the selected coordinates, password, language and word length. It uses a precision-9 geohash and HMAC-SHA256; the address is public information and the method adds no random entropy. A 24-word phrase produced this way does not automatically gain 256 bits of random entropy. The guide to BIP39 word length and entropy explains the distinction.

You can keep SeedAddress for studying derivation or reproducing a known result, but a new wallet initialized with random entropy provides a different starting point for self-custody. Migration does not repair a lost backup, a weak password or a compromised device; it establishes a new root and a backup procedure you can verify.

What to prepare before moving funds

Make an inventory without copying secrets into a website, screenshot or synchronized note. Identify the networks and accounts you use, known public addresses, approximate balances and any asset that requires a separate transfer. On UTXO networks, remember that a wallet can hold multiple outputs; on token networks, review the assets and permissions associated with each account. This list is for checking the result, not for sharing with support.

Keep access to the old wallet. If it only opens on one device, do not erase or reset that device to test a new backup. Bitcoin.org's wallet-backup guidance recommends keeping complete backups in secure locations. Trezor's wallet-backup guidance also says that recovery words must remain private and protected from loss or damage.

If the old wallet depends on SeedAddress, independently keep the mnemonic that already works and the recovery data required by the v1 method: coordinates, password, language and word length. The current interface cannot paste historical coordinates to replay a recovery, and a provider may return different coordinates for the same place name. Do not assume that changing from 12 to 24 words creates a backup of the same wallet.

Create and verify the new wallet

1. Generate a new wallet in a trusted environment

Use a wallet or device that supports your networks, and let it generate the mnemonic from its secure random source. Check whether it uses BIP39 or another format, how many words it requires and whether it supports an optional passphrase. BIP39 and SLIP39 are different standards: a 20-word SLIP39 backup or set of shares is not restored as a 12- or 24-word BIP39 mnemonic.

Write the words on durable, private physical media. Do not enter them into SeedAddress to “convert” them, compare wallets or check whether they match. Do not send them to someone claiming to be support either: Ledger explains how to protect a recovery phrase. A legitimate company can explain a procedure without asking for your words.

2. Check the backup before funding it

Use the device's backup-check feature when available. If you need to restore, use a trusted spare device and follow the manufacturer's documentation. Do not erase the only working device to test an unverified backup. A phrase can have a valid checksum and still belong to a different wallet; this offline-backup guide explains the difference.

Obtain a public address from the new wallet and compare it with the device or application that generated it. If you use a BIP39 passphrase, record separately that it belongs to the procedure: every passphrase produces a different valid wallet, and a typo can show an empty wallet. Do not confuse that passphrase with a device PIN or the SeedAddress input password; the comparison of these concepts explains their roles.

Transfer using a verification path

Send a small test amount first, sized so you can accept the loss if you enter a wrong address. Check a trusted explorer for that same network for confirmation and verify that the new wallet can show or spend the transfer as expected. Confirm the complete receiving address on the new wallet or device and the transaction destination on the old signing device, rather than trusting a clipboard value or a saved contact name. Before moving tokens, NFTs or other operations that depend on the old account, keep enough of that network's native currency there to pay its fees; on Ethereum, for example, gas fees are paid in ETH (gas documentation). Each network has its own rules.

After the test succeeds, transfer the remaining funds in reasonable batches and review each network, account, asset and fee. A confirmed transfer to the wrong address usually cannot be reversed. Do not share the mnemonic to speed up a recovery or use a website that promises to recover funds in exchange for it.

Keep the old wallet until you have checked every balance and application that depended on it. Before retiring it, update saved receiving or withdrawal addresses in the services you use. Importing the old phrase into a new app does not rotate its keys or fix predictable initial entropy. When possible, perform a second recovery from the new backup, compare a known public address and confirm that the physical backup remains readable. Only then should you remove the old wallet from normal use; decide how to retain or destroy its backup according to your threat model and any record-keeping obligations.

What changes in SeedAddress

Changing the coordinates, password, language or word count changes the derivation input and can produce another mnemonic. Two points inside the same precision-9 geohash cell can match, while a coordinate change can separate the results. The application does not keep a recoverable copy on a server and does not replace an independent offline backup.

That is why migration means moving funds to new addresses controlled by a backed-up wallet initialized with random entropy, not asking SeedAddress to make a phrase “more secure”. The SeedAddress input-derived mnemonic may still be needed to sign the transfer. If you no longer have access to it, preserve the exact inputs you do have and use official procedures; no article can reconstruct an unknown password or an unrecorded coordinate.

Frequently asked questions

Does importing the old phrase into a new app complete the migration?

No. Importing it keeps the same keys and addresses; it does not rotate keys or fix predictable initial entropy. Create a new wallet with random entropy, verify its backup and transfer the funds.

Do I need to delete SeedAddress after migrating?

Deleting it is not required to complete the transfer. Keep only the documentation and backups you need, avoid exposing secrets, and treat the old phrase as compromised if you ever entered it into a website or shared it.

Does migration guarantee that I will not lose funds?

No. It reduces dependence on SeedAddress's input-derived mnemonic when you complete a verified new backup initialized with random entropy, but each address, network, signature and backup still needs checking. Self-custody continues to require procedures and independent backups.