A&T View: Low-threshold Wallet - A Necessary Tool for Mass Adoption of Web3 Applications

Author: Billy, AnT Capital

Abstract

TL; DR:

• The user experience and security of existing mnemonic wallets fall far short of Web2 standards, and the high barrier to entry for using mnemonic wallets prevents a large number of Web2 users from entering the Web3 world. The mission of low-threshold wallets is to solve this problem.

• The core paradigm of low-threshold wallets is the 2/2 operational model, which allows wallets to incorporate mature Web2 2FA, risk control, and backup systems, achieving user experience and security levels comparable to Web2, even though some solutions partially sacrifice censorship resistance.

• Low-threshold EOA wallets and low-threshold smart wallets each have their advantages and disadvantages, and both have opportunities in the long term.

• The low-threshold wallet sector is still in its early stages on both the supply and demand sides, with an uncertain competitive landscape, remaining a blue ocean.

• At this stage, the core competitiveness of low-threshold wallets lies in product capability and BD capability.

• Low-threshold wallets are likely to become the user entry point for Web3 and have the potential to grow into super Dapps.

Preface

The term "wallet" does not accurately convey its connotation: managing assets like a real-world wallet is just one of its functions. A wallet is essentially a tool for human users to interact with the blockchain; from sending transactions to DAO voting, users' on-chain operations almost always must be executed through a wallet.

Unfortunately, the mainstream wallet in today's Web3—mnemonic EOA wallets (represented by Metamask)—is extremely user-unfriendly, and this barrier blocks many Web2 users from entering. For a Web2 novice, when they first enter Web3 using a Metamask wallet, a long string of mnemonic phrases and the friendly reminder "never share your mnemonic phrase with others" will greet them. The user recalls various wallet private key theft incidents they have heard about, prompting them to quickly jot down the mnemonic on a piece of paper and hide it in their drawer. Soon after, they realize they have no ETH, meaning they cannot perform any operations.

Thus, they have to click on Metamask's fiat deposit feature, fill in various bank card details, and obtain the corresponding ETH. At this point, they can finally start playing their on-chain cat game, all while remaining vigilant about whether their environment is safe and whether their mnemonic has been leaked. Of course, the above is a very idealized scenario; the reality is more likely that 80% of users abandon account registration upon seeing the mnemonic, and among the remaining 20%, 80% leave Web3 before making a deposit.

For a product to achieve mass adoption, it must lower its user threshold. Fifty years ago, computers faced a similar (though more extreme) problem as today’s Web3. The situation in Web3 is that the interaction tool (wallet) between human users and the blockchain has a high barrier to entry, while early computers had a high barrier to entry for the interface between human users and computers: early computers only supported command-line interfaces.

This made it impossible for computers to be widely adopted by the public; they could only become toys for geeks. It wasn't until the 1970s when Xerox developed the first graphical user interface, which was popularized by Apple, that the public gradually began to accept and use computers, eventually becoming an indispensable item for modern humanity.

Users could only interact with computers via command line when graphical interfaces emerged.

Apple was the first to promote graphical interfaces, bringing computers into the public realm.

Similarly, in Web3, only when the operational threshold for users interacting with the blockchain is lowered to a level that offers a product experience similar to Web2 can Web3 products be widely adopted; otherwise, we will see a situation where the number of investors > the number of project parties > the number of users. Therefore, to gain public acceptance for Web3, the wallet threshold must be lowered, and this is the mission of low-threshold wallets.

Low-threshold wallets have many features, such as 1) eliminating mnemonic phrases, 2) allowing users to log in using familiar Web2 methods like email and Google accounts, 3) supporting free usage for users (gas fees covered), and 4) being embedded into Dapps, etc. These features will help users interact with the blockchain seamlessly, laying the foundation for the explosion of Dapps.

Paradigm Shift of Low-Threshold Wallets: Web2-Level Security and User Experience

Low-threshold wallets and ordinary mnemonic wallets represent two completely different paradigms.

