Backup and recovery across the Fireblocks MPC workspace — the workspace backup and the owner’s device key share backup.
Fireblocks uses MPC-CMP in a 3-of-3 setup: two of the three key shares live with Fireblocks, and the third lives on the wallet owner’s device (in its secure enclave). Every vault and address in a workspace is derived from a single workspace master key (a BIP32 HD wallet), so one backup covers the entire workspace.CoinCover sits alongside Fireblocks as the backup and recovery layer. The integration is API-based — CoinCover provides an RSA public key through the Partner API, which is used to encrypt the material that needs protecting. There are two independent backup flows, because there are two distinct risks: Fireblocks itself becoming unavailable, and the owner losing their device.
The encrypted backup package (.zip) and the RSA private key
Owner’s key share backup
The owner losing their device
The encrypted auto-passphrase and the RSA private key
In both flows CoinCover holds only encrypted material and the RSA private key — never a share it can use on its own. The RSA private key is held encrypted at rest and only ever handled in plaintext within our hardware-isolated key vault.
The integration is API-based: CoinCover generates an RSA-4096 key pair through the Partner API, hands the public key to Fireblocks, and holds the private key. The two flows below both reuse that same key pair.
Protects against Fireblocks becoming unavailable. This is a one-time setup at onboarding that covers the whole workspace.
1
CoinCover provides an RSA public key
CoinCover generates an RSA key pair via the Partner API. The public key is sent to Fireblocks; the private key is held by CoinCover, encrypted at rest.
2
Fireblocks encrypts its two cloud key shares
Fireblocks encrypts its two key shares with CoinCover’s RSA public key.
3
The customer encrypts their device share
The workspace owner sets a recovery passphrase — known only to them — which encrypts their device key share.
4
Everything is bundled and stored
All three encrypted shares are bundled into a single .zip and sent to CoinCover for secure storage.
CoinCover holds the backup .zip and the RSA private key, but the device share inside the .zip is encrypted with the customer’s recovery passphrase, which CoinCover never sees. Without that passphrase the third share can’t be decrypted, so CoinCover alone can’t reconstruct the wallet.
Protects against the owner losing or breaking their device. It’s a separate, per-owner flow, triggered when the CoinCover service activates on that owner’s device — but it reuses the workspace RSA public key.
1
The owner enrols
The owner receives an enrolment prompt on their device and confirms it with face verification.
2
The app generates an auto-passphrase
The Fireblocks app generates an auto-passphrase — random, internal, and never shown to the user. It’s distinct from the workspace recovery passphrase.
3
The auto-passphrase is used twice
The auto-passphrase encrypts the device key share (held by Fireblocks), and a copy of the auto-passphrase is itself encrypted with the workspace RSA public key and sent to CoinCover.
Separation of concerns: Fireblocks holds the encrypted device share, CoinCover holds the encrypted auto-passphrase that unlocks it, plus the RSA private key needed to decrypt that passphrase. Neither party can recover the share alone.
The two flows above protect the keys. Vault sync protects the derivation paths — the record of every vault and address in the workspace and how each is derived, which is what’s needed to rebuild the accounts at recovery. It’s a one-time link-up, recommended at onboarding, that keeps CoinCover’s copy of those derivation paths continuously up to date.
1
Link the workspace to CoinCover Control
The customer sets up an API user in CoinCover Control and links their Fireblocks workspace to it. Ideally this is done during onboarding.
2
CoinCover pulls the account data every 24 hours
Using that API access, CoinCover pulls the account’s wallet data on a 24-hour cycle, maintaining a current, complete set of the derivation paths for every vault and address in the workspace.
3
The synced record is ready for recovery
Because Control already holds an up-to-date set of derivation paths, a workspace recovery can return them as a CSV alongside the key material, with no manual export needed.
Vault sync is optional but strongly recommended. Without it, a workspace recovery still returns the keys, but the customer has to export their own vault report from Fireblocks at recovery time or rebuild every account manually. With it in place, the current derivation paths are always ready — so we encourage customers to complete this linkage during onboarding.
There are two recovery flows, matching the two backup flows. Both are initiated in CoinCover Control and gated the same way: release only happens after identity verification and your approval policy are satisfied, with risk flags routed to manual review. When you raise the request you also supply a public GPG key — CoinCover uses it to encrypt the recovery package so it’s protected in transit, and you decrypt it locally with the matching private key.
Workspace recovery — when Fireblocks is unavailable
1
Request recovery through CoinCover Control
Submit a recovery request from the CoinCover Control dashboard.
2
Approval gate
Release is gated by identity verification and your approval policy before any material is released.
3
CoinCover releases the held material
CoinCover returns the backup .zip and the RSA private key. If the workspace is synced, the release also includes the vault sync package — the current derivation paths for every vault — so the customer has everything needed to rebuild all their accounts. The release is encrypted to the GPG public key you supplied, so you first decrypt it with your GPG private key before using the material.
4
Reconstitute with the Fireblocks Recovery Utility
On an air-gapped machine, the customer supplies their recovery passphrase and uses the Fireblocks Recovery Utility to decrypt the shares, reconstitute the workspace key, and move assets to a new wallet provider. The derivation data needed to rebuild every vault comes back as a CSV alongside the key material — from the synced record in Control if vault sync is set up, or from the customer’s own exported vault report if it isn’t.
The recovery passphrase set at onboarding is always the customer’s to hold — CoinCover never sees it, so it must be stored safely ahead of time.
End result
Assets across every vault and address in the workspace are recovered in a single operation, because all derivations come from the one master key inside the .zip.
Owner device recovery — when the owner lost their device
1
Put the account into recovery mode
The Fireblocks account is placed into recovery mode on the Fireblocks side.
2
Request recovery through CoinCover Control
The owner requests recovery via CoinCover Control. The same approval gate applies before anything is released.
3
CoinCover decrypts and releases the auto-passphrase
CoinCover decrypts the stored auto-passphrase with the RSA private key and returns it to the customer, encrypted to the GPG public key they supplied. The customer decrypts it with their GPG private key to obtain the plaintext auto-passphrase.
4
Restore to a fresh device
On a new device, the owner enters the auto-passphrase. The Fireblocks app pulls the encrypted share from Fireblocks servers, decrypts it, and restores it to the new device’s secure enclave.