How to plan a migration from Safe to a policy-based wallet

What this migration is, and is not

Moving from a Safe to a policy-based wallet is not a balance transfer. A Safe that has been in use for a year is a system: owners on specific devices, a threshold, modules and delegates, token approvals granted to protocols, positions with receipt tokens, contract roles held by the account, deposit addresses printed in counterparties' systems, and a history your accountants rely on. The migration succeeds when every one of those relationships has been deliberately moved, closed, or kept.

Do it because you want recipient allowlists, amount tiers, rate limits, and contract-call restrictions as first-class policies in one managed workflow, enforced onchain and re-checked off-chain, rather than assembled from Safe's Allowance module, optional guards such as Safe Shield's Guardian by Hypernative, and Workspace roles, or because finance needs approval routing and reporting in the same product that holds the funds. Do not do it because a vendor told you multisig is obsolete. A Safe holding long-term reserves behind hardware wallets may be exactly right to keep, with operations moving to the new account. Our Safe wallet review covers when that split makes sense.

This guide uses Den's Multi-Layer Security Wallet as the destination for concrete steps. Den publishes this blog. The inventory, export, and cutover phases apply to any destination.

The plan at a glance

The estimates are planning placeholders, not measured averages. A small treasury with one Safe and no protocol positions can compress the plan to a few weeks. Anything with DeFi positions or contract ownership should not.

Phase 1: inventory the Safe as a system

Work per Safe address and per network. Safe's account model means each network deployment is a separate contract with its own configuration, even when the address matches.

Record for each account:

• Owners and threshold, plus which device or key backs each owner and who holds it.
• Enabled modules, including the Allowance module behind spending limits, any recovery module, and any automation or governance modules. For each, list the delegates and their remaining allowances. Modules execute without owner signatures, so they are live authority that must be revoked or replaced.
• Guards and fallback handlers, and what they enforce.
• The pending queue in the Transaction Service. Stale proposals can execute later against assumptions that no longer hold.
• Token approvals the Safe has granted to routers, bridges, and protocols. These do not move with the funds and should be revoked before the account is retired.
• Protocol positions and their receipt tokens, and whether each protocol lets you transfer the position or requires a withdraw-and-redeposit.
• Contract roles the Safe holds: ownership, admin, minter, pauser, or governance rights in your own or third-party contracts.
• ERC-1271 dependencies, meaning integrations that verify signatures from the Safe as a contract, such as permit-style approvals or off-chain order systems.
• Addresses shared externally: counterparty deposit instructions, exchange withdrawal allowlists, payroll and vendor systems, and any accounting labels.
• Automation that holds an owner key or a delegate key.

Assign a named owner to every line. A dependency without an owner is the one that surfaces three months after cutover.

Phase 2: preserve the record

Export history before anything changes. The Safe Wallet CSV export under Transactions and History supports a date filter and includes only transactions with an amount greater than zero. Owner changes, approvals, and other zero-value calls are missing from it. Fill those from the Transaction Service API or a block explorer, and keep the raw files with the retrieval date, network, and account.

Then build a reconciliation baseline: balances per token per network, open positions with their valuation method, and the mapping from transaction hashes to invoices or internal references. Finance signs off on this baseline. It is the number everything after cutover reconciles to.

Phase 3: design the target model

Resist copying the Safe's threshold into the new system as "3 of 5 for everything." The point of the move is that different transactions can carry different rules. Translate responsibilities, not settings.

In Den's terms, this becomes an organization with members, groups, accounts, and policies. Each policy has an approval type, a transaction type, filters, and optional time limits, and a transaction that matches no policy cannot be queued at all. Changes to members, groups, policies, and admins are organization operations governed by the admin threshold rather than by any single person.

Write the target as a table like the one in our treasury buying guide and have finance and security sign it before configuration begins.

Phase 4: stand up and test the destination

The order matters because some decisions are hard to change later.

