How to Migrate from Fireblocks to Dfns

Migrating custody is a serious matter. It affects security, operations, compliance, and customer trust. But this seriousness shouldn’t lead to analysis-paralysis or stop you from considering alternatives. Many organizations have migrated successfully, and planning for an exit is becoming a regulatory imperative worldwide. For many institutions using Fireblocks today, the question is no longer whether to prepare an exit, but how to do it safely, predictably, and in a way that avoids long-term vendor lock-in.

This guide explains how to migrate from Fireblocks to Dfns end-to-end: how the process works, why customers choose this path, what to expect in practice, and how it aligns with rising regulatory requirements around interoperability and operational resilience. It’s a practical, customer-facing migration guide written for fintechs and regulated institutions.

To learn more about how Dfns compares to Fireblocks, we also recommend reading this comparison.

Why consider migrating from Fireblocks to Dfns?

• Avoiding vendor lock-in: Fireblocks was not designed with portability as a core principle, especially for what they call “Custodial Wallets.” There is no simple, one-click way to export keys or policies. Migrations are possible, but they require careful planning and additional recovery tooling. Dfns takes a different approach by making wallets programmable and API-first, providing clear import and export paths through dedicated APIs, and treating recovery and portability as part of everyday operations rather than rare edge cases.
• Regulation thinks that interoperability is no longer optional: Regulations such as DORA, FISMA, and broader supervisory guidance are increasingly focused on operational resilience, clear exit strategies from critical vendors, avoiding irreversible outsourcing dependencies, and ensuring the ability to recover, migrate, or replace infrastructure when needed. Custody providers are critical infrastructure vendors. From a regulatory standpoint, being unable to migrate keys or wallets represents a real operational risk. Having a tested and reliable migration path is therefore no longer just a technical preference, it is becoming a compliance requirement.
• Better security model going forward: Dfns’ architecture is built so that private keys are never reconstructed on servers. Instead, partial keys are generated client-side and distributed across multiple MPC signers, with end-to-end encryption between the browser and signing nodes. Governance is driven by explicit policies rather than relying primarily on user interfaces. As a result, migration is not just about moving keys from one system to another. It is about moving to a stronger security model for the future.

Important note before you begin

Before diving into the technical steps of migration, it’s important to understand a key strategic choice that will shape your move from Fireblocks to Dfns. You have two main options:

1. Migrate your existing keys (the approach covered in this guide).
2. Create new wallets in Dfns and transfer your assets instead.

Migrating keys can make sense if your move is driven by external pressure. For example, new regulations, a forced vendor change, or security concerns such as an incident, recovery scenario, or loss of trust in your current setup. Moving keys may also be necessary if deposit addresses are hard-coded into your products, partners or users depend on your existing addresses, or you cannot easily rotate addresses operationally.

That said, in most situations, the second option (i.e., moving assets instead of keys) is the better choice. Dfns recommends by default creating new wallets inside Dfns and transferring assets from Fireblocks, rather than importing old keys. Here’s why:

• Imported keys carry their history with them: Any key that lived in another system may have been copied, logged, or exposed in ways a new provider cannot fully verify. Even with strong procedures, Dfns cannot offer the same security guarantees for imported keys as for keys generated natively in our system.
• Native Dfns keys start clean: When you create wallets directly in Dfns, keys are generated inside our secure infrastructure and immediately split into MPC shares. A full private key never exists in plaintext, and you don’t inherit risks from a previous provider.
• Clearer risk and compliance: For regulated institutions, importing legacy keys can blur responsibilities and complicate audits. Creating new Dfns wallets and moving assets into them establishes a cleaner security baseline and a simpler, clearer audit trail.

You can find more details here: docs.dfns.co/api-reference/wallets/transfer-asset#transfer-asset 

What to expect from a Fireblocks migration (upfront)

A migration from Fireblocks involves three high-level phases:

1. Extract key material from Fireblocks (via Fireblocks Full Key Takeover or Recovery Package)
2. Import and reconstruct wallets in Dfns
3. Validate, test, and optionally rotate into new wallets

Step 1: Exporting keys from Fireblocks

• [Option A] “Fireblocks Full Key Takeover”: Fireblocks provides a mechanism called Full Key Takeover, which allows customers to extract their private keys for “non-custodial wallets” or “NCW” only. This process is documented by Fireblocks and requires administrative access and approvals. It produces key material suitable for migration. This option is typically available for certain setups and is the cleanest path when supported.
• [Option B] Recovery Package (most common): In many real-world cases, especially for “Custodial Wallets” or “CW,” migration relies on the Fireblocks Recovery Package. There is no simple “export private key” button for custodial wallets. The Recovery Package is the only reliable path. It was originally designed for disaster recovery, but works for migration too. The Recovery Package is an encrypted bundle containing your wallet key material. It’s protected using either a recovery phrase, or an RSA public key you provide to Fireblocks.

_{If you do not have the Recovery Package, migration is not possible.}

Step 2: Decrypting and reconstructing Fireblocks keys

Once the Recovery Package is obtained, use the Fireblocks’ Recovery Kit. What happens in practice:

1. The encrypted package is decrypted
2. Two key artifacts are reconstructed:
   
   • xprv: standard BIP-32 extended private key
   • fprv: Fireblocks-specific extended key format
