Original author: Norswap

Original compilation: Deep Chao TechFlow

I thought a lot about wallets and user onboarding for 0x Fable. Below are some of my opinions. We will discuss:

• My ideal account structure;

• security considerations;

• Overview of existing Web3 login providers,

Obviously, it is not advisable to require users to install wallet software and save mnemonic phrases during the onboarding process. We need an approach that is friendly, relatively safe, and somewhat forward-looking.

Architecture

Each user gets their own Smart Account, which contains three keys:

• Device Key - Can be stored locally initially, but hopefully in the future passkeys/webauthn will be used.

• Supplementary keys, such as those controlled by the provider and unlocked through social login.

• Back up the key, e.g. with a third party (can be simply as an email attachment or on Dropbox/Google Drive).

If this sounds low-tech or insecure, Im afraid youve been fooled by the providers sweet talk, because theyre actually no more secure than that (many times even less - for example, keys (2) and (3) ) are controlled by the same party).

In this setup, you can use the device key to operate without user interaction. For transfers and transactions involving assets, you can request the use of supplementary keys.

The simple pattern is to have the user log in with Google/Apple/Facebook etc. and then add a confirmation prompt. This makes getting started easy. However, if the user requires more security, this key can be replaced with a traditional EOA. Additionally, any pair of keys can be used to replace the backup key, which only needs to be a file hosted in the cloud.

security analysis

How safe is this? For the most part, hes safe. Two devices or entities must be compromised at the same time for a loss of funds to occur.

The main thing is that there are some configuration risks that may reduce security. For example, host backup keys on Google Drive while assigning supplemental keys to your Google account. Or use a hot wallet as a supplementary key, which carries the same risks as a device key. The user may lose his backup. It is better to periodically prompt the user to rotate the device key, forcing him to find a backup key.

If the backup key is stored publicly, it is also highly susceptible to theft. This is even worse than hot wallets, which encrypt keys on disk (and require the password to be decrypted in memory). Regardless, the addition of pass keys (which allow you to log into the app using device authentication) will solve this problem.

Understand that social login means trusting a provider. The provider basically has a key that he can use however he wants, but he promises you that he will only use it at your request after you log in with your social account. Finally, please note that when the supplementary key is provided by the dapp creator, or there is no confirmation prompt, then it is very easy for the dapp creator to deceive users (because they wrote the frontend that owns the device key, and own or have control over the supplement key).

Overview of existing providers

Who offers this today? As far as I know, no. The problem is usually that either there is no backup key or it is held by the same entity (e.g. Coinbase wallet).

The market is mainly divided into two categories:

• Providers that offer integrated multi-key solutions either use smart accounts or use MPC (multi-party computation, a cryptography technique) to combine multiple keys into a single EOA.

• A lower level provider that holds user keys for you and allows them to sign after logging in.

There are many full-stack providers out there: Particle Network, Privy, Alembic Tech, Magic, Web3 Auth, Turnkey, Dynamic, 0x Pass, Fireblocks, Portal, Capsule, ZeroDev, Keyp, Circle Developers.

Key custodians such as: Lit Protocol, Amazon.

Yes, there is a lot of that. There is basically no difference between them. When the business model is transparent, these typically charge $0.02 to $0.05 per user per year. To me, this seems quite reasonable.

Interestingly, all of these are positioned as development tools. No company seems to be trying to apply these technologies to become the primary wallet for users.

Of course, to work with existing dapps, you need to install wallet software. Therefore, the benefits of the system are reduced to removing the mnemonic phrase. But you can also let dapps promote you as the easiest way to get started (without even installing wallet software if they integrate you). You gain users and the dapp can be easily started for free. Win-win.

Concerns about providers

In addition to not implementing my ideal architecture, these solutions often introduce large centralizing factors, like a REST API, or some MPC calculations that you wouldnt be able to do yourself if they went out of business (or even publicly released? Reviewed? ).

Its unclear what will happen if you stop working with the provider. They have (part of) your users keys! This is very similar to my concerns about Rollups-as-a-service.

After this, one RaaS founder told me that there is a trade-off between allowing easy exits and preventing founders from cheating their users (which would have a bad impact on RaaS).

Heres how to easily switch providers using the above architecture: Users submit a hash of their social account on-chain (e.g. gavin@hooli.xyz). Each social login provider has its own private key (its not necessary to have one for each user, and its generally not more secure). The smart account references a singleton contract that holds the current providers account. Switching providers is as easy as changing this account.

final thoughts

We are clearly moving towards the ideal Onboarding goal. Ideally, these easy-to-entry wallets have a direct relationship with their users. Dapps can then ignore this issue entirely and simply sign a partnership with the wallet to determine who the default login wallet is.

Failing that, my solution would have to be to roll out my own system - it wouldnt be difficult to create my own social login provider within the architecture above. However, I would rather use an external provider. As mentioned above, if the dapp creator controls the free keys, then the system is not fully decentralized.