What potential impacts will MetaMask Snaps bring?

Written by: Haotian

Last night, @MetaMask launched the MetaMask Snaps version, allowing non-EVM wallets such as Solana, Sui, Aptos, Cosmos, Starknet, and other ecosystems to integrate access. Currently, 34 Snaps are open for internal testing.

In my opinion, this is a very clever ecological integration move by MetaMask, further solidifying its leading position as a plugin wallet. What potential impacts will MetaMask Snaps bring? What effects will it have on ordinary users? Next, let's analyze briefly.

In fact, this is a feature that many users have been looking forward to for a long time. Since MetaMask only connects through RPC for EVM-supported chains, users have had to download a bunch of corresponding wallets to interact with other ecosystems for a long time. For example: using Solflare and Phantom to access the Solana ecosystem, using Keplr and Cosmos Station to access the Cosmos ecosystem, using Argent and Braavos to access the Starknet ecosystem, and Sui and Aptos ecosystems also have their own independent wallets.

A seasoned user would have to download more than ten wallets to play on each public chain, which not only results in a poor user experience but also indirectly increases security risks. If MetaMask can integrate all these wallets, users would only need one entry point with the little fox, wouldn't that be fantastic!

The ideal is beautiful, but it's not that MetaMask doesn't want to; technically, it's quite challenging to be compatible with these wallets simultaneously.

In simple terms: MetaMask is built on the Ethereum ecosystem, so its account system, private key management, transaction signing, etc., all follow the Ethereum node interface specifications. Even some chains that are compatible with EVM, such as BNB Chain, Avalanche, and zkSync, connect through different RPCs. Just these EVM chains can present some adaptation issues; for instance, the incorrect gas fee estimation when interacting with zkSync was due to the incompatibility between zkSync's gas estimator and MetaMask. (MetaMask's gas estimation is higher than the actual charges on zkSync), which can cause significant user experience issues.

If MetaMask wants to be compatible with the aforementioned non-EVM chains, the development workload behind fully adapting the account system, address formats, transaction structures, data logic, etc., is considerable. Now, MetaMask has cleverly created a set of Snaps API access specifications, allowing third-party public chain wallet providers to overcome technical difficulties for integration, while MetaMask only handles the auditing of the integration, leaving the other dirty work to the developers.

This way, the problem is easily solved: on one hand, various public chain wallets covet MetaMask's leading entry position and hope to integrate with MetaMask; on the other hand, MetaMask can also bring back users who have been diverted to these non-EVM chains; a win-win collaboration. Of course, the impact on MetaMask will be even greater, and this can be seen as a powerful resource absorption effect of its brand influence. In the foreseeable future, MetaMask is likely to become a super wallet entry point, controlling wallet traffic and distributing DApp traffic, with a vast space for operational business imagination.

Based on this understanding, I personally believe that MetaMask can only solve the "superficial" compatibility:

1) The name Snaps is intriguing; snapshots? It indicates that Snaps emphasizes quick connections and encapsulation, and the native chain functionalities it can support are likely limited, making it difficult to achieve a 100% replica;

2) Some basic asset management and key ecological application interactions can still work, but adapting complex functions like native wallet staking, delegation, multi-signature, minting, and burning is relatively challenging;

3) MetaMask Snaps are primarily provided by the wallets of each chain, so there is no issue of MetaMask stealing users; essentially, it just adds a front-end display entry for MetaMask, which can also help direct traffic to various ecological wallet providers;

4) Although MetaMask has conducted audits and invited third-party auditing firms to participate, it cannot be ruled out that there may be security risks in the future, as these developers are eager to cling to big players, and the quality of their technical work remains to be tested over time;

5) During the permissionless public testing phase, some phishing external links may run rampant, so it is recommended to create new wallets primarily on the new Snaps and be cautious when importing old wallet assets.

6) Snaps only run in a Sandbox environment, and Snaps do not have access to MetaMask account information. This isolation is good, decoupling from the native wallet and avoiding security threats to the original MetaMask assets.

Here are a few small Q&A:

1) Can the original private keys be directly imported into MetaMask Snaps? Answer: Theoretically, yes, as it fully adopts the existing private key management system of each wallet;

2) Will a previously poor-performing wallet improve when integrated with MetaMask Snaps? Answer: No, it may even get worse;

3) Will the original HD hierarchical deterministic wallet mechanism of MetaMask still work (one mnemonic managing multiple addresses)? Answer: No, non-EVM chain accounts and private keys rely on their native wallet management, and the private key derivation and address generation algorithms are unrelated to MetaMask. Remember to back up your private keys properly;

…

Note: The above statements may differ from reality and are based solely on reasonable speculation. Developers who have actually participated in the development of MetaMask Snaps can leave comments to supplement more details, and more interesting discoveries await further observation.