Account recovery use cases (social recovery and dead man's switch)

Feature requests
1

Idea name: Account recovery use cases (social recovery and dead man’s switch)
Description: Explore decentralized methods by which a User can recover their account if they loose their private key or seed phrase.
Use case: As a user, I have lost my seed phrase and I want to recover my account
Target user: Non-technical normal consumer users
Why this is important: Storing a seed phrase for a period of years so that A) it’s not lost and B) it’s not stolen or accidentally exposed is a difficult task.

Account recovery use cases

Below are some high level use cases for the purpose of UX design sketching out a bunch of strawman ideas for account recovery utilizing the functionality proposed in eip-2429 The purpose of this section is to iterate on and eventually agree the high level user flows, before embarking on

What is the problem we are trying to solve?

 
Currently most wallets either:

  • require users to write down a seed phrase during account creation
    OR
  • Delay the need for a user to write down the seed phrase until a later date
    OR
  • Sacrifice some mix of Security, Anonymity and Decentralisation to improve Usability

Problems with seed phrases in general:

  • Storing a seed phrase for a period of years so that A) it’s not lost and B) it’s not stolen or accidentally exposed is a difficult task. Blockchain history is full of people who have lost keys and seed phrases.

  • Anybody with the seed phrase can restore the wallet and gain access to all funds it contains.

  • If a user doesn’t write down the seed phrase, or if they lose the seed phrase, they have no means of restoring the wallet meaning all funds could be lost.

Problem with writing down a seed phrase during account creation:

  • Writing down the seed phrase is significant user friction during account creation, and this leads to significant dropoff.

Problem with writing down a seed phrase at a later date:

  • If the user deletes the app or loses the device before the seed phrase is written down they lose access to the wallet and all funds contained in the wallet.
  • Security risk of seed phrase being stored in the app prior to the user writing it down.

Who are we trying to solve it for

 
Given the objective of increasing the general public’s Ethereum adoption, the design should prioritize the needs of ‘Non-technical normal consumer users’. We also need to service the needs of ‘Advanced users with more complex requirements’ as a second priority.

Servicing the advanced user use cases should never degrade the normal consumer use cases.

Actor definitions

 
User = the Status user
Guardian = a person or entity performing the Guardian role
Guardian Friend = an individual who personally knows the User
Guardian Service = a service that can assist the User with account recovery
System = umbrella term for all software the User interacts with in these use cases

Terminology - use of the word “account”

 
This document currently uses the word “account” in the sense that the general public is used to when thinking about online services e.g. a user’s ‘account’ is their personal identity and content in an online service that they access with their credentials e.g. I can access my email account by entering my email server details and credentials into any email client or I can access my google account (where everything is stored in the cloud) by entering my credentials into google. In the case of Ethereum, I can access and use my on-chain Ethereum account by entering my credentials (private key / seed phrase) into a wallet / dapp browser.

My impression is that the word “account” is already used with the meaning defined above in the Ethereum ecosystem e.g. To access my Ethereum account in a new wallet, I need to enter my seed phrase into a wallet app. Thus there is already a user expectation in the Ethereum ecosystem that users have accounts that live on-chain, and a user’s account can be accessed by entering their seed phrase into a wallet app.

An alternative usage of the word “account” that the public is also familiar with is using the word “account” in the ‘bank account’ sense. A user may have multiple accounts with the same bank, and each account is a pot of money. It may be possible to use the word “account” with these two meanings concurrently e.g. When I access my HSBC online banking account I get to see the balances in my current and savings accounts.

For now this document uses the word “account” to represent a User’s on chain Ethereum account (which they access with their private key / seed phrase), but it’s acknowledged that this may is a confusing issue and the terminology used in this doc may need to be changed.

Strawman 1 - Basic social recovery

 

