How to Migrate a Safe Wallet from One Network to Another

12 October 2026

You don’t migrate a Safe wallet. You move its assets, and you recreate its configuration on the destination network. That distinction matters, because a Safe is a smart contract, and a smart contract deployed on Ethereum cannot exist on Arbitrum, Polygon, or Optimism. The contract address, the signer set, and the threshold are all network-specific.

The process is straightforward, but it has enough steps - and enough places to lose funds - that it helps to walk through it deliberately. Here is what "migrating" a Safe actually involves, and how to do it without making a costly mistake.

The Short Answer

To move a Safe from Network A to Network B, you do three things: record your current Safe’s configuration (signers, threshold, and any module addresses), deploy a new Safe contract with that same configuration on Network B, and then transfer your assets from the old Safe to the new one. You are not moving the contract. You are recreating it and relocating its contents.

Step 1: record your safe’s configuration

Before you touch any assets, write down your Safe’s settings. You need:

• The owner addresses (the signers, which may be hardware wallets, software wallets, or other contracts).
• The threshold (how many signatures are required to execute a transaction).
• Any modules or guards attached to the Safe, such as a social recovery module or a spending-limit module.
• The nonce - though you normally don’t need to record it manually; the Safe UI handles it.

You can find all of this in the Safe web interface under Settings > Safe details, or by reading the contract’s configuration on a block explorer. If you have a hardware signer, make sure you know which derivation path corresponds to which owner address. A common failure point is assuming your hardware wallet’s address is the same on every network. It is not - the address depends on the derivation path, and the path can differ per network.

Step 2: Deploy a New Safe with the Same Configuration on the Destination Network

Open the Safe web app on the destination network and choose Create new Safe. You will be prompted to name it and to add owners. Enter the same owner addresses and the same threshold you recorded in Step 1.

Here is the part people often miss: the new Safe’s contract address will almost certainly be different from the old one. A Safe’s address is derived from the factory contract that deployed it and the configuration (owners, threshold, nonce) at deployment time. Unless you reuse the exact same deployment parameters - including the same nonce and the same factory version - you will end up with a new, different address.

That is fine. You do not need the same address. You need the same signers and the same threshold. What you do need to be careful about is not deploying the Safe with a different owner set by accident. Triple-check the addresses before you hit deploy.

If your old Safe had modules enabled (for example, a social recovery module), you will need to re-add them on the new Safe after deployment. Modules are not carried over automatically, because they are separate contracts with their own addresses. You will need the module contract address on the destination network, which may differ from the source network. Check the Safe’s documentation or the module provider’s site for the correct address on each chain.

Step 3: Transfer Assets from the Old Safe to the New One

Now you have two Safes: the old one on the source network, and the new one on the destination network. You need to move everything from the old to the new.

• Native tokens (ETH, MATIC, etc.): Send them directly from the old Safe to the new Safe’s address.
• ERC-20 tokens: Use the Safe’s built-in transfer function or a standard ERC-20 transfer. The Safe UI has a "Send" button for tokens; use it.
• NFTs: Send them one at a time, or use a batch transfer if the Safe UI supports it. There is no shortcut here.
• Position in DeFi protocols: This is the hard part. If your Safe holds a position in a lending protocol or a liquidity pool, you cannot transfer that position directly. You must withdraw it (or redeem it) on the source network, then move the underlying asset. That may trigger tax events, liquidation risks, or exit penalties. Plan accordingly.

Do not forget pending transactions. If your old Safe has a transaction that is waiting for signatures, those signatures are not portable. You will need to gather them again on the new Safe, because the new Safe is a different contract and does not know about the old one’s pending state.

Step 4: Verify Everything on the Destination Network

Once assets are moved, check the new Safe’s balance on a block explorer. Confirm that the owner set and threshold shown on-chain match what you intended. Then do a test transaction: send a small amount out of the new Safe, sign it, and execute it. This confirms that all signers can still produce valid signatures and that the threshold is correctly enforced.

What about the old safe?

Once the new Safe is funded and tested, you should deactivate the old one. "Deactivate" does not mean delete - you cannot delete a smart contract. It means:

• Remove any approved token allowances the old Safe had on DeFi protocols.
• If the old Safe had a module, consider removing it, though that requires a transaction.
• Stop using the old Safe’s address. If it sits empty, it is harmless. If it holds dust, leave it or sweep it.

Some people choose to "burn" an old Safe by setting the threshold to 1 and the owner to a dead address. That is irreversible and unnecessary unless you have a specific reason. An empty Safe, left alone, is not a risk.

Common Mistakes and How to Avoid Them

• Assuming the address follows you. It does not. The old Safe’s address is gone once you move on.
• Forgetting modules. Social recovery and other modules are separate contracts. Re-add them on the new network.
• Skipping the test transaction. Always send a small amount first. Always.
• Not checking the derivation path on your hardware wallet. The address you see in the Safe UI must match the address on your device. If it does not, you are signing with the wrong key, and the transaction will fail.
• Moving tokens before checking for airdrops or claims. If your old Safe is owed a token airdrop, moving its assets does not affect the claim. The claim is tied to the address, not the tokens. You can claim from the old address later if you still have the signing keys.

When you should not migrate

If your Safe holds a position in a protocol that uses the Safe’s address as an identifier (for example, a governance token with a vesting schedule, or a loan), migrating may not be possible without breaking the position. In those cases, consider whether you actually need to migrate at all. You can continue operating the old Safe on the source network and simply not use it on the new one. A Safe is not required to be multi-chain.

The Bottom Line

Migrating a Safe is not a single transaction. It is a sequence of small, careful steps: record your configuration, deploy a new contract, move your assets, test the new contract, and retire the old one. None of these steps are difficult on their own, but together they form a process that rewards patience and punishes shortcuts. Do it slowly. Check your addresses. Test with a small amount. Then you can move the rest.

Back to smart wallets