Emergency Recovery
What is ERS?
The Emergency Recovery System (ERS) is a "break-glass" process for accessing private keys - and thereby funds - with no external dependencies. In an emergency, the wallet owner can recover a master key from:
- That master key's encrypted recovery information
- The corresponding RSA decryption key
From the recovered master key, all other private keys and addresses can be derived.
📘
Note:
ERS is used to recover the master private key material, not to restore the full wallet system runtime. Wallet/system restoration still relies on your DB backup process.
Recovery information contains encrypted key shares for each node. The designated recovery public key encrypts these shares, and only the corresponding private key holder can decrypt them. Store this private key offline in a secure location and access it only during emergency recovery.
Wallet Owner Responsibilities
The wallet owner is responsible for:
- Defining and implementing the Emergency Recovery Process -
ertoolrecovers keys, but the surrounding process (access controls, air-gapped environments, custodial procedures) is yours to design. - Tracking which addresses are relevant - knowing how many accounts and sub-addresses were present in the wallet at the time of recovery.
- Providing transaction-building software - a third-party wallet or custom tooling capable of generating unsigned transactions for the target blockchain(s).
- Providing blockchain connectivity - integration between signing software and the relevant blockchain network(s) for broadcasting signed transactions.
- Securely storing the ERS decryption key and encrypted backup blob - both must be preserved independently and accessed only during emergency recovery.
How to Create Master Key Recovery Information
Follow the steps below to create the master key and prepare ERS recovery information:
- On first launch, the wallet asks Policy Nodes to create a master key.
- Policy Nodes then:
- Create the master key and a key ID.
- Generate ERS recovery info and exchange it with each other (all nodes must agree).
- Mark the master key as operational, then send key ID and recovery material to the wallet.
- Wallet users download and securely store the recovery information.
📘
Note:
Validate and store recovery information before creating production accounts in the wallet.
ertool: Scope
Blockdaemon ships ertool, a bare-bones helper CLI for Institutional Vault private key recovery. ERS (Emergency Recovery System) is the broader break-glass process your organization defines and operates; ertool supports key-recovery steps within that process. It supports three operations:
- Recover master keys - decrypt and reassemble the master private key from the backup blob (
recover pemorrecover p11). - Derive sub-keys and addresses - walk the HD derivation tree to produce child private keys and their on-chain addresses.
- Sign data - produce signatures with any recovered or derived key (
sign ecdsa-secp256k1orsign ed25519).
ertool is the only moment when key shares are combined into a full master key. It operates independently of Institutional Vault and Blockdaemon infrastructure.
⚠️
Important:
ertoolis not a full Emergency Recovery System, a complete wallet, or a transaction builder. It does not replace scaling Policy Nodes, recovering individual node backups, or cloning a lost wallet.
ertool Quickstart
Run ./ertool --help to see all commands and ./ertool [command] --help for command-specific help.
Full Command List
Shell
ertool --help
Text
Blockdaemon Wallet Emergency Recovery Tool
Usage:
ertool [command]
Available Commands:
completion Generate the autocompletion script for the specified shell
derive Derive a private sub-key from a recovered private key; optionally print the associated address
help Help about any command
recover Recover a private master key
sign Sign a message with a recovered private key
version Print version information
Flags:
-h, --help help for ertool
Recovery supports two decryption backends as subcommands of recover:
Shell
ertool recover --help
Text
Recover a private master key
Usage:
ertool recover [command]
Available Commands:
p11 Recover a private master key with P11 decryption
pem Recover a private master key with a decryption key in a PEM file
Recover with HSM (P11)
Use recover p11 when the decryption key is HSM-protected.
Shell
./ertool recover p11 \
--backup-file wallet-backup.json \
--p11-key-label "ers-recovery-key" \
--p11-library "$P11" \
--p11-pin "$PIN" \
> recovered-master-key.json
P11 Recovery Flags
Shell
ertool recover p11 --help
Text
Recover a private master key with P11 decryption
Usage:
ertool recover p11 [flags]
Flags:
-b, --backup-file string path to encrypted backup file
-h, --help help for p11
-i, --p11-key-id string hex-encoded CKA_ID of key (optional)
-k, --p11-key-label string PKCS#11 label of RSA private key
-l, --p11-library string path to PKCS#11 library (.so/.dylib)
-p, --p11-pin string PKCS#11 PIN (e.g., 'cu_name:password' for Azure HSM)
-f, --p11-pin-file string file with PKCS#11 PIN (e.g., 'cu_name:password' for Azure HSM)
-s, --p11-slot uint PKCS#11 slot ID (default: 0)
-t, --p11-token-label string PKCS#11 token label (alternative to slot ID)
--p11-slot and --p11-token-label are mutually exclusive. --p11-pin and --p11-pin-file are mutually exclusive. --p11-key-label and --p11-key-id are mutually exclusive.
Example Azure HSM Recovery
Shell
./ertool recover p11 \
--backup-file wallet-azure-hsm-back.json \
--p11-key-label "ers-recovery-key" \
--p11-library /opt/azurecloudhsm/lib64/libazcloudhsm_pkcs11.so \
--p11-pin "cu1:user1234" \
> recovered-master-key.json
recover writes a JSON master-key blob to stdout (ECDSA secp256k1 and Ed25519 material). Redirect it to a file and pass that file to derive and sign.
Recover with PEM Key
Use recover pem when the decryption key is in a PEM file.
Shell
./ertool recover pem \
--backup-file wallet-backup.json \
--private-key-file recovery-key.pem \
> recovered-master-key.json
PEM Recovery Flags
Shell
ertool recover pem --help
Text
Recover a private master key with a decryption key in a PEM file
Usage:
ertool recover pem [flags]
Flags:
-b, --backup-file string path to encrypted backup file
-h, --help help for pem
-p, --private-key-file string path to private decryption key in PEM format
Derive Private Sub-Keys and Addresses
After master key recovery, use derive to derive private sub-keys and optionally print the associated address.
Shell
ertool derive --help
Text
Derive a private sub-key from a recovered private key; optionally print the associated address
Usage:
ertool derive [flags]
Flags:
-a, --account uint32 account number in the wallet's standard derivation path
-i, --address-index uint32 address-index in the wallet's standard derivation path
-t, --address-type string optional print of the address of a derived private key (possible values: canton, evm, p2wpkh, p2wpkh-testnet, polkadot, polkadot-westend, solana, stellar, tron)
-c, --coin-type uint32 coin-type of the asset in the wallet's standard derivation path
-d, --custom-derivation-path string a custom derivation path allowing arbitrary derivation, rather than using the standard path generated from (coin-type, account, address-index). E.g., "m/44/0/0" to derive the private key of a BIP44 Bitcoin account)
-h, --help help for derive
-p, --private-key-file string path to the private master key file
--custom-derivation-path is mutually exclusive with --coin-type, --account, and --address-index. Without --custom-derivation-path, derive builds m/44/<coin-type>/<account>/0/<address-index>.
derive Examples
Derive using standard wallet path components:
Shell
./ertool derive \
--private-key-file recovered-master-key.json \
--coin-type 60 \
--account 0 \
--address-index 0 \
--address-type evm
Derive using an explicit custom derivation path:
Shell
./ertool derive \
--private-key-file recovered-master-key.json \
--custom-derivation-path "m/44/60/0/0/0" \
--address-type evm
Sign Messages
After deriving a leaf key, use sign to produce a signature. Redirect derive output (without --address-type, or capture the key JSON) to a file, then sign.
Shell
ertool sign --help
Text
Sign a message with a recovered private key
Usage:
ertool sign [command]
Available Commands:
ecdsa-secp256k1 ECDSA secp256k1 sign a message with a recovered private key
ed25519 ed25519 sign a message with a recovered private key
Shell
ertool sign ecdsa-secp256k1 --help
Text
Usage:
ertool sign ecdsa-secp256k1 [flags]
Flags:
-h, --help help for ecdsa-secp256k1
-m, --message-file string path to file containing the message to sign
-p, --private-key-file string path to the private master key file
sign ed25519 uses the same flags.
sign Examples
Shell
./ertool derive \
--private-key-file recovered-master-key.json \
--coin-type 60 \
--account 0 \
--address-index 0 \
> recovered-eoa.json
./ertool sign ecdsa-secp256k1 \
--private-key-file recovered-eoa.json \
--message-file message.bin
For ecdsa-secp256k1, the message file is the hash to sign. For ed25519, hashing is part of the signing algorithm.
Derivation Paths
The Institutional Vault is a Hierarchical Deterministic (HD) wallet - all sub-keys are derived from the master key using BIP-44-like derivation paths. During emergency recovery you must know which derivation paths were in use to locate all on-chain funds.
Derivation Path Format
Shell
m/purpose/coin_type/account/change/address
Each component means:
- m: master node.
- purpose: set to
44(unhardened) for BIP-44. - coin_type: SLIP44 / chain coin type used by Institutional Vault for that chain.
- account: account index, starting at
0. - change:
0for external addresses (Institutional Vault always uses0). - address: address index, starting at
0.
Blockdaemon Derivation Paths
Use the chain's registered coin type with ertool derive --coin-type. For address printing, pass the matching --address-type.
| Blockchain | Environment | Derivation Path | --address-type |
|---|---|---|---|
| Bitcoin | Mainnet | m/44/0/account_index/0/address_index |
p2wpkh |
| Bitcoin | Testnet | m/44/1/account_index/0/address_index |
p2wpkh-testnet |
| Ethereum and other EVM (incl. Polygon, Base) | Mainnet / testnet | m/44/60/account_index/0/0 |
evm |
| Kaia | Mainnet / Kairos | m/44/8217/account_index/0/0 |
evm |
| Polkadot | Mainnet | m/44/354/account_index/0/0 |
polkadot |
| Polkadot | Westend | m/44/42/account_index/0/0 |
polkadot-westend |
| Solana | Mainnet / Devnet | m/44/501/account_index/0/0 |
solana |
| Canton | Mainnet / Devnet / Testnet | m/44/6767/account_index/0/0 |
canton |
| Stellar | Mainnet / Testnet | m/44/148/account_index/0/0 |
stellar |
📘
Note:
Institutional Vault derives most EVM chains (including Ethereum Sepolia and Polygon) with coin type
60, not BIP-44 testnet coin type1. Kaia uses coin type8217. Confirm the coin type registered for each chain in your deployment before recovery.
Example Emergency Recovery Process
Below is a recommended two-phase approach. Adapt it to your organization's security policies and infrastructure.
Phase 1: Key Recovery (Air-Gapped)
Perform recovery on an isolated, air-gapped system for maximum security.
- Decrypt the master private key using the RSA decryption key and
ertool(recover pemorrecover p11), redirecting stdout to a JSON file.- If the decryption key is HSM-protected, a connection to the HSM is required on the air-gapped system.
- Export the public master key and chain code from the recovered JSON.
- Transfer the public information only (public key + chain code) to an internet-connected system to query on-chain state. The private key must remain on the air-gapped system.
Phase 2: Fund Recovery
Use the public key on a networked system to locate funds, then sign on the air-gapped system.
- Identify relevant accounts and assets on-chain - use the public master key and chain code to derive public addresses (via
ertool deriveor equivalent tooling) and query blockchain explorers or nodes for balances. - Prepare recovery transactions - build unsigned transactions targeting a new secure destination address for each asset.
- Transfer unsigned transactions to the air-gapped system for signing with the recovered private key (via
ertool signor integrated signing software). - Sign and broadcast - sign each transaction on the air-gapped system, transfer the signed transactions back to the networked system, and broadcast them to the respective blockchain networks.
🗣️We Are Here to Help!
Please contact us via email or support chat if you encounter an issue, bug, or need assistance. Don't forget to include any relevant details about the problem. To request a wallet form and Institutional Vault Approver form, please click here or contact our sales team.
Updated17 days ago