3. Derivation paths (i.e., "HD wallets") used by Fireblocks are identified

These artifacts are sufficient to recreate wallets deterministically.

Step 3: Importing keys into Dfns

Dfns provides a Key Import API that is fundamentally different from traditional imports. Example:
github.com/dfns/dfns-sdk-ts/tree/m/examples/sdk/import-hd-wallet 

How Dfns Key Import works:

• A WebAssembly (WASM) module runs directly on your machine 
• The private key is processed client-side
• The key is split into multiple shares (5 by default, configurable)
• Each share is encrypted independently and bound to a distinct MPC signer
• Shares are transmitted securely to the Dfns MPC cluster

The full private key never exists on Dfns servers. This removes single points of failure and significantly reduces attack surface.

Step 4: Recreating wallets and addresses

Once imported, Dfns:

• Create derived wallets using the imported master key and derivation paths
• Verify that the wallets have the same blockchain addresses
• Preserves control over existing wallets

The goal is strict equivalence: Same addresses, same assets, same signing authority. This is essential for continuity where wallet addresses are already shared with customers, exchanges, or counterparties.

Step 5: Policy configuration and governance

Migrating wallets is only half the story. Governance matters just as much. Dfns strongly recommends setting up these three foundational policies immediately:

1. Permission Assignment Approval: Prevents rogue admins from granting themselves access
2. Permission Modification Approval: Prevents silent privilege escalation
3. Policy Modification Approval: Protects your security rules from being changed unilaterally

These are available directly in: Org → Policies

Additional best practices

• Apply least privilege (avoid full admin access for daily use)
• Separate initiators and approvers
• Use wallet tags (e.g. treasury, hot, settlement)
• Configure Transaction amount limits, Recipient whitelists, and Velocity limits
• Test all policies on testnets first

Dfns policies are API-driven and auditable, making them easier to reason about than UI-only governance models.

Step 6: Validation and test transactions

Before any production cutover, Dfns runs a live session with you to verify the newly imported keys work. This includes:

• Address matching
• Balance verification
• Signature validation
• Policy replication
• Test transactions on supported networks

We typically validate:

• One ECDSA key (Ethereum, Bitcoin)
• One EdDSA key (Solana)

EdDSA migrations are explicitly tested due to historical complexity in Fireblocks exports. Only once tests pass do we recommend moving live flows.

You can always export from Dfns

Unlike too many wallet platforms, Dfns explicitly supports wallet export. This is intentional. Interoperability, reversibility, and exit readiness are part of the product design, not an afterthought.

Example: github.com/dfns/dfns-sdk-ts/blob/m/examples/sdk/export-wallet/index.ts

Legal and operational considerations

From a legal and regulatory perspective, wallet providers are treated as critical third parties. Being able to migrate your infrastructure supports MiCA/DORA exit strategies, business continuity planning, supervisory expectations, and audit readiness. Increasingly, institutions are expected to document how keys can be recovered, how vendors can be replaced, and how client assets remain accessible under stress. Dfns migrations fit cleanly into these regulatory frameworks.

In practice, timelines are manageable. A proof of concept typically takes a few days, a partial production migration around 1-2 weeks, and a full production migration depends on the number of wallets, the assets involved, and the complexity of your governance model.

To get started, Dfns generally needs your Fireblocks Recovery Package or a Full Key Takeover, a list of assets and chains, the key types you are using (e.g. ECDSA, EdDSA), which wallets you want to preserve versus rotate, and your desired governance model. Once that is provided, Dfns handles the rest.

Next steps and broader migration roadmap

Key migration is only one part of a real custody migration. Wallets are also tied to identities, roles, approval policies, and operational metadata. Treating migration as “keys only” could increase risk and create operational friction. Dfns’ goal is to make migrations structural, not exceptional.

Today, Dfns already supports:

• Deterministic key and HD wallet migration
• Policy and permission setup via APIs
• Wallet metadata such as tags and labels
• Clear separation between identities, permissions, and signing authority

This makes it possible to recreate a full custody environment in a controlled and auditable way.

In progress

We are building tooling to make custody migrations feel more like database migrations than security exercises, including:

• Bulk import and export of policies and roles
• Programmatic migration of identities and service accounts
• Policy model translation and validation
• Dry runs and parity checks before cutover

The goal is to reduce manual work, shorten timelines, and enable regular exit testing.

Future work

Our long-term direction is to make custody infrastructure replaceable by design:

• Exportable keys, wallets, identities, and policies
• Deterministic re-import into other environments or providers
• Clear ownership of custody data, not just keys
• Routine, testable exits aligned with regulatory expectations

For customers migrating today, Dfns provides end-to-end support, including governance reconstruction and validation. For customers planning ahead, the intent is to make migrations should be predictable, repeatable, and boring.

• Import keys to Dfns: docs.dfns.co/advanced/importing-existing-keys#importing-existing-keys‍
• Export keys from Dfns: docs.dfns.co/api-reference/keys/export-key#export-key 
• Explore our API documentation: docs.dfns.co

If you decide to migrate to Dfns, our team will support you end to end at no extra cost.
‍Start building on Dfns today: app.dfns.io/get-started