The operational model of mnemonic wallets is that whoever possesses the private key (mnemonic) has complete ownership and management rights over the account's assets. Compared to Web2, which has two-factor authentication and password recovery, this operational model greatly undermines the security of user assets: whether the private key is stolen or lost, users will lose all their assets; it also significantly damages the user experience: users must expend considerable effort to prevent the mnemonic from being stolen/lost, such as having to write the mnemonic on paper and hide it away. Of course, the benefits are also clear: users have asset sovereignty and do not have to worry about centralized entities acting maliciously or censoring.

Low-threshold wallets utilize a brand-new 2/2 operational model that elevates their security and user experience to a Web2 level, even though some solutions sacrifice a degree of censorship resistance. Nevertheless, Web2-level security and user experience pave the way for the mass adoption of Web3 applications.

Core of Low-Threshold Wallets: 2/2 Operational Model

In simple terms, the 2/2 operational model means that all user operations must be approved by two designated parties before proceeding. The simplest implementation is to use a multi-signature wallet, stipulating that every operation of the wallet must be signed by two private keys to execute. If we assign the two parties as the user side and the wallet project side (in the specific implementation of the multi-signature wallet, one private key is stored on the user's mobile device, while the other is stored on the wallet project's server), this means that if the wallet project side does not agree, an operation cannot be completed. On this basis, the wallet project side can use mature Web2 2FA (two-factor authentication) and risk control technologies to elevate the wallet's security to Web2 levels.

2FA (Two-Factor Authentication): In Web2, when a user logs into an account on a new device, Web2 applications typically require additional verification, such as email verification, SMS verification, device verification, or facial recognition verification. The security assumption here is that hackers cannot simultaneously compromise two different authentication factors of a user. In fact, this is why Web2 user accounts are far more secure than mnemonic wallet accounts.

Now, the wallet project side's server can help users perform the same two-factor authentication as Web2 applications—only after the user passes the verification will the wallet project allow the user to operate on a new device. This ensures that even if the user's private key is stolen, the user's assets can still be protected because the hacker does not possess the user's email, phone, or facial recognition as the second authentication factor.

Risk Control: In Web2, robust risk control systems can prevent a significant portion of asset theft and fraud. For example, the risk control system AlphaRisk behind China's top payment company Alipay conducts multi-dimensional risk assessments on every transaction. The system is backed by nearly 500 quantitative strategies and 100 risk models to accurately identify abnormal behaviors in user accounts.

Now, the wallet project side's server can run a Web3-specific risk control system for users, providing alerts and multiple verifications for users about to engage in suspicious transactions, significantly reducing the risk of users being scammed, phished, or having their assets stolen in the "dark forest" of Web3.

Once the user's security is elevated to Web2 levels, they can easily back up their private keys to their own cloud storage, such as Google Drive or iCloud, thereby reducing the risk of losing their private keys and allowing users to avoid memorizing/writing down mnemonic phrases, significantly lowering the barrier to entry. At this point, the reason users can directly back up private keys and mnemonics, while ordinary wallets cannot, is that the security of low-threshold wallets has already been elevated to Web2 levels; even if the user's private key is lost, their assets will not be at risk.

If readers find this somewhat counterintuitive, here is a completely analogous example: in Web2 applications, the reason we can set such simple and patterned 8-digit passwords (which are far easier to crack than completely random 64-bit hexadecimal Ethereum private keys) is fundamentally because we have Web2's 2FA and risk control to ensure the security of our accounts.

In addition to not requiring mnemonic phrases, the 2/2 operational model also allows wallets to be embedded into Dapps, enabling users to perform Dapp operations without switching wallet applications, thus greatly enhancing user experience. Why can't mnemonic wallets support in-app embedding? Because embedding means the wallet provides its own SDK to the application project (otherwise, how would the application help the user sign and directly purchase items when the user clicks "buy"?), at which point the application would have complete control over the user's private key.

In the 2/2 operational model, if the wallet project side's risk control system detects a suspicious transaction, such as suspecting that the application is stealing user assets, the wallet project side can require the user to undergo secondary verification, such as sending an email verification code to confirm that this operation is initiated by the user. However, in the operational model of mnemonic wallets, no one can prevent the application from stealing the user's assets.

