Skip to main content

Backup & recovery

The operational store (key storage) is engineered for availability and zero-trust access — not durability against an event that takes the entire AWS account offline. The backup path is what protects against that scenario.

Backup strategy: dead drop​

Every share — including each refresh — is written to a second store the moment it is created in the operational store. The second store is an S3 bucket in a different cloud provider, configured as append-only:

  • Versioning enabled, so re-using a key cannot overwrite history.
  • Object Lock enabled, so existing objects cannot be deleted.
  • Bucket policy denies the producer any read or delete permission — only PutObject is allowed. The producer can never see what it has previously written.

Each object is encrypted with age before upload. age was chosen over GPG for ergonomics — small, modern, no key metadata, and a single binary artefact. The recipient public key is the only material the running system needs; the corresponding private key is generated air-gapped and kept off any digital system.

The result is a write-only audit trail of every share that has ever existed, encrypted to a key that the running system cannot decrypt. We call the pattern dead drop because the producer drops material into a place it cannot read back.

Recovery model​

Recovery is the inverse path: rebuild the ability to sign for a wallet without rebuilding the private key.

Required inputs at recovery time:

  • A threshold (t) of share holders, each able to retrieve their backup ciphertext from the dead-drop store.
  • Their age private keys, brought together for the ceremony.
  • The derivation paths in use for the wallet — these are stored outside Custody, since the system itself is what the recovery is meant to bypass.

The ceremony assumes holders are co-located on the same network, either physically or via a VPN. A guided application walks each holder through decrypting their share, re-establishing the MPC state with the others, and producing one of two outcomes:

  • In-place restore — the wallet is re-imported into a fresh Custody deployment with the same public keys and balance.
  • Sweep — funds are moved to externally-controlled wallets, ending the Custody-managed lifecycle for those addresses.

In neither flow does the private key materialise as a single value. Sweep flows in particular preserve the property that no one party ever sees the full key, even during recovery.

What the system needs from outside itself​

Two pieces of information must live outside Custody for recovery to work:

  • The age recipient private keys (held by the share custodians, off-system).
  • The derivation paths in use per wallet (committed to a separate record of truth — typically the integrator's own ledger).

Without either of these, the ciphertext in the dead-drop store is recoverable material but not actionable material.

Out of scope here​

  • Per-share rotation cadence and lifecycle states — see Key lifecycle.
  • The encryption-at-rest model for the operational store — see Key storage.