• Steve begins by signing up on our platform. During the registration process, he completes a Know Your Customer (KYC) verification and provides his blockchain address to ensure his identity and account security.

• Next, Steve needs to designate a lawyer and may choose any number of other trusted individuals, such as Amy, Jamie, and Paul, to be part of his recovery set.

• Steve must provide at least two contact methods (e.g., email and phone) for each person he designates.

• If Steve doesn't designate a lawyer or at least one other person, we can assign one for him at an additional cost.

• Steve is responsible for notifying all designated participants about their roles in the recovery set.

• The lawyer will automatically inherit access in the recovery process.

• Steve then determines the number of participants (`t`) required to regenerate the key. This number must be at least 2 and no more than `n-1` (where `n` is the total number of participants Steve has designated).

• Once the participants are notified, they need to complete their own KYC process and sign up on the platform.

• Steve will personally contact Amy, Jamie, and Paul to inform them.

• Each participant will provide their email address to our secure phone line.

• If the provided information matches, we'll send a sign-up email containing a token that identifies each participant. This token will expire after a set period.

• Each participant will then choose a password, generate an asymmetric key pair (public/private) on their device, store the private key securely (e.g., on their laptop), and send the public key to our server for storage.

• ​​

• Note: The key pair generation happens on the client side using JavaScript, similar to how PGP or SSH keys are created.

• Once the server receives the public keys from `t+1` participants, Steve is invited to create the shares of his key.

• On Steve's device:

  • If Steve is using a web browser, the private key is downloaded to his device.

  • If using a computer, Steve may need to use a hardware security device like YubiKey.

  • On a smartphone, the private key is stored in the device's secure enclave.

• The server sends Steve the public keys (ECDH) of the `t+1` participants.

• Steve enters his seed phrase and generates `n` shares of it.

• Each share is first encrypted with Lockbox's CEG key (`LockboxCEG[share]`), and the hash of this encryption is sent to Lockbox for verification.

• The encrypted share is then re-encrypted using the public ECDH key of the respective recovery set member, resulting in `Member_n_ECDH[LockboxCEG[share]]`.

• A third-party service holds one share as a backup. This ensures that even if a participant loses their device or forgets their password, the share can still be recovered through a secure process involving the third party. This backup is secured in such a way that a random employee cannot access it without going through proper channels.

• Finally, the server sends the encrypted shares to the appropriate participants, storing the hash of each share for future verification.

​

This method ensures that Steve's key can be securely regenerated by the designated participants while protecting the shares through multiple layers of encryption.