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 - ertool recovers 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:

1. On first launch, the wallet asks Policy Nodes to create a master key.
2. Policy Nodes then:
   1. Create the master key and a key ID.
   2. Generate ERS recovery info and exchange it with each other (all nodes must agree).
   3. Mark the master key as operational, then send key ID and recovery material to the wallet.
3. 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 pem or recover 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-secp256k1 or sign 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:

ertool is 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

ertool --help

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:

ertool recover --help

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.

./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

ertool recover p11 --help

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

./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.

./ertool recover pem \
  --backup-file wallet-backup.json \
  --private-key-file recovery-key.pem \
  > recovered-master-key.json

PEM Recovery Flags

ertool recover pem --help

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.

ertool derive --help

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:

./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:

./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.

ertool sign --help

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

ertool sign ecdsa-secp256k1 --help

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

./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

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: 0 for external addresses (Institutional Vault always uses 0).
• 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.

📘

Note:

Institutional Vault derives most EVM chains (including Ethereum Sepolia and Polygon) with coin type 60, not BIP-44 testnet coin type 1. Kaia uses coin type 8217. 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.

1. Decrypt the master private key using the RSA decryption key and ertool (recover pem or recover 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.
2. Export the public master key and chain code from the recovered JSON.
3. 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.

1. Identify relevant accounts and assets on-chain - use the public master key and chain code to derive public addresses (via ertool derive or equivalent tooling) and query blockchain explorers or nodes for balances.
2. Prepare recovery transactions - build unsigned transactions targeting a new secure destination address for each asset.
3. Transfer unsigned transactions to the air-gapped system for signing with the recovered private key (via ertool sign or integrated signing software).
4. 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.