User sets up social recovery

  1. System notifies the User that they should set up some form of account backup when the funds in the User’s wallet become more than X. Options are: write down seed phrase and/or setup social recovery.
  2. User opts to set up recovery, app shows User a list of their contacts and Guardian Services. Each contact must have a name and an Ethereum account.
  3. User selects which contacts and/or Guardian Services to nominate as their Guardians.
  4. User selects the % of Guardians required to perform recovery
  5. User sets up a password. To aid User memory, the user could be asked to enter their existing Status app password.
  6. System validates that the password entered matches the User’s Status app password.
  7. System generates secret and Recovery URL.
  8. User is prompted to save the Recovery URL to somewhere where it won’t be lost. It doesn’t need to be stored very securely, it’s sufficient for the user to store their Recovery URL in their cloud storage or email it to themselves.
  9. System writes the social recovery contract to the blockchain, User pays gas. In this transaction the User also funds the social recovery contract with a small amount of ETH so that the contract contains sufficient funds to pay the gas required to execute social recovery in the future. The amount of ETH held by the social recovery contract should be sufficient to cover a reasonable increase in gas prices. To cover the case that gas prices rise beyond the expected amount, it needs to be possible to contribute additional funds into the social recovery contract at a later date.
  10. System confirms to User that social recovery has been successfully set up.

Then to perform a recovery (assuming recovery is happening on a new device)

  1. User installs the their EIP-2429 compatible wallet app
  2. User sees welcome screen and chooses ‘Recover account’
  3. User enters their recovery password and Recovery URL to initiate recovery
  4. User selects which of their Guardians they wish to use for recovery. The user enters a current email address for each selected Guardian Friend.
  5. System sends the Guardian Friends an email letting them know that the User needs help recovering their account. Email contains a ‘recovery request code’ (unique to each Guardian) and instructions for the Guardian Friend. Included is a request that the Guardian Friends should first verify that the request is genuine by directly speaking to the User, perhaps via video call. Guardian Services also receive the ‘recovery request code’, how they receive this code depends on the Guardian Service.
  6. Guardian(s) perform the requested actions (see usecase below titled “Guardian Friend assists with a recovery” and the “Guardian Services” section for more details)
  7. User views a screen that shows which Guardians have completed their recovery action, which Guardians they are still waiting on, and how many more Guardians need to perform their recovery action to complete the recovery (e.g. ‘two more guardian signatures required to complete recovery’). User can also reveal the ‘Recovery request code’ for each Guardian, to support the case where the User needs to give this code to a Guardian manually.
  8. Once sufficient Guardians have performed their recovery actions, a ‘Complete recovery’ action is presented to the User.
  9. User presses ‘Complete recovery’
  10. System creates a new account for the User, the old account is subsumed into the new account. Gas for this final step in the recovery process is paid from the funds stored in the recovery contract, because the User won’t have access to their own funds until the recovery process is completed.
  11. If the User has previously revealed their seed phrase, they are informed that their previously revealed seed phrase is no longer valid. They are then given the option of revealing and writing down their new seed phrase. They can also choose to not reveal their seed phrase at this time.
  12. User is now logged into the Status app with their account and IM username recovered
Variation - User cannot get enough Guardians to respond and therefore needs to request recovery from different Guardians

6.1 User cannot get a sufficient percentage of the Guardians they selected to respond
6.2 User taps ‘request recovery from a different set of Guardians’ (wording tbd)
RETURN TO STEP 3

Variation - Gas prices have risen to the extent that the social recovery contract no longer holds sufficient funds to execute the social recovery

6.1 Guardian(s) perform the requested actions (see usecase below titled “Guardian Friend assists with a recovery” and the “Guardian Services” section for more details). When Guardians sign the recovery request, they each contribute a small amount of ETH so that the social recovery contract will have enough funds to execute the final transaction that is needed to complete the recovery.
RETURN TO STEP 7

Question: is there a reliable way for a contract to see the current gas price? Does this require an oracle, therefor introducing an oracle dependency risk?

Guardian Friend assists with a recovery

