Safe Wallet Migration Checklist: What to Do If Your Recovery Phrase May Be Weak or Exposed
A safe wallet migration checklist begins with one rule that prevents many failed recoveries: do not import a suspect recovery phrase into a new wallet and assume the problem is fixed. If the old phrase was leaked, phished, generated with weak randomness, exposed to malware, copied into an unsafe device, or otherwise no longer trustworthy, every account derived from it may remain at risk. A proper migration creates a genuinely new wallet from independent secure randomness, verifies the new receiving addresses, inventories assets and permissions across every relevant chain, moves funds carefully, documents what changed, and retires the old root so future deposits do not flow back into compromised addresses.
TL;DR
- Do not restore a suspected weak or exposed recovery phrase into a different wallet and call that migration. The same phrase derives the same underlying keys.
- First identify the risk type: confirmed seed leak, phishing, weak seed generation, device compromise, suspicious approval, unexplained drain, smart-contract incident, or an issue that is still unresolved.
- If the seed itself may be compromised, assume relevant accounts derived from that seed can also be compromised, even if some addresses currently look untouched.
- Generate the destination wallet from completely independent cryptographically secure randomness using current, trustworthy software or dedicated signing hardware.
- Write the new recovery phrase offline. Do not photograph it, email it, save it in ordinary cloud notes, paste it into a browser checker, or send it to anyone helping with the migration.
- Never type the old recovery phrase into a wallet-risk scanner or vulnerability checker. Public wallet investigation should use public addresses and transaction hashes.
- Verify the new wallet's receiving address carefully before moving substantial value. When practical, make a small test transfer before the larger migration.
- If a wallet is actively being drained, speed matters. A perfect forensic investigation is less valuable than protecting remaining assets, but destination verification still matters.
- Inventory native coins, fungible tokens, NFTs, staking positions, lending deposits, liquidity positions, vault shares, bridge balances, claimable rewards, and secondary accounts across every chain used by the old seed.
- Review ERC-20 allowances and other permissions before and after migration. Token approvals can remain active independently of a wallet's website connection state.
- Review ERC-721 and ERC-1155 operator approvals when NFTs are involved. Operators may have authority over more than one asset.
- On Solana, separately review token delegates, authorities, token accounts, program interactions, and any relevant Token-2022 features. EVM approval terminology should not be applied blindly to Solana.
- Decode large or unfamiliar EVM transactions before signing when possible. Understand the destination, method, approvals, token movements, internal execution, and likely outcome.
- If the incident involves an upgraded spender, smart account, router, proxy, or protocol contract, contract comparison can help determine whether on-chain code changed.
- After migration, update exchange withdrawal whitelists, payroll destinations, saved contacts, payment pages, ENS records where relevant, donation addresses, business invoices, validator or mining payouts, and other systems that may still send funds to the old wallet.
- A migration is complete only when assets, permissions, future deposit routes, and operational records no longer depend on the compromised root.
If you enter the same recovery phrase into another app, computer, phone, browser extension, or hardware wallet, you have moved the interface, not the cryptographic authority. If the original phrase is compromised or predictable, the attacker can still derive the same keys independently.
What safe wallet migration actually means
Crypto users often use the word migrate for several very different actions. Sometimes it means importing the same seed into a different application. Sometimes it means transferring one token to a new address. Sometimes it means moving from a hot wallet to hardware. Sometimes it means changing networks.
When the security problem involves a recovery phrase, the definition needs to be stricter.
A true security migration replaces the root secret.
The old wallet may contain many addresses. Those addresses may exist on several blockchains. They may have permissions granted to protocols, open positions, NFTs, staking accounts, future payment routes, saved exchange destinations, and applications that still recognize the old address as the user's identity.
Moving one ETH balance does not automatically move the rest of that security state.
Migration should remove dependence on the old root
If the old phrase is considered unsafe, the goal is not merely to make its current balance zero. The goal is to ensure that valuable assets and future workflows no longer rely on keys derived from it.
The secure migration sequence
The safest process separates diagnosis, new-wallet generation, verification, asset transfer, permission cleanup, and retirement. Each step solves a different part of the problem.
Classify the incident
Determine whether you are dealing with a leaked seed, weak generation, phishing, malicious approval, device compromise, contract incident, or unexplained drain.
Create a new root
Generate an entirely independent recovery phrase using current trustworthy wallet software or dedicated signing hardware.
Protect the new phrase
Record it offline and keep both the old and new recovery phrases out of websites, scanners, chat messages, screenshots, and support tickets.
Inventory the old wallet
List every chain, account, token, NFT, staking position, DeFi position, approval, delegate, and future deposit route.
Verify the new destination
Check the address independently and make a small test transfer when time and risk conditions allow.
Move assets carefully
Prioritize according to value and active threat, while decoding unfamiliar transactions before signing where practical.
Retire the old root
Update payment routes, document the migration, monitor old addresses, and do not reuse them for valuable future deposits.
Step 1: identify what type of wallet risk you are dealing with
Not every wallet-security incident requires complete seed migration.
If one ERC-20 token moved because a previously approved spender used transferFrom, the root seed may still be private. If an upgradeable protocol contract malfunctioned, users may have lost assets without any individual private key being compromised.
By contrast, if the recovery phrase was entered into a phishing site or generated by software with a confirmed weak-randomness vulnerability, the root itself is suspect.
Confirmed seed disclosure
If you knowingly entered the recovery phrase into a phishing page, sent it to a fake support agent, stored it in an account that was compromised, or exposed it to untrusted software, assume the phrase can be known by another party.
A private phrase does not become private again because the phishing page disappears.
Weak recovery-phrase generation
A wallet-generation vulnerability is different from a leak. The user may never have shown the phrase to anyone.
If the original random generator was predictable, an attacker may be able to reconstruct the same secret independently.
Changing the wallet password or moving the same words into another application does not repair this problem.
Device or malware exposure
If malware may have accessed a computer or phone while the recovery phrase or private key was visible, determine whether the secret itself could have been captured.
A clean reinstall afterward cannot prove that an attacker did not already copy the key.
Suspicious token approvals
An unwanted ERC-20 allowance, NFT operator, permit signature, or other delegated permission may create asset risk without exposing the seed.
Approval incidents still deserve urgent containment, but they should not automatically be diagnosed as root-key compromise.
Unknown wallet drain
If assets moved without authorization and the mechanism is unclear, investigate first using public evidence.
The TokenToolHub Wallet Risk Scanner can help review supported EVM wallet activity, counterparties, assets, funding evidence, approvals, and risk indicators, while the Transaction Decoder can help explain suspicious transaction execution.
Should you replace the seed?
| Situation | Is full seed migration justified? | Reasoning |
|---|---|---|
| Recovery phrase entered into known phishing site | Yes | The root secret should be treated as disclosed. |
| Recovery phrase generated by confirmed weak RNG | Yes | The root may be independently recoverable even if the user never leaked it. |
| Private key copied into untrusted software | Usually yes for that key, and potentially broader if root seed was exposed | Once the private signing material is exposed, continued exclusivity cannot be assumed. |
| One malicious ERC-20 allowance | Not automatically | Delegated token authority can be abused without private-key compromise. |
| One suspicious contract interaction | Depends on evidence | Decode the transaction and review permissions before assuming root compromise. |
| Several unrelated assets directly swept from wallet | Strongly consider migration | Broad directly signed unauthorized activity can indicate compromised signing authority. |
| Several chains associated with same seed drain close together | Strongly consider migration | Cross-chain loss can be difficult to explain with one chain-specific allowance. |
| Protocol exploit affects many users but wallet keys remain private | Not necessarily | The failed security boundary may be the protocol rather than individual wallet keys. |
Step 2: generate a truly new wallet
If root compromise is credible, the destination must be cryptographically independent of the old wallet.
That means generating a new recovery phrase, not selecting create account inside the old wallet tree.
Do not reuse the old words
A recovery phrase deterministically derives keys. Reusing the phrase reproduces the same security root.
Do not rearrange the old words
Trying to improvise a new phrase by rearranging words, replacing a few words, combining two phrases, or manually constructing a mnemonic introduces human bias and can create invalid or weak secrets.
Do not generate the replacement on a random website
A migration prompted by suspected key compromise is the wrong moment to trust an unknown browser generator.
Use current wallet software obtained from authentic sources or a dedicated hardware device with a well-established generation process.
Use a clean environment
If the old wallet may have been exposed through malware, do not create the new root in the same untrusted environment without remediation.
Use a clean updated device or dedicated hardware where appropriate.
Using a hardware wallet for the new root
Dedicated signing hardware can reduce the amount of sensitive key material exposed to a general-purpose computer.
For users replacing a potentially weak or exposed software wallet, a current device such as Ledger can be one option for generating an independent recovery phrase inside dedicated hardware and keeping signing keys separated from the browser or desktop environment.
The critical security decision is to initialize the device with a new recovery phrase when the old phrase is suspect.
Restoring the old phrase is recovery, not remediation
Restoring an existing phrase can be appropriate when the original phrase is known to be secure and the user simply replaced a damaged device.
It is not the correct fix for a phrase that may already be exposed.
Step 3: record the new recovery phrase offline
Generating a strong new secret is only useful if it remains secret.
The migration process can create pressure to move quickly, and rushed users often create a fresh vulnerability while trying to escape the old one.
Do not photograph the new phrase
A phone photo may be synchronized to cloud storage, scanned by image services, backed up automatically, exposed through device compromise, or remain accessible long after the migration.
Do not email it to yourself
Email accounts are online systems with their own credentials, recovery mechanisms, connected applications, archives, backups, and compromise risks.
Do not paste it into chat
No support agent, security analyst, wallet scanner, AI assistant, Telegram admin, Discord moderator, exchange employee, or protocol developer needs the recovery phrase to examine a public blockchain address.
Keep the old phrase private too
Even when a seed is suspected compromised, publishing it can create additional risk to assets that have not yet been migrated or accounts you forgot existed.
A legitimate wallet-risk workflow can begin from a public EVM or Solana address. If a checker demands recovery words, private keys, authentication codes, or wallet passwords, do not use it.
Test the recovery process before moving major value
A migration can fail in another direction if the new wallet is secure but unrecoverable.
Before relying on the destination for substantial value, confirm that the backup was recorded correctly and that you understand the product's recovery procedure.
Do not perform testing through untrusted websites or environments.
Step 4: inventory everything before moving funds
One of the most common migration mistakes is moving what is visible in the current wallet interface and assuming the job is finished.
A recovery phrase may control far more than the home screen shows.
List every blockchain used
Include Ethereum, BNB Chain, Base, Arbitrum, Optimism, Polygon, Avalanche, Solana, Bitcoin, Tron, and any other network historically used with the seed.
List every account index used
Some users create several accounts under the same recovery phrase. Each account has a different address but shares the same root.
List native assets
Native coins are needed for value and for transaction fees. Leaving insufficient gas can make later migration transactions difficult.
List tokens and NFTs
Include small balances. Attackers can automate searches more systematically than users manually review their portfolios.
List DeFi positions
Assets may be represented through lending deposits, LP tokens, staking contracts, vault shares, collateral, synthetic assets, claimable rewards, vesting contracts, bridges, or protocol-specific positions.
List operational dependencies
Exchange whitelists, OTC settlement addresses, invoices, payroll records, validator rewards, mining payouts, marketplace profiles, ENS records, donation addresses, contact books, and recurring transfers can keep pointing toward the old wallet after current balances are gone.
Use public wallet scans to improve the inventory
Before sending transactions from the old wallet, use read-only public data where possible to understand what is present.
The Wallet Risk Scanner can help inspect supported EVM wallet assets, activity, approvals, counterparties, funding evidence, and risk indicators without requiring a wallet connection or private credential.
For Solana, the Solana Wallet Risk Scanner can help review public token exposure, activity, counterparties, delegates, authorities, staking context, and supported wallet-risk evidence.
These tools can improve migration visibility, but neither can certify the private entropy of the old or new recovery phrase.
Step 5: verify the new receiving address before moving high-value assets
Destination verification is one of the most important migration steps because sending assets to the wrong address can turn a security response into an irreversible loss.
Do not trust the clipboard alone
Clipboard-replacement malware can substitute an attacker address after the user copies a legitimate destination.
Compare the address displayed by the receiving wallet with the address shown in the sending interface.
Use a trusted device display where supported
Hardware wallets can display receiving addresses independently of the potentially compromised computer screen.
Check the network
A correct address on the wrong network can still create recovery problems, especially when assets or applications do not support the destination chain.
Make a test transfer when practical
A small test can verify that the destination is correct and accessible before transferring a substantial balance.
Wait for suitable confirmation and then verify that the funds appear in the intended wallet.
What changes if the wallet is actively being drained?
An active attacker changes the tradeoff between careful sequencing and speed.
If multiple unauthorized transfers are already occurring, the risk of leaving assets in place may exceed the risk of skipping optional investigative steps.
Protect the destination setup first
Do not rush so fast that you send to an address you have not verified or generate the new wallet in the same compromised environment.
Prioritize assets strategically
High-value and highly liquid assets may deserve priority, but migration order also depends on gas requirements, protocol constraints, withdrawal delays, staking locks, and whether the attacker appears to be targeting specific asset classes.
Do not compete blindly with an attacker
Repeated failed rescue attempts can consume gas or reveal intentions. When substantial value or complex smart-contract positions are involved, specialized incident-response assistance may be appropriate.
How to choose a migration order
There is no universal ordering that fits every portfolio, but a structured approach is better than random transfers.
| Asset or position | Priority considerations | Common mistake |
|---|---|---|
| Native coin | Needed for gas and may itself hold significant value | Moving all gas too early and leaving tokens stranded |
| Large liquid tokens | Easy for attackers to sweep and usually easy to transfer | Forgetting that some tokens need special transfer or compliance behavior |
| NFTs | May have high value and operator approvals | Assuming one collection transfer covers all NFTs |
| Staking positions | May require unstaking, cooldowns, claim steps, or separate withdrawal credentials | Leaving claimable rewards under old wallet |
| Lending and collateral | Withdrawal can affect health factor or outstanding debt | Withdrawing collateral without managing debt first |
| Liquidity positions | May require removing liquidity and claiming fees | Moving LP representation without understanding protocol mechanics |
| Bridge positions | Funds may be pending, delayed, or claimable on another network | Closing the old wallet before destination-side claim completes |
| Small balances | Lower individual value but easy to forget | Assuming an attacker will ignore them forever |
Do not strand assets by moving all gas first
EVM networks require native gas for many transactions.
If you send every last unit of ETH, BNB, MATIC, AVAX, or another gas asset before transferring tokens or interacting with protocols, you may lose the ability to complete later migration steps without funding the old address again.
Plan enough gas for the full sequence.
Keep only what is operationally necessary
Leaving excess native value in a compromised wallet creates exposure. Estimate the remaining transactions and reduce the balance as the migration progresses.
Step 6: decode large or unfamiliar EVM transactions before signing
Migration can require more than simple transfers. Unstaking, withdrawing collateral, removing liquidity, claiming assets, revoking permissions, or interacting with bridges may involve contracts.
Do not assume every transaction presented during an emergency is safe merely because you initiated the workflow from a familiar website.
Understand the transaction destination
Confirm whether you are calling the expected token, router, vault, bridge, marketplace, staking contract, or approval manager.
Understand the method
Know whether you are transferring, approving, withdrawing, unstaking, swapping, bridging, claiming, granting operator access, or performing a multicall.
Understand token movement
A contract interaction can create internal transfers that are not obvious from the outer transaction value.
Use Transaction Decoder when you have a hash
The TokenToolHub Transaction Decoder can help explain supported EVM transaction methods, token movements, approvals, internal execution, fees, traces, and transaction consequences after a transaction exists on-chain.
For planned high-value interactions, use wallet simulation and trusted protocol interfaces where available before signing, then independently verify the confirmed transaction afterward.
Step 7: review ERC-20 approvals and token permissions
Moving tokens to a new wallet naturally leaves the old token balances behind, but understanding approvals still matters for incident analysis and for any assets that remain temporarily during migration.
ERC-20 approve allows a spender to withdraw up to a specified allowance from an owner's balance. The transferFrom function enables the spender to exercise that permission.
Old approvals do not transfer automatically to the new wallet
Allowances are tied to the owner address, token contract, spender, and network.
A new address starts with its own permission state.
This is an opportunity to rebuild application access according to least privilege instead of recreating every old unlimited allowance.
Review the current live allowance
The TokenToolHub Approval Allowance Checker can read the live ERC-20 allowance for a specific owner, token, spender, and network.
Do not revoke blindly
Revocation is itself an on-chain transaction. Confirm the spender and token before signing.
Why old-wallet approvals still matter after most funds move
If a compromised old address later receives the same token again and an allowance remains active, the spender may still have authority according to the token's current allowance state.
This is another reason not to reuse retired addresses.
Review NFT operator permissions separately
ERC-721 includes both per-token approvals and setApprovalForAll, which can authorize an operator to manage an owner's NFTs. ERC-1155 similarly supports operator approval over an owner's token set.
These permissions differ from ordinary ERC-20 allowances.
Collection-wide operator access can be broad
A malicious or compromised operator may be able to transfer multiple eligible NFTs rather than only one asset.
Moving NFTs to the new wallet resets the ownership context
The destination address has its own approval state. Do not automatically recreate every marketplace or protocol operator from the old wallet.
Remember signature-based permissions
Some token ecosystems allow permissions to be created through typed signatures such as permit flows.
A signature can be security-sensitive even when the signing action itself does not consume gas or immediately move assets.
Emergency migration is not the time to sign unexplained messages
Fake security pages often ask users to sign messages supposedly required to secure or synchronize a wallet.
If you do not understand what authority the signature creates, do not sign it merely because the interface presents the action as recovery.
EVM migration notes
EVM migration usually involves several independent states: the wallet's native coin, ERC-20 token balances, NFTs, approvals, smart-contract positions, and activity on multiple networks.
Each EVM network is separate
The same 0x address may exist across Ethereum, Base, Arbitrum, BNB Chain, Polygon, Optimism, Avalanche, Gnosis, Linea, Scroll, and other networks.
Moving assets on Ethereum does not move assets on Base.
Approvals are network-specific
An allowance on Ethereum is not the same allowance on Arbitrum, even when token names and wallet addresses look similar.
Protocol positions can hide value
A wallet interface may show a small token balance while a much larger amount sits inside lending collateral, staking, vaults, liquidity pools, or claimable rewards.
Smart accounts need additional review
If the wallet uses smart-account modules, session keys, guardians, delegated implementations, or upgradeable execution logic, migrating the human recovery phrase may not be the only security action required. Review the account architecture and every authority that can initiate execution.
Use Smart Contract Diff when code changes are part of the incident
Sometimes migration is triggered not by a leaked seed but by concern that a spender, wallet implementation, protocol contract, router, or proxy changed behavior.
The TokenToolHub Smart Contract Diff and Upgrade Analyzer can help compare supported EVM contracts and identify differences in verified source, ABI, permissions, proxy state, token controls, and runtime bytecode.
Contract risk and seed risk are different
A compromised spender can endanger approved tokens without knowing the user's recovery phrase.
A compromised seed can authorize entirely new transactions regardless of existing spender permissions.
Determine which security boundary failed before recreating application relationships on the new wallet.
Solana migration notes
Solana uses a different account and token model, so EVM terminology should not be copied mechanically.
If a recovery phrase controls Solana accounts, review them independently as part of root migration.
Review SOL and SPL token balances
Include associated token accounts, less visible token balances, staked SOL, protocol positions, and any assets not displayed prominently by the current wallet interface.
Review token delegates
Solana token accounts can authorize delegates to transfer or burn a limited amount of tokens. Solana's token tooling supports approving and revoking delegates.
If a delegate is no longer trusted, review the appropriate account state and remediation path.
Understand mint-level authority and extensions
Token-2022 introduces extensions that can create behaviors different from ordinary token accounts. For example, a permanent delegate can be configured at the mint level and is not a permission that an individual token-account owner can simply revoke.
Do not interpret every unusual token movement as a compromised wallet without understanding the mint's rules.
Review program interactions
Solana transactions can contain several instructions and program calls. Swaps, aggregators, staking, token-account management, compressed assets, DeFi protocols, and custom programs can all produce complex histories.
Use public wallet intelligence as an inventory aid
The Solana Wallet Risk Scanner can help inspect supported public activity, counterparties, funding patterns, authorities, delegates, and risk evidence without requiring the recovery phrase.
Be careful with bridges during migration
Bridging introduces more moving parts than a same-chain transfer.
Assets may be locked on a source chain, represented differently on the destination, routed through third-party liquidity, delayed, or require a later claim transaction.
Do not bridge merely to avoid creating a destination account on the same chain
If the new wallet supports the existing network, a direct same-chain migration is often operationally simpler than introducing a bridge solely for migration.
Verify bridge contracts and destination chain
Fake bridge interfaces are common phishing vectors.
Step 8: document what moved
A migration involving several networks becomes difficult to track from memory.
Maintain a non-secret record of the process.
Useful migration records
- Old public address.
- New public address.
- Blockchain network.
- Asset or position migrated.
- Transaction hash.
- Date and time.
- Whether the position is fully migrated.
- Whether a claim, unstake, bridge, or cooldown is still pending.
- Whether external deposit destinations have been updated.
- Whether the old address must remain monitored temporarily.
Do not include the recovery phrase or private key in this migration record.
Step 9: update every future deposit route
Many incomplete migrations fail weeks or months after the user believes the incident is over.
The old wallet receives new funds because another service still has the old address saved.
Exchange withdrawal whitelists
Replace the old wallet only after independently verifying the new address. Some exchanges impose waiting periods after whitelist changes, so account for those delays.
Payment and payroll systems
If clients, employers, partners, or customers send crypto to a saved address, provide the new destination through a trusted communication channel.
Public donation and creator addresses
Update websites, social profiles, documentation, QR codes, invoices, and payment pages.
ENS and other identity records
If an identity or naming record resolves to the retired address, update it according to the system's security model.
Validator, mining, and reward destinations
Review recurring protocol payouts and infrastructure configurations.
Step 10: retire the old wallet
Retirement means the old root should no longer be trusted to hold meaningful future value.
Do not destroy evidence prematurely
Keep public addresses, transaction hashes, and non-secret migration records. They may be useful for monitoring, accounting, support, or incident reporting.
Do not keep using the old wallet for small daily transactions
A compromised key does not become acceptable merely because the remaining balance is small.
Do not reuse the old address because it is convenient
Convenience is how future deposits return to compromised wallets.
Monitor the old wallet after retirement
Monitoring can reveal accidental deposits, delayed protocol withdrawals, claimable rewards, attacker activity, or secondary assets that were missed.
Monitoring does not mean interacting unnecessarily with the wallet.
Watch for delayed funds
Unstaking periods, bridges, vesting contracts, protocol claims, and delayed withdrawals can send value after the main migration.
Watch for accidental deposits
If another service sends funds to the old address, respond according to the current threat model rather than assuming they are safe.
Common migration mistakes
Importing the old phrase into a new wallet application
This changes the software interface, not the root secret.
Creating a new account under the same phrase
Account number two remains a deterministic child of the same recovery seed.
Moving all gas before tokens
This can strand assets and force users to fund the compromised address again.
Sending everything without a test
One wrong destination can create irreversible loss.
Testing with a huge amount
A test should test the route, not recreate the portfolio risk.
Generating the new wallet on the potentially infected device
If malware is part of the threat model, the destination root can be compromised at creation.
Recreating every old unlimited approval
A new wallet is an opportunity to reduce permissions and start with a cleaner authorization state.
Forgetting NFTs and protocol positions
Wallet home screens do not necessarily show every source of value.
Forgetting secondary chains
A single recovery phrase can have assets on many networks.
Posting the old seed publicly after migration
You may have forgotten an account, pending claim, or future deposit route. A compromised secret does not need wider distribution.
If the original problem was phishing
A phishing incident can involve several layers.
If the user only connected the wallet but signed nothing, exposure may be limited. If the user signed an approval, permission review becomes important. If the user submitted the recovery phrase, the root is compromised.
Do not use the phishing page's recovery instructions
Attackers commonly follow the first compromise with a second message offering remediation.
If the original problem was weak seed generation
Weak-generation incidents deserve full root migration because the vulnerability is embedded in the secret's origin.
The phrase can look normal and remain perfectly private in the user's possession while still being predictable to someone who understands the generator.
A software update cannot add missing entropy
Updating the original application protects future generation only if the generation bug has been fixed.
Hardware import cannot add missing entropy
A hardware device can securely use the old key, but an attacker who can reconstruct the phrase does not need the device.
If the original problem is approval exposure
Full migration may not be necessary if the seed remains secure and the only confirmed issue is a delegated token or NFT permission.
Confirm the permission precisely
For ERC-20, identify owner, token, spender, network, and current allowance.
Review the spender's context
A familiar protocol name is not sufficient if the contract is upgradeable or the address is not the expected deployment.
Revoke or reduce permissions appropriately
After confirmation, verify the resulting on-chain state.
If the original problem is an unexplained drain
When the cause is unknown, preserve evidence and classify the transaction before rushing into a diagnosis.
Use public wallet analysis to see the account context. Decode suspicious EVM transactions. Review allowances. Check related addresses and chains. Examine whether the transaction was directly signed from the victim wallet or initiated by another spender.
When uncertainty should still trigger migration
If substantial directly signed unauthorized transactions occurred and you cannot establish a safer explanation, continuing to trust the same root may be an unnecessary risk.
If the original problem is a smart-contract incident
Protocol exploitation can cause losses without compromising individual wallet seeds.
If the issue involves upgraded code, changed permissions, proxy implementation changes, or a suspicious spender, the Smart Contract Diff and Upgrade Analyzer can help compare the supported on-chain contract state.
Do not replace a secure seed solely because a third-party protocol was exploited unless there is evidence the wallet's signing authority was also exposed.
Treat the new wallet as a clean authorization environment
The purpose of migration is not to reproduce every old wallet habit.
Rebuild permissions deliberately.
Approve only what you need
Where protocols support limited allowances, consider whether unlimited access is necessary.
Verify every new protocol interaction
Emergency migration can push users toward fake websites because attackers know compromised users are searching for help.
Segment high-value custody from frequent dApp activity
A long-term wallet that rarely interacts with contracts can have a different risk profile from an active trading or minting wallet.
Printable safe wallet migration checklist
Safe Wallet Migration Checklist
Use public addresses for investigation. Never write a recovery phrase on this checklist.
1. Classify the risk
2. Prepare the new wallet
3. Inventory the old wallet
4. Verify the destination
5. Move assets
6. Clean up and retire
Worked examples: how migration decisions change by incident
Example one: recovery phrase entered into fake support page
A user experiences a wallet error, searches online, finds a fake support website, and enters the twelve-word phrase into a recovery form.
The wallet still contains funds and no unauthorized transaction has occurred yet.
The lack of theft does not restore secrecy. The phrase should be treated as disclosed. Generate a fresh wallet in a trusted environment, verify the destination, and migrate assets before continuing ordinary activity.
Example two: historical weak RNG disclosure
A user learns that an old software wallet version used weak randomness when creating recovery phrases. The seed was generated during the affected period but has never been entered online.
The risk is generation quality rather than leakage.
Importing the seed into modern wallet software does not change the original entropy. Generate an independent seed and migrate.
Example three: one malicious ERC-20 approval
A user signs an approval to a phishing contract. The spender later uses transferFrom to remove one token, but the wallet's native balance and other unrelated assets remain untouched.
Investigate the allowance and transaction path. Revoke the malicious authorization. Full seed migration may not be necessary if there is no evidence the private key or recovery phrase was exposed.
Example four: multiple direct transactions the owner never signed
ETH, USDC, and several tokens leave through separate transactions originating directly from the wallet. The owner did not authorize them.
Broad directly signed activity raises the risk that wallet signing authority itself is compromised. Generate a new root and protect remaining assets while preserving evidence.
Example five: hardware wallet imported from a suspicious hot-wallet seed
A user buys hardware after learning that the old software wallet may have leaked the recovery phrase. Instead of creating a new phrase, the user restores the old words into the device.
The hardware now stores the old keys securely, but another party who already knows the seed can still sign independently.
Initialize with a fresh root and transfer assets to the new addresses.
Example six: user moves Ethereum but forgets Solana
The old seed was used in a multichain wallet. Ethereum and Base balances are transferred, but the user forgets a Solana account containing tokens and staked assets.
The migration remains incomplete because root-seed compromise is not chain-specific.
Example seven: user moves tokens but leaves DeFi collateral
The wallet home screen shows a small balance after migration, but a lending protocol still holds significant collateral associated with the old address.
Protocol positions must be unwound or migrated according to their mechanics before the old wallet can be considered retired.
Example eight: new wallet generated on compromised computer
The user correctly chooses a new phrase but generates it on the same computer that may contain seed-stealing malware.
The destination root may be compromised at creation. The security environment matters as much as the decision to use new words.
Example nine: old exchange whitelist sends money back
Migration finishes successfully. Two months later, the user withdraws from an exchange using a saved whitelist entry that still points to the old address.
The old compromised key remains valid, so the newly deposited assets may be taken.
Future-deposit cleanup is part of migration, not optional administration.
How TokenToolHub tools fit into migration
No single tool replaces the migration process, but different tools can reduce uncertainty at different stages.
Wallet Risk Scanner
Review supported EVM wallet activity, assets, approvals, counterparties, funding evidence, risk indicators, confidence, and coverage using the public address.
Solana Wallet Risk Scanner
Review supported Solana activity, token exposure, delegates, authorities, counterparties, funding context, and risk evidence.
Transaction Decoder
Investigate suspicious or high-value EVM transaction execution, calls, approvals, transfers, traces, and consequences.
Allowance and Diff tools
Check live ERC-20 spender authority and compare relevant contracts when permissions or upgrades are part of the incident.
Investigate with public data, migrate with a private new root
Use wallet addresses and transaction hashes to understand the old wallet. Keep both the old and new recovery phrases out of scanners and public tools.
How to verify that migration is actually complete
Do not stop when the largest visible balance is gone.
Final migration verification
- Review every chain previously used by the old recovery phrase.
- Review every known account index under the old root.
- Check remaining native balances.
- Check remaining token balances.
- Check NFTs and collection assets.
- Check staking and validator positions.
- Check lending deposits and outstanding debt.
- Check liquidity and vault positions.
- Check claimable rewards.
- Check pending bridges and withdrawal queues.
- Check old approvals and operator permissions relevant to any residual assets.
- Check exchange whitelists and saved withdrawal destinations.
- Check recurring payment or reward destinations.
- Confirm the new wallet backup is secure and recoverable.
- Confirm no recovery phrase was stored in the migration notes.
Conclusion: a safe migration replaces the trust root, not just the wallet app
When a recovery phrase may be weak, leaked, phished, copied by malware, or otherwise exposed, changing wallet software is not enough.
The old recovery phrase is the security boundary that needs to be replaced.
A successful migration therefore begins with a completely new recovery phrase generated from independent cryptographically secure randomness. It continues with safe offline backup, careful destination verification, a complete asset and account inventory, controlled transfers, permission review, transaction interpretation, and cleanup of future payment routes.
The correct response still depends on the original incident.
If the only confirmed problem is an ERC-20 allowance or NFT operator, permission remediation may be enough. If a protocol contract was exploited, the wallet seed may remain private. If multiple directly signed unauthorized transactions appear, private-key compromise becomes more plausible. If the original recovery phrase was submitted to phishing or created through a confirmed weak-generation path, the root should no longer be trusted.
During the process, use the Wallet Risk Scanner for public EVM wallet evidence, the Solana Wallet Risk Scanner for supported Solana account intelligence, the Transaction Decoder when suspicious EVM execution needs to be understood, the Approval Allowance Checker for live ERC-20 spender authority, and the Smart Contract Diff and Upgrade Analyzer when changed on-chain code is part of the risk.
Those tools operate on public blockchain evidence. They do not need a seed phrase.
The migration is not complete when the old address reaches zero. It is complete when valuable positions no longer depend on the compromised root, the new wallet has a secure and recoverable backup, permissions have been rebuilt deliberately, future deposits point to the new addresses, and the old wallet is treated as retired.
The safest mental model is simple: investigate the old wallet publicly, create the new wallet privately, verify every movement, and never carry a compromised root into the destination security model.
FAQs
What is the safest way to move funds from a compromised wallet?
Create a completely new wallet from independent secure randomness in a trustworthy environment, record the new recovery phrase offline, verify the receiving address, make a small test transfer when practical, then migrate assets systematically while accounting for gas, protocol positions, permissions, and other chains.
Should I import my compromised recovery phrase into a new wallet?
No. Importing the same phrase recreates the same underlying keys. If the recovery phrase itself is compromised or weak, the destination should use an entirely new phrase.
Does creating another account under the same seed make my funds safe?
No. Additional accounts remain derived from the same root recovery phrase. A compromised root requires an independent new root.
What should I do if my seed phrase may be weak?
Generate a new wallet using trustworthy cryptographically secure randomness, securely record the new phrase offline, inventory all assets controlled by the old seed, verify destination addresses, and migrate relevant assets and future payment routes.
What should I do if I entered my seed phrase into a phishing site?
Treat the phrase as compromised. Do not wait for unauthorized transactions before taking action if assets remain under the exposed root. Generate a new independent wallet and migrate safely.
Do I need to migrate if only one token approval is suspicious?
Not automatically. A malicious ERC-20 allowance can be abused without exposing the seed. Verify the transaction path, check the live allowance, revoke unnecessary permissions, and determine whether there is evidence of broader signing-key compromise.
Can changing my wallet password fix an exposed seed?
No. A local wallet password usually protects application access or encrypted storage. It does not change the private keys derived from the recovery phrase.
Can moving an exposed seed to a hardware wallet secure it?
No. Hardware can protect signing with the imported keys, but it cannot undo previous seed exposure or weak generation. Generate a fresh seed on the hardware device if the old root is not trusted.
Should I enter my recovery phrase into TokenToolHub to check it?
No. TokenToolHub wallet scanners operate on public addresses. Never submit a recovery phrase, private key, wallet password, keystore secret, or recovery code to a public scanner.
Should I move the most valuable assets first?
Value is one factor, but migration order also depends on active attacker behavior, gas requirements, withdrawal delays, staking locks, protocol mechanics, and whether moving one asset affects another position. Prioritize with the complete portfolio in mind.
Why should I make a test transfer?
A small test helps confirm the destination address, network, and access to the new wallet before larger transfers. During an active drain, urgency may require balancing test size and response speed.
How much native gas should I leave during migration?
Leave enough for the remaining planned transactions, including token transfers, revocations, withdrawals, unstaking, or protocol interactions. Moving all native gas too early can strand other assets.
Do ERC-20 approvals move to the new wallet?
No. An allowance is tied to the owner address, token contract, spender, and network. The new wallet has its own permission state.
Should I recreate my old unlimited approvals on the new wallet?
Not automatically. Migration is an opportunity to apply least privilege and authorize only the applications and amounts you currently need.
How do I check an ERC-20 allowance?
Identify the owner address, token contract, spender, and network, then read the live allowance. TokenToolHub Approval Allowance Checker is designed for this exact relationship.
Do NFT approvals work differently from ERC-20 allowances?
Yes. ERC-721 and ERC-1155 support operator-style permissions such as setApprovalForAll. Review NFT-specific approval state when migrating valuable collections.
Do I need to check Solana separately?
Yes. Solana has a different account and token model. If the old recovery phrase controlled Solana accounts, review SOL, SPL tokens, token delegates, authorities, staking, program positions, and other relevant state separately.
Can a Solana token delegate move funds without owning the seed?
A token-account delegate can be authorized to transfer or burn tokens within its delegated allowance. Review delegate state and revoke inappropriate permissions according to the relevant token program.
Does every Solana delegate work like an ERC-20 spender?
No. Solana's token model and Token-2022 extensions have their own authority semantics. For example, some mint-level features such as permanent delegates require different interpretation.
Should I bridge assets during an emergency migration?
Only when the bridge is necessary and understood. A direct same-chain transfer to the new wallet is often simpler when the destination wallet supports that chain. Bridges add contract, interface, timing, and destination-network complexity.
What should I do with DeFi positions?
Identify the protocol-specific withdrawal, repayment, unstaking, liquidity-removal, claim, or transfer process. Do not assume a token transfer alone moves the underlying position.
What if my assets are locked in staking?
Document the position, initiate the appropriate unstaking or withdrawal process if needed, monitor the old wallet during any cooldown, and move the released assets as soon as the protocol permits.
What if a bridge transfer is still pending?
Record the source transaction, destination chain, claim requirements, and expected completion path. Do not retire operational access to the old wallet before every necessary claim or completion step is understood.
Can Wallet Risk Scanner prove the new seed is secure?
No. A public wallet scanner analyzes on-chain behavior. It cannot certify the private entropy or confidentiality of a recovery phrase.
Why use Transaction Decoder during migration?
Complex migration actions can involve smart contracts, approvals, internal calls, token transfers, bridges, staking, and multicalls. Decoding confirmed transactions helps verify what actually executed.
When is Smart Contract Diff useful?
It is useful when the incident involves a changed or upgraded EVM spender, smart-account implementation, router, proxy, or protocol contract. It does not determine whether the seed itself is compromised.
When is wallet migration complete?
Migration is complete when relevant assets and positions no longer depend on the old root, the new wallet is securely backed up, future deposit destinations have been updated, permissions have been rebuilt deliberately, and the old wallet is retired from meaningful future use.
Should I delete all records of the old wallet?
No. Preserve public addresses, transaction hashes, dates, and non-secret incident records. Do not preserve private keys or seed phrases in insecure digital notes merely for documentation.
Can I reuse the old wallet after it reaches zero?
If the root is considered compromised, do not intentionally reuse it for valuable future deposits. The compromised signing authority does not disappear when the balance reaches zero.
Why should I monitor the old wallet after migration?
Monitoring can reveal delayed protocol withdrawals, accidental deposits, claimable rewards, missed assets, or continued attacker activity without requiring you to place new value in the old wallet.
What is the biggest mistake during wallet migration?
The most consequential mistake is treating a different wallet application or device as a new security root while restoring the same compromised recovery phrase. Safe migration requires independent new entropy.
References and further reading
The following standards and technical resources provide additional background on token permissions, NFT operators, Solana token delegates, and secure recovery-phrase handling.
- ERC-20 Token Standard
- ERC-721 Non-Fungible Token Standard
- ERC-1155 Multi Token Standard
- Solana SPL Token Basics
- Solana Token Spend Permissions
- Solana Token-2022 Permanent Delegate Documentation
- Ledger: Recovering a Hot Wallet on Hardware
- Ledger Recovery Phrase Security Guidance
This guide is educational security material, not a guarantee that assets can be recovered or that a wallet is safe. Wallet and protocol architectures differ, and an active compromise can require case-specific incident response. Never submit a recovery phrase, private key, wallet password, keystore secret, one-time code, or exchange credential to TokenToolHub or any public wallet checker. Use public addresses and transaction hashes for on-chain investigation.
