Original author: Pengyu, Co-founder of Particle Network
MetaMask is the most well-known wallet product in the industry. Its influence has surpassed the wallet field, giving people an almost unshakable impression. The core reason is that it has taken advantage of the first-mover advantage in the developer community and built a growth flywheel with the dApp ecosystem. This article will analyze the launch and operation of the MetaMask growth flywheel, and why it may be failing.
A brief review of the development history of MetaMask
Let’s take a brief look at the history of MetaMask:
MetaMask was created by Kumavis (also known as Aaron Davis) and several other core members. Its purpose is to simplify user interaction with dApps through browser extensions. Before 2016, interacting with Ethereum-based dApps usually required running a full Ethereum node, which was quite complicated for many users.
Contrary to what you might intuitively feel, MetaMask was positioned more as a developer tool in the initial stage, with the goal of providing developers with a friendly and easy-to-use user access interface.
Figure 1-MetaMask’s growth flywheel
From the development history, we can summarize the initial state and running state of MetaMask's growth flywheel
In the process of the rapid rise of DeFi and NFT fields, thanks to MetaMask's advantages in asset and user scale, more and more dApps choose MetaMask as the preferred solution for connecting on-chain businesses, thereby further enhancing MetaMask's asset scale and user scale.
Summarizing the development history of MetaMask, we can clearly see the initiation, launch, and operation stages of its growth flywheel:
The initial stage of the flywheel: focusing on developer-friendly features, becoming the default user access tool for early dApps.
The start-up phase of the flywheel: gaining a lead in terms of user and asset scale.
The operation stage of the flywheel: "wealth effect" in the industry - incremental users entering on-chain products (such products are mainly DeFi products, and mainly interact through web pages) - use MetaMask for connection by default - increase the user and asset scale of MetaMask - transform from a single user access tool to a complete user ecosystem - and then attract more developers to use MetaMask.
Why does it fail?
I think MetaMask’s growth flywheel is failing for several reasons:
1. Not becoming an “entrance” makes the growth flywheel run more stably
In the entire traffic path, MetaMask is not the core driving force for the entry of incremental users, but only one of the places for new users to enter Web3 driven by the wealth effect. In terms of traffic interaction, MetaMask is reflected as a one-way absorption without distribution and feedback. Another feature is that the proportion of users who use MetaMask as the starting point for active needs other than transfers is very small.
I think the entrance should be the starting point for active demand collection and distribution, not just the receiving place of traffic. For example, Google is an entrance, but Lu.ma, an activity management platform often used by Web3 people, is not an entrance. In fact, MetaMask hopes that Snaps can take on the task from receiving traffic to distributing traffic.
2. The core business scenarios on the chain are migrating: non-DeFi category pan-user application layer projects are rising rapidly
The migration of core business scenarios will change the underlying driving force of incremental users in the industry. In the past, the underlying driving force of almost all new on-chain users came from the wealth effect of top assets Bitcoin and Ethereum. However, with the rise of application projects, this driving force will shift to a dual drive of the wealth effect of top assets and Web3 native content. Therefore, the entry path for incremental users has changed significantly.
In the business scenarios of pan-user application layer projects, the characteristics of user-chain interaction are: cross-platform, low value, high frequency, which is different from the web-side interaction of Defi products, high value, medium-low frequency. The standard configuration of pan-user application layer projects will be mobile-first, using a cross-platform product matrix.
On the mobile side, using MetaMask as a tool for users to access business scenarios will bring about a clear sense of experience segmentation. Specifically reflected in the product data, the registration conversion rate of new users is very low, and the completion rate of calling MetaMask for signing in mobile business scenarios is also very low. In this case, the damage to developers’ end-user experience will be significantly amplified, and MetaMask’s asset scale and user scale advantages can no longer make up for it.
3. Wandering in the realm of account abstraction
The business scenarios of some application layer projects have entered a more complex stage of intelligent interaction by leveraging the power of account abstraction. However, MetaMask does not reinforce the business scenarios of application layer projects in these scenarios, but only plays the role of a Signer.
The essence of account abstraction is to generalize account types, and the ultimate goal is to eliminate EOA accounts. However, as a leader in the EOA account system, MetaMask has some conflicts with the essential goal of account abstraction, resulting in its business layout in the field of account abstraction not being aggressive enough.
4. Misalignment between iteration and product essence: As a Web3 on-chain product with the largest number of C-end users, the product idea is developer-first.
The overall idea of MetaMask is to prioritize developers, which is a good strategy in the early days of the industry because basically all users are developers and developers are all users.
This was not a problem during the DeFi boom, but with the rapid rise of general-user application layer projects, the crypto industry is transforming from a crypto-punk-friendly industry to a mass consumer industry, and the developer-first approach will become out of touch with end users.
Figure 2- Migration of core business scenarios on the chain
Based on the two core reasons for the failure of the growth flywheel, what changes may occur in the "entry" pattern?
1. MetaMask has not yet become an entry point, and has lost the flywheel effect of mutually enhancing asset scale and user scale with dApp on the mobile side
Does this mean there will be more opportunities for retail wallets?
This will bring the competition back to between products, but it does not make it easier for other retail wallets to become an entry point.
On mobile, the pressure on other retail wallets will be reduced. Unlike the web era, other retail wallets no longer compete with the ecosystem built by MetaMask, Defi products, and web-first dApps, but more like competing with an independent wallet product called MetaMask that has a certain degree of popularity on mobile. The competition between retail wallets has changed from the competition between independent products and ecosystems in the web era to the competition between independent products in the mobile era.
However, this does not mean that other retail wallets have increased their chances of becoming an “entrance”. As we analyzed before, retail wallet products need to simultaneously undertake traffic and active distribution needs to become an entrance. On the mobile side, this challenge has not been alleviated for other retail wallets. At the same time, although MetaMask does not have a unique growth strategy on the mobile side, this only brings everyone back to the same competitive dimension, and MetaMask still has a clear first-mover advantage.
Even on this basis, more opportunities belong to only some retail wallets, who may have the following characteristics:
A mobile-first retail wallet that has unique insights into and is able to meet the native needs of end users in mobile scenarios.
A mobile retail wallet that can operate with a positive economic model throughout the user life cycle. As an independent wallet product, it can achieve a commercial closed loop within the product. For example, the wallet is combined with on-chain contract transactions, which may achieve a commercial closed loop within a certain user scale. It can positively enhance the monetization capabilities of the entire ecosystem. This type of ecosystem is currently mainly concentrated on exchange products that can generate high LTV through strong operations, including leading decentralized exchanges and centralized exchanges. For example: Uniswap's mobile wallet, OKX's OKX Wallet, etc.
Going beyond the UI perspective of the wallet and involving the underlying optimization opportunities of every on-chain transaction, such products may not currently be classified in the wallet field, such as companies engaged in Mempool optimization, MEV, or authorization management.
2. The migration of core business scenarios on the chain is a more important reason for the failure of MetaMask’s growth flywheel
Next we will discuss what changes this factor will bring to the import structure.
The most lasting impact of the migration of core business scenarios on the chain on the entry structure is not only the failure of MetaMask's growth flywheel, but more importantly, the change in the main driving force for new users on the chain.
Before the rise of application layer projects, the main driving force for new users on the chain was the wealth effect of top assets. But with the rise of application projects, this driving force has shifted to the dual drive of the wealth effect of top assets and Web3 native content.
Therefore, in order to more clearly understand the possible changes in the entry pattern, we should pay more attention to how the pan-user application layer project will handle the interaction between new users and the chain, including: public key generation, private key management, initiating signatures, completing signatures, and feedback after signing.
The pan-user application layer project has three options for handling new user and link interactions:
1. Access to high-market-share retail wallets such as MetaMask/Coinbase Wallet.
2. Build your own wallet.
3. Access WaaS (Wallet as a Service).
There are four specific solutions for building your own wallet:
1. Self-built custodial applications with built-in wallets.
2. Self-built mnemonics and non-custodial application with built-in wallet.
3. Self-built social login class and built-in wallet for non-custodial applications.
4. Build your own independent retail wallet.
Based on the two dimensions of user experience (registration conversion rate of new users, efficiency of completing signatures within dApp) and asset responsibility, combined with the business interaction characteristics of pan-user application layer projects: pan-user, cross-platform, low value, high frequency, the following comparison chart can be made:
The first option: Connect to retail wallets with high market share such as MetaMask/Coinbase Wallet.
Driven by the wealth effect and Web3 native content, this solution is not feasible. Imagine that new users are attracted by the content and gameplay and download a mobile client of a Web3 game, and then the first thing they do is to go to the app store to download a second app (Coinbase Wallet or MetaMask mobile).
The second option: build your own wallet.
Building your own independent retail wallet is a relatively poor option because compared to accessing retail wallets with a high market share (such as MetaMask/Coinbase Wallet), it neither solves the problem of experience fragmentation nor increases the responsibility of user assets.
The benefit of building your own mnemonic wallet is that you don’t have to download a mobile app, but the problem of low new user registration conversion rate caused by the mnemonic itself has not been solved. Generally speaking, for general users (who don’t have much experience in using Web3 products and services), the mnemonic link (understanding and memorizing) will cause more than 60% of users to leave.
Self-built custodial applications with built-in wallets are a relatively feasible solution in the short term and can solve the user experience problem. However, the drawback is that the on-chain behavior of independent users cannot be tracked. In addition, as the business grows, the asset responsibility of application layer projects continues to increase.
Building your own non-custodial application with built-in wallet that supports social login is the relatively optimal solution, but for most project parties, considering the cost of self-construction and operation and maintenance, this solution is not cost-effective.
The third option: access WaaS (Wallet as a Service).
The essential services provided by wallet-as-a-service products include two aspects: one is to provide a social login solution for the dApp it serves to significantly increase the registration conversion rate of new users; the other is to generate a built-in full-function wallet in the corresponding dApp, so that business-related on-chain signatures can be completed within the dApp without jumping out.
There are essential differences from the SDK of retail wallets: first, the entry process must be non-mnemonic, otherwise it conflicts with the need to solve the conversion of new user registration through social login; second, there is no independent wallet product as a necessary condition for signature. In addition, wallet-as-a-service products are also different from retail wallets in terms of business model and product iteration path.
Figure 3-Wallet as a Service Product (Enter - Sign in the App - Full Operation on the Chain)
This approach can solve the problems of asset responsibility and user experience, but the risk is that it will rely on the operation and maintenance capabilities of the wallet-as-a-service company to a certain extent. However, I think the core risk lies not in the business itself, but in how to make the right choice among partners.
Considering the cost and efficiency, in the industry landscape where pan-user application layer projects are rising, the standard configuration for handling the interaction between new users and the chain will be WaaS (Wallet as a Service). Therefore, after the core scenario migration, a large proportion of new users can directly interact on the chain through application layer projects combined with WaaS, and after completing a large number of business scenarios, they will be diverted to other application layer projects or independent retail wallets.
Based on this idea, we can outline the possible development trend of the "entry" pattern.
Figure 4: Flow path under dual driving force
Who is the new entrance?
Under this development trend, have pan-user application layer projects become a new entry point?
Let’s go back to the definition of the entrance: the entrance is the starting point for active demand collection and distribution, not just a place to receive traffic.
Under this trend, general-user application layer projects have actually replaced MetaMask's role in receiving traffic, and their advantage over MetaMask is that they are also one of the underlying driving forces for incremental users to enter the industry.
However, even a single application layer project that has the potential to drive incremental users into the industry will not directly become an entry point because there are still two problems that need to be solved:
1. Head effect;
2. Redistribution capability.
In the traffic path diagram under this dual driving force, it can be seen that the head effect determines the scale of undertaking pan-user application layer projects, while the redistribution capability determines whether it is possible to form a benign two-way interaction with the traffic based on the undertaking location.
The judgment of the head effect seems to have a path but is actually highly uncertain. Only one type of product is widely recognized: Web2 super applications that continue to invest in Web3 business and have clear goals. For example, Telegram. Will Web3 native head pan-application products with the ability to drive incremental users occur in the re-evolution of centralized exchanges, or on Web3 social communication protocols or game platforms?
The ability to redistribute is one of the essential characteristics of an “entry”. However, in the Web3 industry, I think the meaning of the ability to redistribute is broader, not just the distribution of traffic, but also the distribution of capabilities and the distribution of consensus. The distribution of traffic is very intuitive, it means actively guiding the attention of the majority of end users to upstream and downstream products. The distribution of capabilities includes the ability to operate on-chain assets and the ability to operate user communities. The distribution of narratives and consensus is essentially the distribution to top users.
The head effect and redistribution capabilities determine whether a sustainable "entrance" can be formed.
In addition, we cannot ignore two roles:
1. Centralized exchanges: The leading centralized exchanges will continue to participate in the process of reallocating traffic to on-chain businesses. Mobile retail wallets, WaaS wallets as a service, and on-chain contract trading businesses will become standard features of leading exchanges.
2. New products that belong only to Web3: Unlike the data closure and user rights restrictions of Web2, the transactions and authorizations of Web3 are completely controlled by the end users. When application layer projects emerge, the authorization and signatures of end users may require a platform for unified management, which involves authorization and signatures in different business scenarios. End users may have new entry opportunities in terms of on-chain assets, authorization, and transaction status management.
In general, MetaMask's growth flywheel may be failing. The core reason is the rise of pan-user application layer projects, which has caused the core business scenarios on the chain to migrate from web page interaction to mobile-first cross-platform interaction. The Web3 industry is transforming from a crypto-punk-friendly financial industry to a mass-friendly consumer industry. In this process, pan-user application layer projects with head effects and redistribution capabilities have become the core driving force. The Web3 entrance we envision is likely not produced through planning, but a reward for the role that contributes the most in this process.