Note: this flow has the Guardians signing off on the recovery directly on chain. The advantage of this approach is that the UX is easier for Guardians who don’t use Status, the disadvantage of this approach is that each Guardian has to spend some gas to sign off on the recovery. There is an alternative approach where the Guardians sign off-chain and they send a generated signature back to the User. The User then submits the signatures they have received on chain to initiate the recovery. In this alternative approach there is only one gas paying event when the User submits all the signatures. Revisit question of which flow is preferable in low-fidelity mocks.

  1. Guardian Friend receives email requesting their help with recovering the User’s account. Included in the email is a ‘recovery request code’ and a message asking the Guardian to first conduct a video call with the User to validate that this is a genuine request.
  2. Guardian conducts a video call with the User to validate their identity
  3. a) If Guardian is using Status or another wallet that supports Guardian recovery, they navigate to the ‘Assist friend with account recovery’ screen, enter their ‘recovery request code’ and then sign the recovery request.
    b) If Guardian is not using a wallet that supports Guardian recovery, they navigate to the ‘Guardian recovery request dapp’, enter their ‘recovery request code’ and then sign the recovery request.
    The gas for this action is paid by the Guardian.
  4. A message is displayed thanking the Guardian Friend for assisting with the account recovery.

Strawman 2 - User changes their social recovery settings (inc. Guardian list)

 

When a user wishes to change their guardian list

  1. User taps ‘change social recovery settings’

  2. If the User has previously exposed their seed phrase: User is presented with two options: wait one month to make social recovery changes and their seed phrase stays the same, or they can make the changes immediately but their current seed phrase will become invalid and a new seed phrase will be created.

    If the User has not previously exposed their seed phrase they move directly into the usecase titled “User has not previously exposed their seed phrase and the want to change their social recovery settings”

User has previously exposed seed phrase and they choose to change their social recovery settings immediately

CONTINUING FROM ‘When a user wishes to change their guardian list’

  1. User is warned again that their seed phrase will change, and asked if they still wish to continue.
  2. User is asked to sign a transaction. Behind the scenes a new set of keys is created for the User.
  3. System displays the User’s previous social recovery settings.
  4. User makes the changes they wish to make to their social recovery settings.
  5. User finalizes the changes to their social recovery settings and pays gas. Funds stored in the previous social recovery contract to pay for recovery gas are moved to the new social recovery contract.
  6. A new Recovery URL is generated and the user is prompted to store the Recovery URL somewhere where they won’t lose it. It doesn’t need to be stored very securely, it’s sufficient for the user to store it in their cloud storage or email it to themselves.
  7. User given the option of revealing and writing down their new seed phrase. They can also choose to skip this step and not reveal their seed phrase at this time.
  8. System informs the user that their social recovery settings have now been updated

Note: this usecase avoids imposing a delay on the user when they wish to change their guardian list by creating a new set of keys, and then creating a new social recovery contract on top of the new keys.

User has previously exposed seed phrase and they choose to wait a month before changing their social recovery settings in order to retain their current seed phrase / keys

CONTINUING FROM ‘When a user wishes to change their guardian list’

  1. User enters their Recovery URL and password
  2. Timer starts - User cannot change their social recovery settings for roughly X days.
  3. User’s wallet starts displaying a message saying something along the lines of ‘Guardian list change requested, tap ‘cancel’ if you didn’t make this request’. A persistent countdown timer is displayed somewhere, possibly somewhere in Profile.
  4. After the timer completes counting down, the user receives an in-app notification letting them know that they can now edit (or disable) their Guardian list and social recovery settings.
  5. User finalizes their changes to the guardian list and/or social recovery settings and pays gas.
  6. A new Recovery URL is generated and the user is prompted to store the Recovery URL somewhere where they won’t lose it. It doesn’t need to be stored very securely, it’s sufficient for the user to store it in their cloud storage or email it to themselves.
  7. System informs the user that their social recovery settings have now been updated

User has not previously exposed their seed phrase and the want to change their social recovery settings

CONTINUING FROM ‘When a user wishes to change their guardian list’

  1. User is asked to sign a transaction. Behind the scenes a new set of keys is created for the User.
  2. System displays the User’s previous social recovery settings.
  3. User makes the changes they wish to make to their social recovery settings
  4. User finalizes their changes to the guardian list and/or social recovery settings and pays gas. Funds stored in the previous social recovery contract to pay for recovery gas are moved to the new social recovery contract.
  5. A new Recovery URL is generated and the user is prompted to store the Recovery URL somewhere where they won’t lose it. It doesn’t need to be stored very securely, it’s sufficient for the user to store it in their cloud storage or email it to themselves.
  6. System informs the user that their social recovery settings have now been updated