So far, low-threshold wallets based on the 2/2 operational model have elevated wallet security and user experience to Web2 levels. The final user flow is, just like in familiar Web2, to log in using Google/phone number/email right from the start, and then proceed to use it directly. When users need to back up their private keys, they simply click "backup," and the user's private key will be automatically backed up to the cloud. However, we have always made one assumption: that centralized wallet project sides are diligently providing their services. Now it's time to consider the possibility of centralized wallet project sides acting maliciously.

The first question is, can the wallet project side steal users' funds like a custodial wallet?

The answer is no. The 2/2 operational model of low-threshold wallets stipulates that every operation must simultaneously obtain consent from both the user side and the wallet side to proceed. As long as the user does not cooperate, the wallet project side cannot unilaterally transfer the user's assets.

The second question is, can the wallet project side freeze user assets?

The answer is, if the wallet's functionality stops here, then yes. The 2/2 operational model of low-threshold wallets stipulates that every operation must simultaneously obtain consent from both the user side and the wallet side to proceed; as long as the wallet project side does not cooperate, the user will never be able to perform any operations. This sounds like a serious issue, but I believe it is acceptable for Web2 novices because the wallet project side has little economic incentive to freeze users' accounts; if they do freeze, it is more likely due to censorship.

For the general Web2 public, being subject to censorship is not an unacceptable point; user experience and security are what they care about more. Nevertheless, the wallet project side having the power to freeze user assets remains very dangerous. Some project parties choose to patch this issue based on the 2/2 operational model. Among them, low-threshold smart wallet projects have on-chain social recovery, while low-threshold EOA wallets also have some solutions, which I will introduce in more detail below.

Implementation Methods of the 2/2 Operational Model

The 2/2 operational model is independent of the type of wallet; whether it is a smart wallet or an EOA wallet, the above 2/2 operational model can be used to transform into a low-threshold wallet, differing only in characteristics.

There are two main methods for EOA wallets to implement the 2/2 operational model: Shamir's Secret Sharing and MPC.

Shamir's Secret Sharing scheme, in simple terms, divides the original EOA private key into two pieces and distributes them to two parties. When needed, both parties send their respective private key shares to the same device and aggregate them into the original complete private key, which is then used to sign. However, the Shamir's Secret Sharing scheme has a step of private key aggregation; if the device performing the aggregation is hacked, the complete private key can be directly stolen, thus increasing security risks.

MPC (Multi-Party Computation) technology solves this problem: the two parties in the 2/2 operational model generate private key shares directly on their respective devices and cooperate to generate signatures during operations, rather than first aggregating into a complete private key and then signing. This means that if the mobile device we are using for wallet operations is hacked, using the Shamir's Secret Sharing scheme would result in asset theft, while using the MPC scheme would not lead to security incidents.

Compared to EOA wallets, smart contract wallets have an additional option, which is multi-signature. The security of the multi-signature scheme is similar to that of the MPC scheme, but due to more complex on-chain logic, its gas fee consumption will be higher than that of the MPC scheme.

Low-Threshold Smart Wallet vs. Low-Threshold EOA Wallet

The difference between smart wallets and EOA wallets is that the former is a smart contract, allowing for the implementation of arbitrary logic. Supporters of smart wallets or account abstraction will mention many of its new features, such as Multicall, Session keys, etc., but I believe the most important aspect is that smart wallets have full on-chain social recovery functionality, while many other features can be satisfied by the 2/2 operational model.

In other words, as long as users bind several friends/family members on-chain, when the wallet project side wants to freeze user assets, as long as the accounts of the user's friends/family members are still usable, they can help the user recover their account on-chain, ultimately allowing the user to regain control over their account. This is how low-threshold smart wallets address the issue of wallet project sides having the authority to freeze user accounts. If EOA wallets want to prevent user accounts from being frozen, there are some solutions, but the overall difficulty is significantly higher.

However, smart wallets also have several disadvantages compared to EOA wallets:

