Bringing Web2 users into Web3 - The future belongs to non-custodial wallets

Authors: Chen Li, Ivy Zeng, and Ivo Entchev, Youbi Capital

For Web2 users encountering Web3 for the first time, the initial experience (to put it politely) is not very pleasant. Traditional EOA wallets require a series of complex and tedious processes, including wallet generation, private key management, and mnemonic phrase storage. Next-generation non-mnemonic wallets attempt to alleviate this friction point by abstracting private keys and mnemonic phrases, allowing users to log in using their familiar Web2 social accounts with just a few clicks. Therefore, non-mnemonic wallets represent an important advancement for Web3 towards mass adoption.

One way wallet providers implement non-mnemonic wallets is through fully centralized account custody solutions. However, this runs counter to the original intention of Web3 applications. The correct solution should not come at the cost of users losing ownership of their accounts and self-custody to achieve the convenience of abstraction. Instead, it should strike an appropriate balance between the two based on user needs.

We are at a turning point in bringing Web2 consumers into Web3. The login process will be crucial in the next phase of growth. Therefore, creating a login and account management experience that aligns with the decentralized spirit of Web3 while providing the convenience and interoperability of Web2 is essential.

Because the login and account management experience is so important, we have been closely monitoring innovations in Web3 account infrastructure. Many developers also want to understand the latest developments in Web3 user login and our views on wallets. This article is intended for that purpose.

Trade-offs: Non-Mnemonic Key Management vs. Self-Custody

Recent iterations of all wallet products can be analyzed through their pursuit of two main but mutually constraining characteristics: non-mnemonic key management and self-custody. Non-mnemonic key management is the foundation for new users to seamlessly enter Web3. This means that users can log into accounts in the new environment without needing a mnemonic phrase or private key. Therefore, their onboarding process and account management are abstracted, similar to Web2.

From a technical perspective, this abstraction is achieved by wallet providers delegating the permissions of customer accounts to servers or third parties. For example, Magic Link requires users to obtain (official) authorization to access their cryptographic keys and uses a master key (protected by a centralized hosting service HSM on AWS) for decryption. Other methods reduce the risk of exposing the entire key by splitting the private key into multiple fragments and storing them in different locations, achieving a greater degree of decentralization.

Clearly, users need to make trade-offs between non-key and self-custody, which is important (if not completely sacred) for many cryptocurrency users, and the rationale is compelling. When wallet services rely on third parties, these third parties have the power to censor transactions or even take over assets. They may be subject to government regulation and intervention. Wallet services that rely heavily on service providers are also more susceptible to disruption in the event of malicious attacks or incidents.

So, how can we balance non-key and self-custody to achieve the best user experience? For Web3 applications, we can assume that their primary goal is to seamlessly convert Web2 users who are accustomed to using usernames/passwords or social logins but do not immediately possess a large amount of on-chain assets. As user assets grow, they often have higher demands for security and decentralization, at which point developers should consider adjusting the trade-offs between the two characteristics.

Finding the Right Balance: A Comparison of Existing Non-Mnemonic Wallets

Based on the framework above, we researched some representative non-mnemonic wallets and analyzed them according to their degree of self-custody and other relevant factors. These wallets are:

MagicLink, Web3Auth, Particle Network, Sequence, UniPass

New technologies such as secure cloud storage, MPC, and smart contracts enrich the design space of the next generation of wallets, providing users with a range of new features for managing and using their Web3 accounts. The improvements to EOA wallets mentioned above enhance user experience to varying degrees (as shown in Figure 1).

Figure 1: Applications of Cloud Computing, MPC, and Smart Contracts in Wallet Design

EOA wallets such as Metamask, Imtoken, and Phantom are the most localized and independent wallets, but they are also inevitably the most cumbersome in terms of user experience. Users need to learn how to securely store their mnemonic phrases or private keys and how to use them to import accounts to new devices. Account addresses derive from private keys, and if a private key is lost or stolen, the account address will be permanently locked or inaccessible.

The most straightforward alternative is to use custodial services, such as Magic Link. Custodians can grant account access simply through email or social login. However, the convenience of custodial services often comes with key security risks and centralization risks.