User receives ‘Guardian list change requested’ message but they didn’t initiate this request

  1. User’s wallet starts displaying a message saying something along the lines of ‘Guardian list change requested, tap ‘cancel’ if you didn’t request this’.
  2. User taps ‘cancel Guardian list change’
  3. System displays a screen informing the User that their Recovery URL and Password may have been compromised and that the user should change their social recovery settings.

FLOW CONTINUES AT STEP 2 OF ‘When a user wishes to change their guardian list’ USECASE

Strawman 3 - Possible Guardian Services

 
The idea here is that we create a standard for Guardian Services, and then Guardian Services can be created and operated independently and used in any Wallet that supports EIP-2429.

Note: we could specify a minimum number of Guardians needed to setup social recovery.

Simple Guardian Service that only validates control of an email account

  1. User selects ‘setup Email Guardian Service’

  2. User provides an email address to Guardian Service to setup the Guardian Service

  3. (optional) User pays the Guardian Service a small amount of ETH to the Guardian service. This ETH is for: pre-payment to the Guardian Service for the gas costs the Guardian Service will incur in a future recovery, and also for any fee the Guardian Service may wish to charge for their service.
     
    Then at some point in the future when the User needs social recovery…
     

  4. When User requests recovery, a message that contains a ‘recovery request code’ is sent to the the Guardian Service

  5. Guardian service sends an email to the email address the User originally specified.

  6. User clicks on a link in the email to confirm they have control of the email address

  7. Guardian Service signs the recovery request on-chain and pays the gas for this transaction.

Simple Guardian Service that only validates control of a mobile number

  1. User selects ‘setup Mobile Number Guardian Service’

  2. User provides a mobile number to Guardian Service to setup the Guardian Service

  3. (optional) User pays the Guardian Service a small amount of ETH to the Guardian service. This ETH is for: pre-payment to the Guardian Service for the gas costs the Guardian Service will incur in a future recovery, and also for any fee the Guardian Service may wish to charge for their service.
     
    Then at some point in the future when the User needs social recovery…
     

  4. When User requests recovery, a message that contains a ‘recovery request code’ is sent to the the Mobile Number Guardian Service

  5. Mobile Number Guardian Service sends a txt to the phone number the User originally specified.

  6. User clicks on the link in the txt to confirm they have control of the mobile number.

  7. Mobile Number Guardian Service signs the recovery request on-chain and pays the gas for this transaction.

Simple Guardian Service that validates via answers to secret questions

  1. User selects ‘setup Secret Questions Guardian Service’

  2. User selects a number of questions from a list and then provides answers to these questions to the Guardian Service

  3. The User’s public key is provided to the Guardian Service

  4. (optional) User pays the Guardian Service a small amount of ETH to the Guardian service. This ETH is for: pre-payment to the Guardian Service for the gas costs the Guardian Service will incur in a future recovery, and also for any fee the Guardian Service may wish to charge for their service.

  5. Secret Questions Guardian Service is now set up
     
    Then at some point in the future when the User needs social recovery…
     

  6. User requests recovery from the Secret Question Guardian Service.

  7. The system passes the ‘recovery request code’ to the Secret Question Guardian Service

  8. Secret Question Guardian Service serves the User’s questions in an embedded webview

  9. User answers all of their secret questions correctly

  10. Secret Question Guardian Service signs the recovery request on-chain and pays the gas for this transaction.

Guardian Service that uses full KYC info to respond to a recovery request

Precondition: User has already signed up to the KYC service.

Note: This type of Guardian Service could either be a real world entity, or in the future it could also possibly be a decentralised identity service like iden3.io Existing centralized crypto exchanges like Coinbase, Kraken, etc… could potentially offer this service to their customers.

  1. User selects a KYC provider to use as a Guardian Service.

  2. If the KYC provider is a centralized service (e.g. an exchange), the User authenticates with the KYC provider via OAuth.

  3. (optional) User pays the Guardian Service a small amount of ETH to the Guardian service. This ETH is for: pre-payment to the Guardian Service for the gas costs the Guardian Service will incur in a future recovery, and also for any fee the Guardian Service may wish to charge for their service.

  4. KYC Guardian Service is now setup
     
    Then at some point in the future when the User needs social recovery…
     

  5. User requests recovery from the KYC Guardian Service, a message that contains the ‘recovery request code’ is sent to the KYC Guardian Service

  6. User gets in contact with this KYC Guardian Service, and goes through whatever process the KYC Guardian Service specifies to prove their identity.

  7. KYC Guardian Service signs the recovery request on-chain and pays the gas for this transaction.

