via u/vbuterin on reddit

Multisig wallets (eg. Gnosis Safe) are an easy and safe way to store funds, and can give you most of the key benefits of self-custody - namely, your funds not being subject to disappearing because a centralized entity that seemed trustworthy turns out not to be at all - without the risks of having to be personally responsible for your entire security setup. I use a multisig wallet personally to store the bulk of my funds, as does the Ethereum Foundation.

A close cousin of multisig wallets is social recovery wallets, where a single key can be used to sign transactions but if that key is lost, a group of keys held by other people can be used to recover the funds. Social recovery wallets are much easier than multisig wallets to use, especially with the rise of ERC-4337 account abstraction and upcoming wallets like Soul Wallet that will make the technology user-friendly. In general, once social recovery wallets become mature enough, my recommendation will be to use social recovery for hot wallets that store a small portion of a person or organization's funds, and multisigs for cold wallets that store a person or organizations's savings.

Both multisig wallets and social recovery wallets rely on a concept of guardians: a set of N addresses, typically held by other people, of which any M can approve an operation (eg. one could set N=6 and M=4). In the case of a multisig wallet, each transaction must be signed off on by M of the N guardians. In the case of a social recovery wallet, there is a single key that can sign transactions, but if that key is lost, M of the N guardians must sign a message to reset the key.

Two key questions in using multisig wallets and social recovery wallets securely are: (i) whom do you choose as guardians, and (ii) what instructions do you give them? This post will outline how I think about this issue. The ideas here should mostly apply equally to multisig and social recovery wallets being used to secure funds for individuals and for organizations.

• Minimize the chance that they lose their keys
• Minimize the chance that they collude to steal your money, or get coerced into doing so
• To the extent that the above two risks are unavoidable, the risk of each guardian should be maximally uncorrelated - you want to minimize commonalities that risk situations that will disable or compromise too many of your guardians at the same time.

This answer is simple and short, but it guides all of the choices that I make with regard to guardians.

It makes natural sense to have at least one guardian be a wallet on one of your own devices - it doesn't reduce decentralization to do that, and after all, it is your money. Once you go above one guardian controlled by yourself, however, you get into a tricky tradeoff: you get to trust other people less, but you're also concentrating more power into yourself, which can create a risk if you get hacked, coerced, or incapacitated or die.

My rule of thumb is that enough guardians should be controlled by other people that if you disappear there are enough other guardians left to recover your funds. That is, you should control at least 1 guardian, and at most N-M guardians. Also, each guardian should be on a separate device (laptop, phone, old phone, etc).

Ideally, the guardians should not know who each other are. This greatly reduces the risk that they collude, and furthermore there is no good reason for them to know each other. If something happens to you, they will still be able to find each other, because there are obvious standard protocols that naturally come to people's minds in such a situation (eg. contact your family).

Also, you want to minimize correlations between your guardians as much as possible: don't choose two guardians who live in the same city (or ideally even the same country), or two guardians who use the same type of wallet, and have a balance between different operating systems.

When you ask a guardian to approve an operation for you (in a multisig, this would be any transaction, and in a social recovery wallet, this would be resetting your account's key), they should not simply say yes immediately. This would be a disaster for security: if someone hacks into your chat account, they could scan your messages, figure out who your guardians are, contact each of them and ask them to confirm, and thereby steal your funds.

My preferred protocol to avoid this is to instruct guardians to ask a security question. That is, when you ask for a confirmation on your operation, the guardian should ask you something that only the two of you and very few other people know (eg. “the last time we met, what kind of food did we have?”), and only confirm the operation if you give the correct answer. A natural alternative is voice or video calls, but in the age of AI deepfakes this is weaker evidence than before, and so you may want to combine the voice/video call with asking some kind of security question.

If you're doing degen stuff with on-chain contracts, you may need to act quickly: pull money out if a contract gets a vulnerability, move money around if you are close to being liquidated, etc. If your needs include this, then you want to find guardians who can act quickly on short notice (and therefore also, guardians in different time zones, so enough guardians to complete a transaction are awake at all times) to protect your funds. If you do not do these kinds of things, however, then speed is not particularly important, and in fact may even be slightly harmful, because convincing people of the need to act urgently is a common social engineering tactic used by hackers and it can be good to have people who are by default mentally averse to that.

Make a test operation at least once a year. Ideally, make two test operations each year, using half your guardians for one and the other half of your guardians for the other. This makes sure that your guardians haven't forgotten or lost their accounts.

One of the challenges with guardians today is that the tech does not yet exist to make it possible to protect your financial privacy from your guardians. However, this is a technical problem that can be solved technically: instead of guarding your account directly, the guardians guard a “lockbox” contract where the link between your account and the lockbox is hidden. Making the link stay hidden until a recovery needs to be made is pretty easy: for example, your account could have as a guardian a CREATE2 contract that only the lockbox can create. Making the link stay hidden even after a recovery, however, requires more advanced ZK-SNARK tech. Hence, this is a problem that I expect will slowly be solved over the next few years.