“One of the great challenges with making cryptocurrency and blockchain applications usable for average users is security: how do we prevent users' funds from being lost…”
Vitalik in his blogpost “Why we need wide adoption of social recovery wallets”
Safe{RecoveryHub} solves this problem by allowing users to choose from a variety of recovery options to regain access to their Safe if they lose access to one or multiple signer accounts. In the following, we want to present how the foundation of the feature works and provide guides on how to enable different recovery setups.
How users can lose access to their Safe Accounts
Access to a Safe Account is arranged via signer accounts (owners) which, in turn, can be either externally owned accounts ("simple" crypto wallets) or smart accounts (like Safe). If a user loses access to the signer wallet there is a chance that they lose access to the Account.
Why a chance? It depends on the ownership setup. If the Account threshold allows other signers to operate without a signer that can't be accessed, then there is no issue e.g. the threshold is 1/2 or 2/3. No recovery is needed. The remaining signers will be able to remove the "bad" one. However, that's not always possible.
If you lose access to your "regular" externally owned account - for instance, your computer breaks and your seed phrase is lost - there is no way to recover the funds on it. No central authority - no backup.
If you keep your funds in a Safe smart Account and then lose access to your signer wallet, there's good news: you can recover your funds if you set up the recovery feature beforehand.
Ways to recover your Safe Account
At Safe we aim to provide the best user experience for all possible cases, hence we will gradually introduce several ways to recover access to the account. For now, there are 2 types.
Centralized recovery
The first type involves a trusted centralized third party. As of December 2023, we are planning to launch integrations with 2 such parties - Coincover and Sygnum. The main advantage of this approach is that one doesn’t have to care about private key safety. The main disadvantage, besides needing to trust an entity, is the necessity of KYC as recovery relies on your identity.
In a nutshell, you provide the trusted recoverer your ID and partial access to your Safe Account. If you lose access, you get back to them, provide your ID and they re-enable the access for you. This is similar to the “Forgot password” logic of Web2 services but with a greater level of security.
Decentralized Custom recovery
The second type involves no trusted third-party and gives you a great level of flexibility - a user can set up any blockchain account as a Recoverer. The only downside of this trustless approach is reliance on the Recoverer account(s) and the safety of their private key. There is no centralized authority to help you in case the Recoverer’s key is lost.
As of December 2023 the only implemented solution is a decentralized Custom solution, so this article focuses on that.
How Custom recovery works
Imagine the following case: there is a Safe Account with 2 signers and a threshold of 2/2, so to execute a transaction the Account will need the signatures of both signers. But something happens and the second signer account is no longer accessible.
What are Recoverers?
The owners of this Safe Account were smart enough to assign a Recoverer beforehand, that in this case comes in handy. A Recoverer is also a blockchain account (an EOA or a Smart Account) with 2 limitations as opposed to Safe Account owners:
Recoverers can replace all the current owners with one or more new owners (including themselves) and change the threshold.
Most importantly, transactions proposed by a Recoverer are delayed. During this time owners can reject the recovery proposal if they meet the threshold.
Owners can set up any account they trust as a Recoverer. It may be a friend or a family member, some trusted third-party or even their own account that they are sure they won't lose access to.
Recoverers can bypass any threshold and propose ownership changes - swapping, adding or removing owners and changing the threshold in a way that owners can regain access to a Safe Account should they have, for example, lost a signer.
Why is the delayed execution needed?
As mentioned, owners have a delay period in which they can reject a transaction that was proposed by a Recoverer. We leverage the fully audited and battle tested Zodiac Delay Modifier - a Safe Account module that is deployed during the setup of recovery.
A default of delay of 28 days is available but this time frame can be longer or shorter - the interface offers 7, 14 or 56 days, for example.
Why would an owner reject the proposed recovery proposal? There are 2 major use cases:
Recovery is not needed. For instance, the user managed to restore access to the second signer account from the above example, e.g. they found a lost seed phrase.
Recovery attempt is malicious. At the moment of setup the Recoverer was meant to be trusted but has bad intentions and wants to take over the account..
The delayed execution is a very important security measure given that the Recoverer can bypass the threshold of a Safe Account.
Two-step recovery execution
To execute a recovery proposal, a Recoverer will have to execute 2 transactions:
Recovery proposal which outlines the new owners and starts the countdown
Recovery execution itself which is available after the delay
Both actions are on-chain and require gas for execution.
It is important to mention that the proposal can only be done by a Recoverer while the execution is possible by any account after the delay period has passed.
Communication challenges
It’s very important to acknowledge that all the communication between the old owners, new owners and Recoverersis completely abstracted from the Safe{Wallet} interface. As of the initial release there is no form of notification sent on any of these occasions: recovery setup, proposal or execution.
With that said, a user must understand that if the assigned Recoverer initiates the recovery, Safe{Wallet} will not send any communication to the owner. The only way to find out that someone is trying to recover your Safe is to open the application and see the status.
Real-life use cases for recovery
Use your own account
You can be a Recoverer for yourself or shared Safe by setting up an Account. You should ensure that you’ve properly secured the private key of the Recoverer account.
This can be, for instance, a hardware wallet that is not used in any on-chain activity, and its seed phrase is securely stored on paper or memorized.
Use friends and family accounts
You can involve other persons with crypto wallets as Recoverers. We recommended gathering a small group of 2-3 people with wallets and asking them to deploy a Safe Account with at least a 2/n threshold (2/2, 2/3, etc). This Safe Account can then be assigned as your Recoverer (yes, a Safe Account can recover another Safe Account!).
Why is this approach better than just assigning a friend with a crypto wallet as a Recoverer?
Less trust is needed. If there needs to be a quorum of 2+ people to recover, there’s less of a chance that 1 person can take over your Account
Less chances that the Recoverer is unavailable. If the setup of the Recoverer Safe Account is ⅔, it means that one of the owners can lose access and the remaining 2 can still execute recovery for your Account.
Note that besides the addresses, ENS domains are supported in the Safe{Wallet} UI and you as a Safe Account owner can deploy a Recoverer Account yourself, adding your friends’ addresses or ENS and sharing it with them.
How to set up the account recovery
The following is a step by step guide on how to setup recovery in the Safe{Wallet} interface.
Recovery can be set up either from the home page (see the widget in the bottom right corner of the screen), or from Settings > Security & Login.
You will be prompted to choose the recovery method. As of December 2023, only Custom recovery is available so proceed with this option to continue.
After the intro screen outlining how recovery works you’ll land on the configuration page where you need to specify the following:
Trusted Recoverer address - either a wallet or a Safe Account
Recovery delay, the time frame during which you can reject the recovery, 28 days by default
Transaction expiry, the time frame during which the recovery can be executed after the delay expires. By default it’s infinite.
e.g. if the delay is 28 days and the expiration is 1 day it means that a Recoverer will have to:
Propose a recovery
Wait for 28 days
After 28 days pass they’ll have 1 day to execute the recovery attempt
If they fail to execute in 1 day then the recovery transaction expires and will not be executable. The Recoverer will then have to start the process over again.
After executing, the setup transaction will appear in the History as MultiSendCallOnly one.
In Settings > Security & Login, you’ll see your recovery setup which can be edited or completely removed if you decide that you don’t need recovery anymore.
How to initiate and execute an account recovery
If you connect a Recoverer account to a Safe Account, you’ll immediately see the prompt to recover theSafe Account which one can dismiss, e.g. to explore the Account before recovering it.
As mentioned above, a recovery transaction will alter current Safe Account ownership and threshold.
Before execution, the Recoverer can see the delay period . Note: despite the recovery attempt being a proposal, a Recoverer will still need to pay gas and execute a transaction. Why? They publish the hash of the proposal on the blockchain for greater security. If you feel like you need a more in-depth explanation of the underlying process, refer to this article.
After the transaction is executed a Recoverer will see the confirmation screen.
The transaction will remain in the Safe{Wallet} queue until it is executable.
If you connect a current owner signer, there will be a Cancel button available. Cancellation is possible both during the delay and after it expires.
After the delay period ends, the Recoverer can execute the recovery transaction.
After execution, the recovery transaction will appear in the history as normal ownership management transactions. In our case, since we swapped one owner for another, it’s shown as a swapOwner.
At this point, the owner structure has been successfully changed and recovery is complete.