More complex methods typically involve MPC (SSS, TSS), such as Web3Auth and Particle Network. By splitting the key into several parts, multiple key holders must authenticate during login, thereby decentralizing management and reducing the risk of centralization.

In addition, there are successful implementations that combine smart contracts on top of MPC, introducing account management logic that allows users to reconstruct or reset the master key managed by MPC, further reducing centralization risks. The core of account management logic is to choose so-called guardians for deep customization, eliminating dependence on wallet service providers or specific guardians.

Besides addressing the trade-offs between non-mnemonic key management and self-custody, these non-mnemonic wallets can also be evaluated from six dimensions of user experience.

Gas Fees: Gas fees incurred on-chain when creating smart contract accounts (regular usage gas fees are close to EOA wallets)

Latency: Time spent on the creation and import process (for example, due to being an on-chain process, smart contract wallets typically take longer)

Ease of Device Replacement: Smoothly switching to a new environment or device

Security: The existence of single points of failure, including whether any individual party, such as a service provider or integrated frontend, has the ability to expose, reconstruct, or reset the complete key or credentials to fully control the account

Custodianship: Service availability and censorship resistance (i.e., the degree of dependence on service providers and whether custodians can access or freeze customer accounts)

Functionality: The ability to implement additional account management logic (e.g., funding gas fees, multi-signature, delegated signing)

Among these supplementary factors, security and custodianship are relatively imperceptible to users compared to significant factors like gas fees, latency, and additional functionality that greatly affect user experience. However, accidental events such as security vulnerabilities or service interruptions can have catastrophic impacts on businesses or individuals.

Magic Link (Custodial EOA Wallet)

Magic Link is a non-mnemonic wallet that supports email and social logins. After obtaining authorization from Magic Link, customers can download a copy of their private key from the custodian when logging into their account on a new device, thus avoiding the need to store and use a mnemonic phrase. Magic Link outsources the encrypted version of the private key to AWS HSM to directly serve clients, so Magic Link does not store the private key in plaintext.

Technically, Magic Link is equivalent to Metamask but adds the benefits of cloud hosting, allowing users to switch devices using online authentication. However, to provide the best experience for users, Magic Link officially uses a unique authentication server to grant access to the decryption key, making it a potential single point of failure in the workflow. If a hacker or insider gains access to the authentication server, they can fully control the user's account. Additionally, the decryption key may not be unique for each user, creating the possibility of bypassing the authentication server using keys from other accounts.

Figure 2: Magic Link (AWS Key Management Service)

We tested and evaluated Magic Link integrated with Zerion, and here are our findings.

Figure 3: Our Evaluation of Magic Link

Gas Fees: Low, as it is an EOA wallet

Latency: Low, similar to Metamask

Device Replacement: Easy, as the private key is transferred to the new device with access tokens (Email/OAuth).

Security: Low. Single point of failure. Complete private key exposed on the frontend

Non-Custodial: Low. High dependence on the authentication server, leading to poor service availability and weak censorship resistance

Functionality: Low. Not a smart contract wallet

Web3Auth (Distributed Custodial EOA Wallet)

Web3Auth is a popular wallet service provider that also supports social logins, allowing users to connect via social accounts to verify themselves across various applications. Various Web2 and Web3 applications have integrated Web3Auth, such as Chess.com, Opensea, and Skyweaver. Undoubtedly, social login is an attractive and even the most seamless authentication method for any consumer-facing application.

However, like Magic Link, the social login workflow requires the server to generate login requests and sign them using application keys, so it must be centralized. Although smart contracts can verify signatures using public keys provided to the authorized server, this is not a user-friendly process for end users.

To mitigate risks, Web3Auth adds other keys to the OAuth key, requiring multiple keys to jointly sign to reconstruct the complete key. When users first log into their social accounts (e.g., Gmail/Twitter), three key fragments are generated in a decentralized manner using Shamir Secret Sharing (SSS) and then stored separately. Here’s how these fragments are stored:

• Device Fragment: Generated and stored on the user's device, regenerated each time they log in on a new device

• OAuth Login Fragment: Generated on the OAuth server, then further split and stored in a node network, retrieved only when the OAuth code is validated

• Backup / 2FA Fragment: An additional fragment retained by the user, which can be stored on a separate device, in the cloud, or in email. This fragment must be used when logging into a new device.

