The Fireblocks Recovery Tools Are Free. Here's What They Prove, and What They Don't

Fireblocks gives every workspace owner an open-source path to reconstruct their keys from the customer-held backup: the legacy fireblocks-key-recovery-tool and the current Recovery Utility. This is genuinely good design: your exit from the platform does not depend on the platform being alive.

But “the tool exists” and “we are recoverable” are different claims. This article walks through what the tooling actually does, what a successful run proves, and the gap between that proof and what a board, an auditor, or a regulator means when they ask “can you recover?”

What’s in the backup

The backup kit is a ZIP archive containing:

metadata.json: the registry of per-key-set algorithm, public keys, chain codes, and key-set identifiers. This is the reference everything is checked against.
The encrypted cloud key shares, plus mobile shares wrapped under your recovery passphrase or RSA key.

Every workspace carries key material on both curves, MPC_ECDSA_SECP256K1 (Bitcoin, EVM chains) and MPC_EDDSA_ED25519 (Solana and others), so any complete recovery exercise has to handle both.

What verify mode does

Run without the private-key flag, the recovery tool:

Unwraps your shares with the recovery key (RSA-OAEP for cloud shares; passphrase-derived for mobile shares).
Recombines them via Lagrange interpolation over the curve order (standard Shamir-style reconstruction).
Derives the public key from the reconstructed private key, internally.
Compares it against the registered public key in metadata.json and prints the extended public key with a Verified! confirmation.

The important property: the private key is reconstructed in memory but never displayed or exported. Revealing the xprv requires an explicit flag and an extra confirmation. Verification and exposure are deliberately separated, and that separation is what makes routine checking viable at all: you can prove the backup works without creating a key-handling incident in the process.

What a successful verify run proves

A Verified! on an air-gapped machine proves, for that moment:

Your recovery key/passphrase is correct and available.
The backup decrypts and the shares are internally consistent.
The reconstructed master keys match what the platform registered; the backup really controls your vaults.

That is real, load-bearing assurance. It is also strictly point-in-time, key-level assurance.

What it doesn’t prove

Freshness and coverage. A verify run checks the backup you have, not the workspace you run. Key material added after your last backup is silently absent from it. Unless someone reconciles backup contents against the current workspace on a schedule, “we verified the backup” can be true while “the backup covers our assets” is false.

Wallet-level reachability. The legacy tool stops at the master extended keys. Deriving the thousands of actual wallet addresses, enumerating which of them hold balances across chains and derivation paths, is a separate exercise (the newer Utility derives wallets; discovery at scale is still on you).

The long tail. Reconstruction gets you signing capability. It does not unstake bonded ETH, exit a lending position, unwind LP tokens, or bypass a vesting lock. Those assets cannot be swept; they can only be runbooked: protocol-specific exit steps, unbonding timelines, validator interaction. For many institutional portfolios this long tail is a material fraction of value, and it is exactly the part no recovery tool can automate away.

Operational readiness. The tool ran for whoever ran it, on that machine, that day. Whether your team, minus the one person who set it up, can do it under stress, against a clean machine, with documented procedures, is an organizational property no software run demonstrates.

Evidence. A terminal printing Verified! is not an artifact you can hand to an auditor in eighteen months. If the run isn’t captured as signed, timestamped, tamper-evident evidence, organizationally it didn’t happen.

The questions worth asking instead

If you operate an MPC custody setup with customer-held backups, Fireblocks or otherwise, the recoverability question decomposes into five sharper ones:

When did we last verify the backup, and can we show evidence of it?
What fraction of current key material does that backup actually cover?
For each asset class we hold, is it sweepable, or does it need a runbook? And does that runbook exist?
Who, other than one specific person, can execute the recovery, and when did they last rehearse it?
Would any of the above survive an auditor’s scrutiny as written evidence rather than verbal assurance?

The vendor’s free tooling is the floor: it makes recovery possible. Everything a regulator or board actually asks about lives above that floor: scheduled, evidenced, rehearsed, and covering the assets a sweep can’t touch.