This forum is a read-only archive. Posting, replying and signing in are disabled.

Social / multi-factor recovery on Algorand?

Generalalgorand-walletsmart-contracts
Kcarter
KcarterKevin

Are there any plans to build social recovery wallets on Algorand (whether it be part of the official Algorand wallet or separately) similar to Argent wallet on Ethereum?

For those who are unfamiliar with social recovery wallets, the general idea is that they allow users to recover a lost wallet via separate cold storage devices and/or wallets you’ve previously designated as your “guardians”— enforced via smart contracts.

The main benefits are 1. No single point of failure, 2. Low mental overhead, and 3. Ease of transacting.

For a deeper dive on this, I feel that this blog post from Vitalik explains better than I.

I feel that this would be great to have on Algorand. Thoughts?

✔ Solved by fabrice in post #4
fabrice
fabriceFabrice Benhamouda

This looks very interesting.

I believe this can easily be done using a smart contract and a smart signature, where the main account is a smart signature contract account that expects to be called in a group with a smart contract call (that verifies the policy).

One great advantage of Algorand is that this would actually be very cheap to implement this in terms of transaction fees (0.002 Algo).

This would work very well for any basic transaction (transfer of Algos, transfer of ASA).
However, dApp calls may actually be a bit more complex (as they usually expect a single transaction for operations, as opposed to a group of two transactions).

An alternative design is to use only smart signatures + rekeying. This would have the advantage of being easier to use (no group of transactions) and cheaper (0.001 Algo / transaction), at the expense of flexibility (essentially rekeying would allow any change instead of a restricted set of changes - actually rekeying can be done very smartly allowing restricted set of changes but this would lead to a quite complex code where the TEAL code would re-compute the contract address on the fly…).

Maugli
MaugliLipovszki Gábor

Dear @fabrice ,
Social recovery wallets would be GREAT. But the devil is in the details: I don’t think that
with the present Algorand contracts and apps it can be done.
Reasoning: you told that a contract and an app could be used, where the app enables the payment txn of the contract. OK, but who owns the app? Who is the signer? It cant’t be the present owner of the wallet, since if (s)he loses the secret key, then (s)he won’t be able to sign the app. But it can’t be the wallet company neither, as Algorand doesn’t support the mass storage of states, only 64 key/value pairs can be stored in an app.
You also mention rekeying. That would be great, but who does the rekeying. The owner can’t do it, since (s)he has lost the wallet. So what, how to proceed? Please, be a little more explicit, so I could make a working example under testnet… Thanks a lot!

References:
Argent wallet website
Argent wallet contracts
Argent wallet specification

edited
fabrice
fabriceFabrice Benhamouda

There are many different ways of implementing it, with many trade-offs.

But here is a possible option: Alice wants to create a multi-factor wallet that 2-out-3 guardians about Bob, Charlie and Eve can recover.

  1. Alice creates a normal account on the blockchain.
  2. Alice creates the required application or opt-in to an application provided by the wallet company (the second option is probably better). As part of the application creation / application opt-in, Alice specifies the policy (2-out-of-3) and the addresses of the 3 guardians.
  3. Alice then signs a delegated logic signature that allows her account to be controlled by the application

Normally, Alice uses her normal secret key.

Alice can change her guardians and policy at any time by calling the smart contract.

But in case of loss of her secret key, she can ask Bob and Eve (for example) to perform a recovery action, e.g., rekeying to a fresh new key. The recovery action may be for example a group of 3 transactions:

  1. An application call from Bob to the application specifying that it agrees rekeying of Alice’s account to her new key.
  2. Similar application call from Eve. This application call will fail if it is not also done by Bob before - according to the policy)
  3. A rekey transaction allowed by the delegated logicsig (that will verify the presence of the previous application call)

You can imagine even more advanced flows where even normal transactions are approved by the application. This can be useful to allow large transactions to gather further approval.