Traditional Web Identity Guardian Service

Precondition: User has already signed up to the traditional web identity service.

  1. User selects a web identity (OAuth) service to use as a Guardian Service e.g. Google, Facebook, Microsoft, etc…

  2. User authenticates with the web identity service via OAuth.

  3. (optional) User pays the Guardian Service a small amount of ETH to the Guardian service. This ETH is for: pre-payment to the Guardian Service for the gas costs the Guardian Service will incur in a future recovery, and also for any fee the Guardian Service may wish to charge for their service.

  4. Web Identity Guardian Service is now setup
     
    Then at some point in the future when the User needs social recovery…
     

  5. User requests recovery from the Web Identity Guardian Service, a message that contains the ‘recovery request code’ is sent to the Web Identity Guardian Service

  6. User authenticates with the web identity service via OAuth

  7. Optionally, the web identity service could ask the user further identifying questions

  8. Web Identity Guardian Service signs the recovery request on-chain and pays the gas for this transaction…

Keycard as a Guardian Service

  1. User selects ‘setup Keycard as a Guardian Service’

  2. User is prompted to tap the Keycard on their device

  3. User pays a small amount of ETH into the Keycard contract wallet. This ETH is to pre-fund the keycard Guardian Service for the gas costs that will be incured in a future recovery.

  4. System confirms that the Keycard is now setup as a Guardian Service
     

    Then at some point in the future when the User needs social recovery…
     

  5. User requests recovery from the Keycard Guardian Service

  6. User is prompted to tap their Keycard on the device from which recovery is being requested.

  7. Keycard Guardian Service signs the recovery request on-chain and pays the gas for this transaction.

Note: like all other Guardian Services, the User can set up multiple Guardian Services of the same type. In the case of the Keycard Guardian Service, this allows the User to setup a social recovery scheme that utilises multiple Keycards.

Guardian Service provides an additional service where they watch the blockchain for Guardian list change requests on behalf of the user

  1. User provides the Guardian Service with the address of their wallet contract
  2. Guardian Service watches the blockchain for any Guardian list change requests that impact users of their Guardian Service
  3. When a Guardian list change request is detected, the Guardian Service uses the contact information they have on file for the user to inform them that a Guardian list change request has been detected.

Strawman 4 - Utilise social recovery to restore a keycard

 

User sets up Keycard social recovery

  1. User decides to set up social recovery for their keycard, app shows User a list of their contacts and Guardian Services. Each contact must have a name and an Ethereum account.
  2. User selects which contacts and/or Guardian Services to nominate as their Guardians.
  3. User selects the % of Guardians required to perform recovery
  4. User sets up a password. To aid User memory, the user could be asked to enter their existing Status app password.
  5. System validates that the password entered matches the User’s Status app password.
  6. User is prompted to tap their keycard on their phone
  7. System generates secret and Recovery URL.
  8. User is prompted to save the Recovery URL to somewhere where it won’t be lost. It doesn’t need to be stored very securely, it’s sufficient for the user to store their Recovery URL in their cloud storage or email it to themselves.
  9. System writes the social recovery contract to the blockchain, User pays gas. In this transaction the User also funds the social recovery contract with a small amount of ETH (which could perhaps then be converted into ’Chi Gastoken’?) so that the contract contains sufficient funds to pay the gas required to execute social recovery at a later date. The amount of ETH/’Chi Gastoken’ held by the social recovery contract should be sufficient to cover a reasonable increase in gas prices. To cover the case that gas prices rise beyond the expected amount, it needs to be possible to contribute additional funds into the social recovery contract at a later date.
  10. System confirms to User that social recovery has been successfully set up.

