# Wallet recovery One of the most challenging topics of deceterlized networks is key managment, it always been the achilles heel of the adoption of crypto. Our goal is to take the mental overhead and obsecure the complexity of key-managment from the user while delivering a seamsless experince. Lets explore the different approches to achive that, but before we need to go over the critrias to evalute them. ### Considertion and critrias **Security** - What are the security assumptions and attack vectors. **On-chain** - Is the recovery process involves interaction with the chain. **Multi party** - Are there other entities/actors involves in the recovery process. **Centralized** - Is the solution depends on one external entity? **Time** - There is a locking time or processing time for the request to carry out. ## Menu We have serval approaches we can take, in some scenarios it makes sense to combine two approaches, for example, an on-chain option can be accompanied by an off-chain option to enable more economic possibilities. ### Mnemonic seed Provide the user with its [mnemonic](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) of his seed, in that way the user can recover his wallet easily and instantly. ### Encrypted cloud copy The user generates an encryption key and encrypts his private key, then uploads the encryption key to Tweed servers and uploads the encrypted private key to cloud backup. To recover the private key, the user requests the encryption key from Tweed servers, and then he uses it to decrypt his encrypted cloud copy of the private key. ```sequence Note left of User: Private key backup User->User: Generate encryptKey User->User: encrypt pk User->Server: Send encryptKey User->Cloud: Send encryptedPK Note left of User: Private key Recovery Note right of Server: Server thinks Server->User: Get encryptKey Cloud->User: Get encryptedPK User-->User: Decrypt encryptedPK ``` ### Social recovery wallet As Vitalik suggested, a wallet-based contract to manage a multi-sig key recovery. All operation happens on-chain. The contract stores the public spending key and a list of guardians, that when the time comes, they can vote to update the contract public spending key. ### Secret sharing Split the key into shares and encrypt them for each guardian, so only the elected guardian can be exposed to the share of the key. When the user needs to recover its private key he will send a request to its guardians to retrieve shares of the key which he will combine into its private key. **Alternaitve approch:** Encrypt the key shares with encryptKey that he'll send to Tweed servers for storing so the guridans will be exposed only to the encryption of the shares. (the encryptKey is managed as in Encrypted cloud copy). --------------