1) Difficult to support multi-chain: Contract wallets are bound to the contract and public chain systems, meaning that when deploying smart wallets on a structurally different chain, the account logic needs to be redeveloped, which is costly. Moreover, the generated accounts are completely non-interoperable due to structural differences. In fact, almost all smart wallets currently only support EVM chains.

2) Higher gas fees: The logic of smart wallets is more complex than that of EOA wallets, so each operation incurs higher gas fees. Additionally, creating a smart wallet also requires a significant gas fee.

3) Not widely promoted yet: Currently, all applications accept EOA account systems, but not necessarily contract account systems.

I believe that issues 2) and 3) will be resolved in the long term, while 1) is indeed a hard flaw of smart wallets.

In the long run, I believe both technical routes have opportunities. It is important to specifically point out that we need to stop mythologizing smart wallets and account abstraction. As we can see from the above, the core of low-threshold wallets is the 2/2 operational model; whether it is a smart wallet or an EOA wallet is merely a method of implementation, and smart wallets/account abstraction do not inherently represent low thresholds.

Competitive Landscape

The Sector is in its Early Stages, Core Competitiveness Lies in Product Capability and BD Capability

The low-threshold sector is still in its early stages. This early stage can be divided into two dimensions: 1) the supply side is in its early stages, and 2) the demand side is in its early stages.

The supply side being in its early stages means that the product design of low-threshold wallets has not yet stabilized; everyone is still making trade-offs in user experience, security, and censorship resistance, while continuously exploring new features. An example is Web3auth, which has been established for two years and has received significant investment from major capital like Sequoia, recently abandoning its previously inefficient 5/9 consensus model in favor of the more advanced MPC model, which fully demonstrates that the supply side in this field is still in an unstable, rapidly iterating state.

The demand side being in its early stages refers to the customer base of low-threshold wallets, which consists of a large number of Web2 novices who will be brought into the Web3 world when Web3 applications explode on a large scale in the future. Currently, the users of wallets are investors and builders coming in to make money and learn, which is completely different from the user profile of "Web2 novices" who come for user experience. Therefore, the market is still in its early stages, and the Web2 novice users that low-threshold wallets hope to capture have yet to appear.

In a situation where the supply side is still in its early stages and products have not yet stabilized, a project's product capability becomes crucial, as this is also a point where projects can easily differentiate themselves, making product capability one of the core competitive advantages. The second core competitive advantage is the project's BD capability: first, we assume that these Web2 novice users are brought in by Web3 applications, so the choice of which wallet to use to enter the Web3 world almost entirely depends on the first Dapp they encounter and what wallet it has embedded.

This means that the choice of low-threshold wallets involves a principal-agent problem; Web3 applications choose wallets for Web2 novice users, and the choice is in the hands of the application rather than the user, transforming low-threshold wallets from a B2C business into a B2B business. Therefore, projects with stronger BD capabilities, combined with their excellent products, will be able to gain more adoption from applications, thereby increasing the likelihood of being integrated into future popular Web3 applications and ultimately capturing the most Web2 novice users.

Overview of Some Existing Projects

Because this sector is in its early stages and the competitive landscape is uncertain, I will simply list the characteristics of some well-developed low-threshold wallet projects on the market without making detailed comparisons.

Web3auth:

Web3auth is a mature low-threshold wallet company that recently raised $13 million in a round led by Sequoia India, USV, Multicoin, FTX, and other major institutions, giving Web3auth a good BD advantage. Its current flagship product, Torus, uses a 5/9 consensus to help users save private keys, thus eliminating the need for mnemonics; however, the complex consensus requires users to wait 30-45 seconds to log in, severely damaging the user experience. Therefore, Web3auth is currently developing a low-threshold EOA wallet based on the MPC 2/2 operational model, expected to launch by the end of the year.

It is worth mentioning that due to Web3auth's longer history, it has already been integrated into many major Dapp projects, such as Opensea, AAVE, and ENS. However, as mentioned above, the low-threshold wallet market is still in its early stages, and the user base of "Web2 novices" will not care about what existing large Dapps this wallet is integrated with (if necessary, they can also use WalletConnect), so the "network effect" barrier of Web3auth's extensive integration with existing projects is not its core competitive advantage.