Then to perform a recovery (assuming recovery is happening on a new device)

  1. User navigates to ‘restore keycard via social recovery’
  2. User enters their recovery password and Recovery URL to initiate recovery
  3. User selects which of their Guardians they wish to use for recovery. The user enters a current email address for each selected Guardian Friend.
  4. System sends the Guardian Friends an email letting them know that the User needs help recovering their account. Email contains a ‘recovery request code’ (unique to each Guardian) and instructions for the Guardian Friend. Included is a request that the Guardian Friends should first verify that the request is genuine by directly speaking to the User, perhaps via video call. Guardian Services also receive the ‘recovery request code’, how they receive this code depends on the Guardian Service.
  5. Guardian(s) perform the requested actions (see usecase titled “Guardian Friend assists with a recovery” and the “Guardian Services” section for more details)
  6. User views a screen that shows which Guardians have completed their recovery action, which Guardians they are still waiting on, and how many more Guardians need to perform their recovery action to complete the recovery (e.g. ‘two more guardian signatures required to complete recovery’). User can also reveal the ‘Recovery request code’ for each Guardian, to support the case where the User needs to give this code to a Guardian manually.
  7. Once sufficient Guardians have performed their recovery actions, a ‘Complete recovery’ action is presented to the User.
  8. User presses ‘Complete recovery’
  9. System creates a new account for the User, the old account is subsumed into the new account
  10. User is prompted to tap their new Keycard on their phone to transfer their new private keys to the keycard.
  11. If the User has previously revealed their seed phrase, they are informed that their previously revealed seed phrase is no longer valid. They are then given the option of revealing and writing down their new seed phrase. They can also choose to not reveal their seed phrase at this time.
  12. System confirms to User that their Keycard as been successfully recovered.

Strawman 5 - dead man’s switch for recovery of funds from an account

 
This is a complementary form of account recovery that can be used in parallel to storing a seed phrase and social recovery.

User sets up dead man’s switch for recovery of funds from their account

  1. User decides to set up a dead man’s switch fund recovery mechanism for their account.

  2. User enters the following information:

    • Period of time their account needs to be inactive for before recovery can be initiated (default unit of time is years)

    • Length of waiting period after recovery is initiated before recovery can be completed

    • Ethereum address (or addresses) that are permitted to initiate recovery.

  3. User can optionally choose a specific address or multiple addresses for the funds to be distributed to when recovery completes. If the user selects multiple addresses, they have to choose what % of funds to go to each account. These addresses can be different from the addresses permitted to initiate recovery. If the user doesn’t choose a specific address or addresses for the funds to go to, when recovery is complete the funds will be transferred to the address that initiated recovery.

  4. User signs and pays gas to setup contract

  5. System confirms to the user that the dead man’s switch is successfully set up.

Account recovered via dead man’s switch

  1. User’s account is inactive for X years.
  2. Friend who owns one of the whitelisted addresses pings the contract to initiate recovery.
  3. System waits for the specified waiting period to expire.
  4. Friend who owns one of the whitelisted addresses calls the account contract to initiate the distribution of funds.
  5. System distributes funds according to how the User specified when the dead man’s switch was set up.

