The Vault introduces the Fireblocks Adapter: move custody without exporting keys or rewriting integrations
The Vault now offers a structured migration path for institutions currently running on Fireblocks. At its centre is the Fireblocks Adapter, an endpoint that accepts the Fireblocks API calls an existing integration already makes and executes them against Vault wallets and policies. Assets move to newly generated MPC wallets through ordinary on-chain transfers, and no private key is exported at any point.
The two questions behind every migration
Conversations about leaving Fireblocks tend to start with the same two concerns: what happens to the keys, and what happens to years of integration code.
The second is usually the one that stops a project. Teams can adapt to a new console, new approvers and new policies. Rewriting deposit address provisioning, sweep jobs, withdrawal services and webhook consumers that the rest of the business depends on is a different matter. The Vault's migration path is designed around that reality.
Keys stay inside MPC
The Vault does not move keys between systems. Instead, new wallets are created inside The Vault through a distributed key generation ceremony between the client's signer nodes and approver devices, so a complete private key never exists in one place. Assets are then transferred from Fireblocks to these wallets on chain.
This avoids reconstructing a key outside MPC, which exporting it from another platform would require. It also gives regulated firms a clear audit answer: for a key generated inside The Vault, it is known who has ever been able to sign with it.
The Vault has no self-service key import or export. Where existing keys genuinely must be preserved, for example for a counterparty that cannot update its deposit addresses, key import is available as a managed procedure with a security review, a signed risk acknowledgement and a joint validation session.
Integration code stays as it is
The Fireblocks Adapter mirrors the Fireblocks REST paths and payloads for vault accounts, assets and transactions. Behind it, each call becomes a Vault operation: a vault account becomes a Vault wallet, activating an asset creates an address, and a transaction request becomes a governed transfer that passes through Vault policies and approvers exactly like a transfer started in the console. Deposits and status changes are delivered to the client's webhook as Fireblocks-style events.
For the integration team, the change comes down to two things: the base URL and the authentication header. Data models, vault account IDs, asset identifiers and event handling stay the same.
How a migration runs
A migration involves three teams working largely in parallel. Security and operations build and govern the destination: signers, approvers, wallet groups, policies and whitelists, rehearsed on testnet first. Integration engineers switch the existing integration to the adapter. Treasury moves funds in tranches on its own change calendar, starting with a small pilot for each asset class.
Fireblocks stays live in read-only mode throughout, until the last old address has gone quiet, so there is never a moment without a working custody system. Each step is a normal withdrawal on one side and a normal deposit on the other: nothing is irreversible and no downtime is required. Before cutover, The Vault team runs a joint validation session with the client covering balances, a full transfer through the adapter, deposit detection, policy behaviour and webhook delivery.
How long it takes
Repointing an integration to the adapter takes about a day. A pilot transfer, including policy rehearsal, takes a few days. A full production move typically takes two to four weeks, depending on the number of wallets and how quickly counterparties rotate addresses.
Getting started
To scope a migration, The Vault needs the assets and chains in use, the structure of the Fireblocks workspace (vault accounts, roles and TAP rules), the webhook endpoint, and the list of Fireblocks API calls the integration makes, so that adapter coverage can be confirmed before any commitment. Migration support is included.
To book a demo and discuss the details of your migration, contact us at demo@thevault.inc.
For technical details, including supported endpoints, webhook events, console configuration and the full migration runbook, see Migration from Fireblocks in The Vault documentation.
Frequently asked questions
Can Fireblocks and The Vault run side by side?
Yes, and this is recommended. The two are independent endpoints, and most customers keep Fireblocks in read-only mode for several weeks after the last tranche.
Do we have to rotate published deposit addresses?
Usually, yes. Done in tranches while the old addresses are still monitored, it is less painful than it sounds. If a specific counterparty cannot update, a managed key import can be discussed for that one wallet.
What about transactions in flight at cutover?
They complete on Fireblocks. The adapter only sees transactions created through it, so there is no overlap.
Are adapter transactions subject to our policies?
Yes. Policies are enforced on every transfer, whether it comes from the console, the native API or the adapter.
Can we leave The Vault later?
The same rule applies in both directions: no one-click key export, but a governed asset transfer to wherever you are going, with a managed key procedure where it is unavoidable. An exit plan under DORA and MiCA can reference this approach.