# 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  
Shell

```shell
ertool --help
```

Text

```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

```shell
ertool recover --help
```

Text

```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

```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

```shell
ertool recover p11 --help
```

Text

```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

```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

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

### PEM Recovery Flags  
Shell

```shell
ertool recover pem --help
```

Text

```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

```shell
ertool derive --help
```

Text

```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

```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

```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

```shell
ertool sign --help
```

Text

```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

```shell
ertool sign ecdsa-secp256k1 --help
```

Text

```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

```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

```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**: `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`.

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

# 🗣️We Are Here to Help!  
Please contact us via [email](mailto:support@blockdaemon.com) 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](/content/support/index.html) or contact [our sales team](/content/get-in-touch/?contact-sales/index.html).

Updated17 days ago