Dead man’s switch account recovery canceled by User

  1. User’s account is inactive for X years
  2. Friend who owns one of the whitelisted addresses pings the contract to initiate recovery
  3. System enters the specified waiting period
  4. User sees alert informing them that their dead man’s switch has been activated.
  5. User performs any interaction with the account contract that requires signing with their private key e.g a transfer out of the account
  6. Countdown to fund distribution is in effect cancelled (If one of the white listed addresses tries to call the contract to initiate the distribution of funds, the operation will not succeed because the User’s account became active again during the waiting period.

Dead man’s switch configuration changed by the User

  1. User decides to change their dead man’s switch recovery configuration
  2. User selects the new dead man’s switch configuration that they desire
  3. User signs and pays gas to modify contract
  4. System confirms to the user that the dead man’s switch is successfully modified.

due to discuss character limit the Q&A section of this post had to be moved into a google doc, see Account recovery Q&A - Google Documenten

2

Great work diving into the details of social recovery options @John This is a lot to absorb and I’m sure this is the condensed version of all considerations. Below are comments and questions from my side. Given how much the project relies on the smart contract design and security model, I’d like to invite @ricardo3 and @0kok0k to chime in to answer some of the questions.

TL;DR My opinion on next steps: Basic recovery, strawman 1, in combination with Keycard as a Guardian Service, strawman 3.6, seems most defined, principled and appealing to follow up as a model for social recovery. Converging, this should be the focal point. As part of this focus, I suggest investigating (more) ways to delay or relay the user’s recovery costs, e.g. by offering mutual guardianship only.

Comments and questions

Strawman 1

  • point 3: You mention Recovery password, not sure where this is set. I assume this is equal to the password used unlock/sign with your keys on Status. Is that right?
  • point 11 Once an account is recovered, and the seed phrase is subsumed, what happens if that seed phrase is used? E.g. in a wallet that doesn’t support eip-2429. Is that possible at all or is this question irrelevant?
  • point 12 I’m not clear on how the chat key would be generated when using this contract account, before and after recovery, and consequently how the chat key would be recovered. The description that the user receives a new seed phrase to me implies a new account is used, thereby implying that a new chat keypair would be derived
  • I would love to understand more ways to enable funding of ‘recovery gas’ after the recovery contract has been set up or when recovery has occurred (i.e. reimbursement to a guardian). Reason I would want to try and uncover all options here is that having ETH on onboarding is a recurring issue. Given the target audience, it’s likely they don’t have funds to prepay gas, if at all for the initial setup. A chain of thought: What about mutual guardianship, I pay for you to recover, but I know you’d also pay for me.

Strawman 2

  • I’d leave out options to update the social recovery contract, that require a seed phrase change for now. Unless they are critical to understand what methods need to be included in the contract design for auditing purposes

Strawman 3

  • I much appreciate seeing all options laid out because we are making tradeoffs compared to what users might be familiar with, including email, sms, and OAUTH based guardian services. Still, I’d consider a combination of the secret question, potentially in combination with Keycard to increase security as the best guardian service option. No reliance on 3rd party API’s, and no risk of matching personal data with accounts
  • Keycard might be distributed with a redeem code to solve the no ETH for gas issue

Strawman 4

  • I need to think more about this; it might be easier to set up social recovery for existing Keycard accounts. At the same time, the Keycard (cold storage) target user might be less reliant on social recovery (cc @guylouis @gravityblast @michele in case you’ve had any past conversations about social recovery for Keycard). Personally, I see Keycard more as a guardian within a recovery scheme for regular accounts.

Strawman 5

  • I really see a great use case here for execution of wills and saving accounts (e.g. funds released to your current account when turning 18). A separate future project in my view to be cherished for later
3

Impressive work @John, as per scenarios where keycard is used:
- Strawman 3 : keycard as guardian
I agree it makes a lot of sense. A simple way would be to use keycard cash applet on the card to sign a meta-tx provided by the wallet (or a dApp).This would not ask to the user for a card pairing code, neither a PIN. This meta-tx needs to be sent to the contract with some gas, this gas being either funded by a gas relayer or by a eoa that the wallet that’s used for the recovery controls.

- Strawman 4 - utilise social recovery to restore a keycard
Well I don’t get this one if we’re talking about the keycard being used as a hardware wallet. In this case, keycard is protecting an eoa, and I don’t get how social recovery could work.

1 Like
4

@hester thanks for the feedback

To reply to your comments and questions:

Strawman 1

 

Q from Hester:

A from John:
Yes you are correct, in these usecases the Recovery Password is currently equal to the password that is used to unlock/sign with your keys on Status. But I’m not 100% sure that this is the right approach.

The Recovery Password needs to be something that the user will always remember, if they forget this password then they are locked out of performing a social recovery. The idea behind re-using an existing password is that hopefully the User will find it easier to remember. One downside of using an existing password is that we would need to handle the corner case of when the User changes their Status password, do we then also need to change their social recovery password at the same time?

However there are other options available, for example the Recovery Password could instead be the answers to a number of personal questions e.g. name of first pet, mother’s maiden name, name of childhood best friend, etc, etc…

The Recovery Password could really be anything, but it needs to be something that A) only the User would know and B) something that the User is very unlikely to forget

I’m interested in hearing others thoughts about this…

Q from Hester:

A from John:

Good question! Seed phrases can be used to restore accounts into any compatible wallet, when it comes to restoring via seed phrase whether or not eip-2429 is supported by the wallet should be irrelevant. However I’m going to have to defer to @ricardo3 to check what happens when a old, superseded seed phrase is entered into a wallet that supports recovery via seed phrases. @ricardo3 what are your thoughts on this question?