Figure 4: Web3Auth (Shamir Secret Sharing, Social Login)

Currently, both the OAuth fragment and the backup fragment are controlled by Web3Auth through the Auth network, and these two fragments are used to reconstruct the complete private key. In services integrated with Web3Auth, such as Opensea and Sequence, users can authenticate and log into applications directly through their social accounts without any other requirements, making Web3Auth the sole account custodian.

Web3Auth can distribute backup keys to third-party storage. This way, when users log in from a new device, they can call the backup key to create a new device share in the environment. Delegating the storage of backup keys to third parties can reduce the risks of security vulnerabilities and censorship. Bitizen.org is a good example of this distributed custodial approach, using 2/3 TSS and the client's own cloud storage to store backup key shares. However, since service providers have complete access to users' cloud storage, privacy issues are a significant drawback.

Gas Fees: Low. Not a smart contract wallet

Latency: Low. Immediate login

Device Replacement: Simple. Social login and password, or just social login

Security: Low. Single custodian. Complete private key exposed on the frontend

Non-Custodial: Low. Service highly dependent on Web3Auth, with no censorship resistance

Functionality: Low. Not a smart contract wallet

Our testing of Web3Auth was conducted on Treasure.chess.com and Skyweaver.net.

Particle Network (Distributed Custodial EOA Wallet)

Particle Network is another wallet service featuring email or social login, using a 2/2 MPC-TSS algorithm. There are two parties in the key generation process, the client and the official, who jointly compute the public key, each holding a segment of the private key. Only the client can initiate the signing process.

During signing, the proof generated by TSS technology is uploaded to the chain without exposing the private key. When the client switches devices or recovers the account, after verification via email OTP or social login, the client key stored in the cloud is called.

Figure 6: Particle Network (MPC-TSS, Social Login)

The TSS multi-signature algorithm is more secure than SSS because it does not expose the complete private key throughout the process. However, in a 2/2 TSS scheme, losing any one of the key fragments makes recovery impossible, which increases the risk of permanent account lockout.

Currently, Particle Network allows users to download the keys stored in the cloud, making it easy to achieve social login on new devices. However, the key is not password protected, and the service provider has full access to the account.

Figure 7: Our Evaluation of Particle Network

Gas Fees: Low, not a smart contract wallet.

Latency: Low, 2/2 MPC is very efficient.

Device Replacement: Simple, email OTP or social login

Security: Medium, complete private key does not exist, nor is there permanent exposure. Social login verification is still centralized.

Non-Custodial: Low. The server can pause services or censor transactions.

Functionality: Low. Not a smart contract wallet

Our testing of the Particle Network wallet was conducted at https://wallet.particle.network.

Sequence (Distributed Custodial Smart Contract Wallet)

Sequence is a multi-signature smart contract wallet that delegates one of the three keys to Web3Auth while supporting email or social login. It allows developers to manage account security more flexibly. Additionally, as a smart contract wallet, Sequence supports setting additional logic in different use cases to improve user experience. Some games and Web3 applications have already adopted Sequence.

The Sequence wallet currently uses three private keys to ensure security, which are sufficient to create a majority weight to fully control the account: a session key, a guardian key, and a Torus key.

• The session key is stored in the browser's IndexedDB.

• The guardian key is stored on Horizon (the Sequence server).

• The Torus key (SSS) is generated by the Torus network, also known as Web3Auth. For its features, please refer to the previous section.

Figure 8: Sequence (Smart Contract, SSS)

Compared to Web3Auth, Sequence adds further decentralized custodial options for developers or clients. Currently, Sequence allows users to directly invoke the Torus key and guardian key when logging into new devices using social accounts, reducing friction and improving user experience.

Gas fees are an additional factor for smart contract wallets. Account creation, transaction signing, and key reconstruction all occur on-chain, thus consuming gas. The cost of transaction signing can be negligible, but the cost of creating accounts and reconstructing keys on Polygon is $0.005-0.01, while on Ethereum, the cost is about 1000 times that.

Figure 9: Our Evaluation of Sequence

Gas Fees: Low-Medium

On Ethereum: 270k gwei is about $5-12 (Gas price at 15-30 gwei, ETH at $1500) for account creation.

