MetaMask can only solve "shallow level" compatibility.
Written by: Haotian
Last night @MetaMask launched the MetaMask Snaps version, which allows non-EVM wallets such as Solana, Sui, Aptos, Cosmos, Starknet and other ecological wallets to integrate and access. Currently, 34 Snaps are open for internal testing.
In my opinion, this is a very smart ecological integration move by MetaMask, which once again consolidates its leading position as a plug-in wallet. What are the potential impacts of MetaMask Snaps? What impact does it have on ordinary users? Next, a brief analysis.
In fact, this is a function that the majority of users have been looking forward to for a long time. Since MetaMask only supports EVM chain access through RPC, for a long time, users have to download a bunch of corresponding wallets to interact with other ecosystems, such as: Using Solflare, Phantom to connect Enter the Solana ecosystem, use Keplr and Cosmostation to connect to the Cosmos ecosystem, use Argent and Braavos to connect to the Starknet ecosystem, and the Sui and Aptos ecosystems also have independent wallets.
A senior user will have to download more than ten wallets to play on every public chain. Not only will the user experience be poor, but it will also indirectly increase many security risks. If MetaMask can integrate these wallets, users only need one entrance from Metamask, wouldn’t it be great!
The ideal is wonderful, but MetaMask does not want to think about it. It is technically difficult to be compatible with these wallets at the same time.
To put it simply: MetaMask is created based on the Ethereum ecosystem, so its account system, private key management, transaction signatures, etc. all follow the Ethereum node interface specifications, even if it is compatible with some EVM chains, such as: BNB Chain, Avalanche, zkSync, etc. Access through different RPCs. Just these EVM chains will also have some adaptation problems. The gas fee estimation error during zkSync interaction mentioned earlier is caused by the incompatibility between zkSync's Gas estimator and MetaMask. (MetaMask's estimated Gas is higher than the actual zkSync charge), which will cause considerable user experience problems.
If MetaMask is to be compatible with the non-EVM chains mentioned above, it is easy to imagine how much development work will be required to fully adapt to the account system, address format, transaction structure, data logic, etc. Now MetaMask has cleverly developed a set of Snaps API access specifications, allowing third-party public chain wallets to break through technical difficulties to access it on their own. MetaMask is only responsible for the audit work of access, and developers will handle other dirty work by themselves.
This problem is easily solved: on the one hand, all public chain wallets covet MetaMask's leading entrance position, hoping to be able to access MetaMask; on the other hand, MetaMask can also bring back users who have been diverted by these non-EVM chains; killing two birds with one stone, cooperation is a win-win situation. . Of course, the impact on MetaMask must be greater. This can be regarded as a powerful resource absorption effect of its brand influence. In the foreseeable future, MetaMask will become a super wallet entrance, dominate wallet traffic, distribute DApp traffic, and become an operational business There is a lot of room for imagination.
Based on this cognitive premise, I personally believe that MetaMask can only solve "shallow level" compatibility:
1) The name of Snaps is very intriguing. Snaps? It shows that Snaps emphasizes fast connection and packaging, and the native chain functions that it can carry are likely to be limited, making it difficult to achieve 100% reproduction;
2) The interaction between some basic asset management and key ecological applications is okay, but it is difficult to adapt to complex functions such as native wallet pledge, delegation, multi-signature, Mint, and Burn;
3) MetaMask Snaps are basically provided by the wallet parties of each chain, so there is no such thing as MetaMask grabbing users. In essence, MetaMask is just a front-end display entrance. If used well, it can also divert traffic to various ecological wallet parties;
4) Although MetaMask has conducted an audit and invited a third-party audit company to participate, it does not rule out that there will be security risks in the future. After all, these developers want to quickly embrace the big boss’s lap. How well they have done their technical homework remains to be seen. test of time;
5) During the unlicensed public beta stage, some phishing external links will come rampant. It is recommended to create a new wallet on the new Snaps and import old wallet assets with caution.
6) Snaps only run in the Sandbox environment. Snaps do not have access to MetaMask account information. This isolation is very good and is decoupled from the native wallet to avoid security threats to the original MetaMask assets.
By the way, a few Q&A to popularize science:
1) Can the original private key be directly imported into MetaMask Snaps? Answer: Theoretically, it is possible, and the original private key management system of each wallet will be completely used;
2) Will the wallet experience that was previously bad improve after being connected to MetaMask Snaps? Answer: No, it might even be worse;
3) Will the original HD hierarchical deterministic wallet mechanism of MetaMask still work (one seed phrase manages multiple addresses)? Answer: No, non-EVM chain accounts and private keys rely on their native wallet management. Private key derivation and address generation algorithms have nothing to do with MetaMask. Remember to back up your private keys separately;
…
Note: There may be discrepancies between the above statement and the actual situation. It is only based on reasonable speculation. Developer friends who have actually participated in the development of MetaMask Snaps can leave a message to add more details. More interesting discoveries need to be further observed.
