I’m interested in developing a social recovery guard + module for Gnosis Safe and was wondering if the community is interested and/or if something like I’m proposing already exists? Besides recovering ones own wallet this should also aid family members in inheriting digital assets from users who become incapacitated or somehow other are unable to access their assets.
Core Functionality
Safes can assign a list of recovery agents and their respective delays
Recovery agents can only recover the safe after it has been inactive for the duration of their delay
Each recovery agent can have a custom delay (allows expressing recovery priority preferences)
Safe inactivity is tracked via the last authorized transaction
Upon recovery the recovery agent will replace the owners of the safe
Mechanics
Storage
For each safe the recovery contract will keep track of the following data:
recoveryAgentRoot: Merkle tree of approved recovery addresses and their recovery delay
ping: timestamp when safe last executed an authorized transaction
recoveryAgent: Currently active recovery agent, address(0) if none
Logic
Logic - Pinging
As a safe’s guard the recovery contract will update the safe’s ping when it’s triggered with either the checkAfterExecution or checkTransaction hooks.
Logic - Recovery
To initiate recovery the calling account will pass the merkle proof along with a new set of owners to replace the old.
Other Considerations
Having recovery agents keep track of and store the merkle proofs associated with a safe could be complex and not very user friendly. Instead it may be better to keep track of the recovery agents in an array directly in the contract, while this comes at a higher cost it could be worth it considering the low amount of addresses that are likely to be recovery agents for a given safe.
Thoughts & Feedback
I’ve really been looking to make my setup more secure and convenient with social recovery but haven’t really found a good solution so far. I’ve started using Safes a bit more and looking into them and I really like the existing UX and feature set (especially the mobile app) so I thought this would be a great extension considering the nice module + guard system Safes have.
Let me know what you think about the idea and design and to what extent it’d be useful for you.
This is a massive long-term opportunity for individuals and organizations/businesses. The core functionality provided above is a great v1/proof-of-concept.
Other multisig products offer a form of social recovery.
They are more centralized than Safe, less customizable, and often don’t allow the user to maintain complete ownership of the backup process through seed phrases if they wish in addition to the social recovery aspect.
Core functionality feedback
Custom delays are great
Defining the agent ownership threshold is important to maintain the same level of security as the original multisig Safe under the original ownership structure.
By defining the agent ownership threshold I mean that the original Safe owner should be able to decide the ownership quorum after a recovery has been completed.
Sample rules
I’d like Bob or Alice to be able to recover my Safe with a delay of 56 weeks.
Once a recovery has been completed all transactions require a 3 of 5 approval from Bob, Alice, Chip, Dale, and Ellina.
First, you need to enable the module, and your Goerli Safe needs to have a small amount of ETH if you want to use ‘subscription mode’.
Smart contract is written in a way that safe ownership can’t be ‘stolen’ by me or anybody else, and can only be transferred to a user defined address after a certain time period.
This module has a time lock of 10 minutes, which means that if you initiate ‘Inactive for’ recovery in 2 minutes (120 seconds). The recovery will finish in ~12 minutes.
After 2 minutes a script it will initiate recovery, and after additional 10 minutes it will finalise it. In the end the recovery address will have 1/1 Safe ownership.
Disclamer:
This is just a test version, so please don’t get mad if you encounter
I’m interested in the community opinion.
In real scenario that recovery time lock would be longer. so that the owner can cancel the recovery upon receiving multiple email notifications. ‘Farewell’ email msg and email address would be encrypted, and the UX/UI would be better.
Rather than relying solely on inactivity, I’d love the option to have a 2-step recovery process for the recovery party. E.g.
The recovery party is first required to submit a transaction to indicate their intent to acquire ownership. A delay period begins and an event is emitted so that Safe owner(s) can be notified of the recovery party’s intent to acquire ownership.
The existing safe owner(s) can submit a transaction to cancel the request any time during the delay period. Otherwise, after the delay period is over, the recovery party can finalize the request to transfer ownership.
The two-step approach removes the burden on Safe owner(s) to submit arbitrary transactions in order to maintain “activity”. I’d imagine this would be particularly useful in the case the Safe is used for cold storage. It also removes the need to update a timestamp field on every transaction that would be required to track activity, saving a little gas.
@bxmmm1 do you have any updates since your last post? Or do you consider these done / ready to go?
@Philogy what approach did you go with in the end?
I have not made any updates or additional work as it did not receive any significant engagement or interest from the community.
Allow me to clarify the two-step process in my version.
The safe owner makes a deliberate decision to transfer the ownership of the Safe to a specified address, let’s say ‘0x123’. Additionally, they enable the recovery mechanism, which is triggered if the Safe remains inactive without any new transactions for a predetermined period, such as 10 days (customizable).
After the specified duration elapses and no new transactions occur within the Safe, the recovery process can start.
To complete the recovery, two on-chain transactions are required:
initiateTransferOwnership:
This transaction can be initiated by anyone and serves as the starting point for the safety countdown timer. The countdown period, which can be customizable but, for the purpose of this example, let’s assume it is set to 30 days. At this stage, the Safe still belongs to the original owner, who retains the ability to cancel the recovery within the 30-day timeframe.
Assuming no action is taken by the owner during this period, 30 days after the initiateTransferOwnership transaction, the second transaction takes place. In this transaction, the ownership of the Safe is transferred to the designated address, ‘0x123’.
I see this module as a hybrid web2/3 app due to the necessity of a notification system. It is essential to avoid the scenario where setting up the recovery process and subsequently neglecting it becomes a possibility. This web2 infrastructure would be accountable for executing recovery transactions automatically on-chain and sending emails to both Safe Owners and Safe Inheritors.
Recovery options are extremely important for the ecosystem. Happy to see this interest in creating recovery modules. I created two custom recovery modules for myself, see github. One focussed on inheritance (no guardians needed) and one for secret social recovery (with guardians and custom secrets).
