Migration from Fireblocks
This section describes how to move a production custody setup from Fireblocks to The Vault. It explains the migration model, the Fireblocks Adapter, adapter configuration in the console, the migration runbook and the validation performed before cutover.
The migration is built on two principles. Keys are not moved: new master keys are generated inside The Vault during the Distributed Key Generation ceremony, and assets are transferred on chain. Integration code is not rewritten: the Fireblocks Adapter accepts the Fireblocks REST calls your integration already makes, so only the base URL and the authentication header change.
What Is the Fireblocks Adapter?
The Fireblocks Adapter is an API surface that The Vault exposes under /v1. It
mirrors the Fireblocks REST paths and request and response payloads for vault
accounts, assets and transactions, and translates each call into a Vault
operation.
For your integration, nothing changes in the data model: it keeps its vault account IDs, asset identifiers and event handling. Behind the adapter, every operation is executed against Vault wallets and is subject to the Policy Engine in the same way as an operation initiated from the console or the native API.
| Fireblocks | The Vault |
|---|---|
| Vault account | A wallet, placed in a wallet group of your choice |
| Activating an asset | Creating the corresponding address in the wallet |
| Transaction request | A governed transfer, evaluated against your policies and approved by your approvers |
| Deposits and status changes | Fireblocks-style events delivered to your webhook endpoint |
Migration Model: Transfer Assets, Not Keys
The default migration is a sequence of ordinary on-chain transfers from Fireblocks wallets to newly generated Vault wallets.
- Master keys for the new wallets are created during the Distributed Key Generation ceremony between your server signers and the mobile signers of your approvers. A complete private key does not exist at any point.
- Outgoing transfers are governed by your existing Fireblocks policies. Incoming transfers are governed by Vault policies you have already tested. Both sides produce a complete record.
- Fireblocks remains live in read-only mode until the last inbound transfer to an old address has been swept, so there is no period without a working custody system.
- The blockchain itself serves as the audit trail.
Why Keys Are Not Exported or Imported
Fireblocks does not provide a private key export function for custodial wallets.
What exists is the Recovery Package, an encrypted bundle created for disaster
recovery, and the Recovery Kit, an offline tool that decrypts it and
reconstructs the extended private keys (xprv).
Using this route for migration means the complete private key exists in plaintext on a workstation for a period of time. Splitting it into shares again after import does not remove the copies that may remain elsewhere — in shell history, swap files, workstation backups or screenshots. For a regulated firm this is also an audit question: for a key generated inside The Vault, it is known who has ever been able to sign with it; for an imported key, this cannot be established with certainty.
The Vault has no self-service key import and no self-service key export. This is a deliberate product decision, not a missing feature.
Managed Key Import
If existing keys must survive the migration — for example, because deposit addresses are embedded in third-party systems that cannot be updated on your timeline — contact your account manager. Key import is then handled as a managed procedure:
- A security review of how the key material was produced and handled.
- A signed risk acknowledgement.
- A joint validation session before the wallet is allowed to hold production balances.
Managed import is applied to individual wallets, not to the whole workspace. In each case, we first assess whether address rotation with a communication plan would solve the problem instead.