The user will create their wallet with a specific recovery method provided, such as a google account.
When the recovery sequence is initiated, the user will send a OpenID Connect JWT token they fetch from their google account, generate a zk proof showing ownership of the token which is then verified on chain.
If the verification is successful, the account ownership will be transferred to a new address after a period of seven days, during which the original owners can submit a transaction to cancel the ownership transfer.
albert@fun.xyz
Please note that all of these steps will be abstracted away via the funkit core and funkit react SDKs.
Setup
Recovery
The zero knowledge proof on the OpenId Connect JWT token solves the biggest problem with JWT style verifications. By submitting a proof and not the actual JWT token onchain, we make it much more difficult for a third party to perform a replay attack. Additionally, we will have an expiration timestamp on the proof to prevent replay attacks.
The user will create their wallet with a group of N signers.
The recovery sequence can be initiated when M of N signers sign the same data and send this data in a userOp.
If the verification is successful, the account ownership will be transferred to a new address after a period of seven days, during which the original owners can submit a transaction to cancel the ownership transfer.
Please note that all of these steps will be abstracted away via the funkit core and funkit react SDKs.
Setup
Recovery
This idea is heavily based on Vitalik's vision for social recovery wallets: https://vitalik.ca/general/2021/01/11/recovery.html
The largest risk to this approach is a lack of availability for the current wallet owner. If the recovery signers collude, they could take ownership of the funwallet. To prevent this, we will allow funwallets to have arbitrarily long veto periods, wherein a transaction from the current wallet owner can stop the ownership transfer.
configuration = single userOp: superuser creates recovery group in UserAuth and configures the group in RBAC to allow it to call UserAuth.recover() and nothing else.
initiate recovery = single userOp: third-party calls initiateRecovery on UserAuth, providing group information for the new, receiving group, which after recovery will be the new superuser groupx
initiateRecovery()
), someone could just repeatedly call this function. Wouldn't it make more sense to make it such that only the recovery group can call initiateRecovery()?(timelock period)
confirm recovery = single userOp: recovery group calls UserAuth.recover() which overwrites the wallet’s superuser group (without changing the group ID).
What is the point of overwriting the wallet's superuser group? By superuser, do you mean owner?
If superuser != owner, what permissions does it have and when is the superuser group configured?