Skip to content
VaultKeepR

Recovery

Recovery covers two cases: getting back into your own vault when devices are lost, and passing the vault to beneficiaries after your death. Both live in the open-source @vaultkeepr/recovery and @vaultkeepr/legacy packages.

Fragmented recovery

Section titled “Fragmented recovery”

The recovery flow uses Shamir secret splitting. You split the master key into encrypted fragments and set a threshold: the number of fragments required to reconstruct the secret. The SDK default is 2 of 3, and the threshold is configurable.

The fragments go to storage channels you configure: IPFS, on-chain pointers in the VaultKeeperFragments contract on Base L2, and other channels offered in the app. The chain stores fragments and pointers only, never derived keys.

A recovery identifier (generateRecoveryId) is a secret you retain, separate from your wallet. Public APIs reference fragments or manifests by a hash of that identifier (computeLookupIdHash), so a random caller cannot enumerate your recovery data.

Recovery re-derives the master key on device, from your password plus a wallet signature. Reassembling a threshold of fragments with combineFragmentsAndDecrypt restores the vault.

No central reset

Section titled “No central reset”

We cannot reset your master password or decrypt your vault on your behalf. Recovery depends on the fragments, the recovery ID, and the threshold you set. There is no support-desk backdoor, by design. If you lose the fragments and the recovery ID, the ciphertext stays ciphertext.

Before relying on fragmented recovery for a production vault, run a full dry run with a test vault: distribute the fragments, confirm the threshold restores access, and verify you can locate the recovery ID. Do not delete or overwrite the main vault until the flow has worked end to end.

Digital legacy

Section titled “Digital legacy”

@vaultkeepr/legacy implements time-locked inheritance backed by the VaultKeeperLegacy contract on Base L2. The owner registers a beneficiary list, a delay, and a grace period in days. The master key travels only inside ECIES envelopes encrypted to each beneficiary’s public key; the chain stores pointers, the beneficiary list, and timing, never keys.

A heartbeat mechanism (proof of life) pushes the deadline forward while the owner stays active. After the deadline passes without a heartbeat, a beneficiary can call claimLegacy and receive the master key and vault CID from the IPFS envelope bundle. The owner can revoke the setup at any time with revokeLegacy.

Source files

Section titled “Source files”