1. Check network coverage first. Den's contracts are deployed on Ethereum, Arbitrum One, Base, Optimism, and Ronin, with Sepolia for testing and new networks available on request. If a Safe lives on a network the destination does not support, that account stays where it is or waits for a deployment.
2. Create the organization and its admins, and set the admin threshold. This is the group that can change rules, so keep it small and make the threshold greater than one.
3. Enroll approvers on the mobile signing client and register automation as API members. An API member is invited by an admin, proves control of its key by signing a registration payload, and is then added through a member proposal that admins approve. Generate its key in a KMS or HSM, never in an environment variable in production.
4. Create accounts through account proposals and record the new addresses. Den covers gas within a plan allowance, so there is no fee wallet to fund.
5. Load the policy set through the dashboard or the policy update proposal flow. Only one policy proposal can be queued at a time, so batch changes.
6. Run the deny cases on Sepolia, then on mainnet with small amounts: a routine payment that should auto-approve, a payment to an address not on the allowlist, a payment over the cap, a contract call to the wrong function, and a burst that exceeds a time limit. Confirm each is stopped where you expect, in the SDK or app before signing, and record the evidence.
7. Configure recovery before you fund at scale. Den's disaster recovery uses two separately configured recovery addresses, which can be hardware wallets or multisigs, and timelocks between 2 and 30 days. Once set, recovery addresses are immutable, so choose them as a deliberate governance decision. Transaction Recovery bypasses the policy engine, so treat that address as your most sensitive key.

Phase 5: move positions, roles, and balances

Sequence the moves so that nothing is stranded.

• Revoke token approvals the Safe granted to protocols you will no longer use from that account. Approvals are a standing permission on the Safe and do not disappear when balances leave.
• Transfer contract roles using each contract's own mechanism. Prefer two-step ownership transfers where the contract supports them, and test that the new account can accept. In Den, the acceptance call is a contract interaction that needs a policy allowing that contract and function.
• Migrate protocol positions. Some receipt tokens can be transferred directly. Others require withdrawing to the Safe and redepositing from the new account, which has fee and timing implications and may need a Treasury-approved contract-interaction policy on the destination.
• Re-point ERC-1271 integrations. Den accounts can validate signatures as a contract, so integrations that verified the Safe's signatures need the new account's address and a re-run of their onboarding.
• Move balances in tranches under the new policies. Start with an amount you can afford to have stuck while you learn the approval flow, reconcile it against the Phase 2 baseline, then continue.

Every move in this phase is a signed transaction with people watching. Review the exact calldata with the responsible operators before execution, especially for role transfers, which can be irreversible.

Phase 6: cut over and decommission

Change one workflow at a time. Update the deposit address with counterparties and exchanges, allowing for their allowlist delays. Run one full payment cycle on the new account and reconcile it. Then move the next workflow.

Keep the old Safe monitored for at least a quarter. Counterparties will keep sending to the old address, and stale approvals or queued transactions can surface late. Do not lower the Safe's threshold to make sweeping easier. Keep its owners intact and sweep stragglers through the normal approval process. When inbound activity has stopped and finance has closed a period with no old-account entries, revoke remaining module authority, and only then decide whether to retire the account or keep it as a cold reserve.

Pitfalls to plan for

• Copying the threshold instead of designing policies, which reproduces the Safe's limitations in a new place.
• Automation keys left in environment variables when the whole point of API members is that keys can live in a KMS or HSM.
• Rate limits set from intuition that block the first legitimate payroll batch. Size time-based limits from the Phase 2 history.
• Approvers not enrolled on the mobile client until the first urgent payment.
• Recovery configured as an afterthought, or not at all, on addresses that are then hard to change.
• Forgetting that ERC-20 approvals stay with the Safe, leaving standing permissions on a supposedly dormant account.
• Cutting over on a network the destination does not support, discovered when the first deposit arrives.

For the architecture behind this decision, read Safe vs MPC wallets. For the wider vendor landscape, see Fireblocks alternatives. Den's API quickstart is the fastest way for an engineer to see the propose, approve, and execute flow end to end.