Q from Hester:

A from John:

My understanding is that the old HD account is just nested under a new HD account, so that everything that was linked from the old HD account master key pair would still be available exactly as it was but under a new master key pair. @ricardo3 please correct me if anything I have said above is wrong.

Q from Hester:

A from John:

yes gas availability is a big challenge for social recovery. Initially I tried to find a way to make it possible for a User to setup Social Recovery in a very quick, lightweight way as part of the onboarding process, but I couldn’t find any solution that would work in practice, was scalable and didn’t have regulatory issues (e.g. a solution that didn’t involve us paying the gas or in-app crypto purchases). As a result I abandoned my experiment to see if it would be possible to bring social recovery into the initial signup flow. If anybody has any ideas on how this could be achieved I’m all ears!! :slight_smile:

Not setting up social recovery during new user onboarding means that we still have a dangerous gap in the user lifecycle when the user will lose their funds if their phone is lost or stolen or if the Status app is deleted. This gap only closes when the User either reveals their seed phrase and/or sets up social recovery. We prompt users to reveal and store their seed phrase once their funds grow above X amount, and in the future we can prompt users about social recovery in this same way, but it’s not an ideal solution.

Back to the topic of Gas - the other moment in the Social Recovery flow where there was a gas issue was at the point when the User needed to finalize the recovery of their account by performing an on-chain transaction. Because the User hasn’t recovered their account at the point this transaction needs to be made they are stuck in a catch-22; they can’t recover their account because they don’t have access to their funds, and the only way to get access to their funds is to recover their account!

The way this challenge is currently solved in these use cases is by getting the User to pre-pay some funds into the recovery contract, so these funds can be used to execute the recovery contract at a later date without needing access to ETH/gas. I also thought about using contributions from the Guardians to fund this final recovery step, but this introduces more complications so I walked back to the simpler approach of the User funding the recovery contract when it’s setup.

Re. reimbursing Guardian Friends for the gas costs they have incurred, I thought about some schemes to do this but then came to the conclusion that this can be solved offchain e.g. by the User buying the friend a beer next time they meet them, or by the User making a simple transfer of funds back to their friend as soon as their account is recovered.

Not sure if that fully answers your question??

Strawman 2

Q from Hester:

A from John:

Agreed, this is totally something that can be descoped from an MVP. This is only an optimisation so that a User can avoid the wait before changing their social recovery settings (at the cost of changing their seed phrase). Without this functionality the user will still be able to change their social recovery settings AND they will retain their seed phrase BUT they will have to endure a waiting period before they can make changes. Which IMHO is fine for the MVP

Strawman 3

Q from Hester:

A from John:

Agreed. As you mentioned, in this section I was mapping out all the different Guardian Services that could be created, and not taking a stance on should they be created or should we be the organization that creates them. Humm, I should probably have been more explicit that this was just a spread of what could be done…

Re. the Guardian Services, for me the important point is that we agree a common standard which any Guardian Services can plug into as part of eip-2429. Then other organizations can create Guardian Services, and User’s can use any Guardian Services from any Guardian Service supplier with any wallet that supports eip-2429.

Agreed that for us building the Keycard and perhaps the secret question Guardian Services make most sense. And even then, these are not strictly required for the social recovery MVP

Will follow up with replies to your other comments and questions in another post.

@hester thanks again for your feedback!

1 Like
5

Strawman 4

Q from Hester:

A from John:

This is probably also something we can descope from the social recovery MVP

Strawman 5

Q from Hester:

A from John:

Fully agreed; this feels like a separate project, and definitely something that is not needed in any social recovery MVP. But still good to keep in mind so that the smart contract defined wallet is architected in such a way that this functionality can be added later.

1 Like
6

Bumping this thread to say that Loopring released their wallet and it has social recovery via Argent-esque Guardians.

1 Like
7

Would like to try it out, but the apk file downloaded from the website isn’t working for me. Have you had any success with that @salutary_songbird?

8

I only have iOS :grimacing:

But you should mention them on twitter or something if you have that!

9

This topic was automatically closed 0 minutes after the last reply. New replies are no longer allowed.