On Polygon: $0.0068-0.015 (Gas price 47 gwei, MATIC at $0.9) for account creation.

Latency: Medium, first login usually takes 15 seconds, social login takes 10 - 20 seconds.

Device Replacement: Simple. Social login

Security: Low. Single point of failure. In the current implementation, only the Torus key is sufficient for login.

Non-Custodial: Low. In the current implementation, only the Torus key is sufficient for login.

Functionality: High. Sequence is a smart contract wallet, thus supporting additional account management logic.

UniPass (Distributed Passive Custodial Smart Contract Wallet)

UniPass is also a smart contract wallet built on MPC key management. It inherits all the excellent features of smart contracts and MPC wallets. Compared to Sequence, it uses domain key email (DKIM) to verify reset requests instead of using guardian keys and social keys. Users can simply send an email from their pre-set email account to reset the master key.

The DKIM-based reset mechanism works as follows: users send an email in a specific format, with the content of the email address hashed and signed by DomainKeys, and then broadcast the signed hash using any RPC service to invoke the reset function in the smart contract. The domain key signature of the guardian email is verified on-chain, as shown in Figure 10.

DKIM authentication can be easily completed by sending an email, and the entire process does not involve any server that requires authorization from the user, effectively eliminating centralization risks. Currently, the UniPass server simplifies the process of resetting the master key by drafting recovery emails for users and providing RPC services. However, users do not rely on the official server; the open-source frontend can run locally, completely bypassing the server in the account recovery/social recovery process.

Figure 10: UniPass DKIM Recovery

In this design, the guardian email can still be seen as playing the role of a custodian, but it is passive, as there is no specific service provider involved in the entire process, thus avoiding censorship risks. This approach significantly reduces the risk of service providers being attacked maliciously, whether internally or externally, and lowers the likelihood of custodial service providers being censored. Access to the account is protected not only by the secure environment of the email service but is also invisible to outsiders (the relationship between the email address and the account is encrypted using zk technology, and no one knows which email corresponds to your wallet).

Due to gas fees, users typically log into accounts using 2/2 TSS keys without invoking the more expensive functions of smart contracts. As shown in Figure 8, to log into a new device or environment, users first download the user key encrypted by the keystore from the cloud using email OTP and decrypt it with the keystore password. This key can then be used locally to initiate transaction signing. Once the user key (client key) signs the transaction, another key held by UniPass will automatically participate in the signing. The UniPass key acts as a gatekeeper, automatically monitoring the content of transactions to check for potential frontend attacks.

Figure 11: UniPass 2/2 MPC-TSS Login Process

UniPass also supports session keys, which are authorized to automatically sign transactions under predefined conditions, such as within a certain transaction amount, over a period of time, or adding whitelisted addresses. This is made possible by the functionality of smart contracts. Using session keys can greatly improve user experience in certain scenarios (such as gaming).

Figure 12: Our Evaluation of UniPass

Gas Fees: Low to Medium. The cost of creating an account on Polygon: 80k-130k wei is $0.0033-$0.005 (Gas price at 15-30 gwei, MATIC price at $0.9).

Latency: Medium

Device Replacement: Medium. Email OTP + password. Users cannot simply import accounts through social login.

Security: High. Hackers need to compromise two emails (the relationship between the address and the email is hidden by zk-tech) to access the client's account, which is nearly impossible.

Non-Custodial: Medium. High service availability; even if UniPass officially stops services, clients can still access their wallets; no custodial behavior detected.

Functionality: High. UniPass is a smart contract wallet, so it can implement additional account management logic.

Conclusion

As the barriers to entry for Web3 users decrease, more and more developers are beginning to realize the importance of the wallet itself and its role as a gateway for user traffic. In the past, project teams had to make trade-offs between non-mnemonic key management and self-custody; now, MPC and smart contracts have alleviated this pressure. Distributed custodial solutions, especially the passive custodial solution of UniPass, provide the most balanced user experience and security features for users and developers. In the coming 12 months, as a wave of consumer-facing Web3 applications arrives, this balanced solution may see wider adoption.

Figure 13: Our Evaluation of Leading Non-Mnemonic Wallet Solutions and Related Metrics