ZenGo:

ZenGo is a mature low-threshold wallet company that recently raised $20 million, with investors including Insight Partners and Samsung. The backing from Samsung has given ZenGo a significant channel advantage with Samsung phones. ZenGo's product is essentially a standard low-threshold EOA wallet based on the MPC 2/2 operational model, and its solution to the issue of wallet project sides having the ability to freeze user assets is to introduce a third-party institution to encrypt and back up an additional private key share to that third party.

Coinbase Wallet:

Coinbase Wallet is the low-threshold wallet launched by Coinbase, also based on the MPC 2/2 operational model. It is noteworthy that Coinbase Wallet primarily focuses on B2C wallets, rather than Dapp integration like other low-threshold wallets. However, based on the author's assumption that a large number of Web2 novice users will be captured by applications, focusing solely on B2C may not be a good direction.

I believe the launch of Coinbase Wallet is more defensive: it can increase user stickiness for Coinbase; rather than being offensive: capturing a large number of users during the explosion of Web3 applications. Nevertheless, Coinbase's strong BD resources and trust backing give Coinbase Wallet a significant advantage in the B2C low-threshold wallet sector.

UniPass:

UniPass is an emerging low-threshold wallet company that recently raised several million dollars. UniPass's product is a low-threshold wallet based on the MPC 2/2 operational model for smart wallets. Because UniPass is a smart wallet, it can effectively address the issue of wallet project sides having the ability to freeze user assets: UniPass innovatively allows users to bind the emails of relatives and friends on-chain, so if extreme situations occur and the wallet project side freezes the user's assets, the user can calmly use the email of relatives and friends to reset the account, thereby regaining control over their assets.

At the same time, to protect users' privacy and security, UniPass uses ZKP technology to hide the binding relationship between accounts and emails, preventing hackers and governments from linking users to specific emails, thus avoiding theft or censorship of the corresponding emails.

Argent:

Argent is a mature smart wallet company that recently raised $40 million from investors including Fabric Ventures, Metaplanet, Paradigm, and Jump. I believe that Argent cannot really be classified as a low-threshold wallet; it merely fully utilizes the advantages of smart wallets to allow users to bind the on-chain accounts of relatives and friends, thus achieving mnemonic-free account recovery. However, I believe that binding the on-chain accounts of relatives and friends (rather than binding emails like UniPass) is inherently quite difficult, and Argent's goal is to create a perfect smart wallet without a strong inclination towards low-threshold features.

The Final Form of Low-Threshold Wallets: The User Entry Point for Web3, with the Potential to Grow into Super Dapps

First, Web3 applications that want to achieve mass adoption will definitely adopt low-threshold wallets. The reason is simple: mnemonic EOA wallets significantly degrade the user experience for Web2 novices, while they also greatly reduce the conversion rate for Dapps, meaning that unless users have an extremely strong need for a Dapp (e.g., making money), most users will quickly return to their Web2 comfort zone. Low-threshold wallets largely solve this problem, allowing users to interact with Dapps safely and smoothly using familiar login methods like email, phone numbers, or Google. This provides the possibility for most Web3 Dapps to compete with user-friendly Web2 apps on a large scale.

So, if in the next bull market, Web3 really experiences an explosion of applications and a large number of users enter the Web3 world through applications, low-threshold wallets will become the traffic entry point for large-scale users entering Web3, meaning that low-threshold wallets will have a large number of users: if the Web3 application layer brings 100 million users to the Web3 world, it is likely that 80 million of those users will come using low-threshold wallets.

At the same time, once Web3 Dapps occupy our lives, the interaction between users and the blockchain will likely be high-frequency, which means there are many potential extension functions for wallets, and they may even become the super APP of Web3. For example, WeChat has a large user base and high usage frequency, allowing it to embed many features such as WeChat Pay, WeChat Official Accounts, and WeChat Login, ultimately establishing a super commercial empire. Similarly, wallets have the potential to leverage their ecological niche as user entry points to build a super ecosystem.