Confusion when invoking the wallet

Connecting the wallet is a crucial step to enter the Web3 world, and Web3 users often need to connect their wallets on some DApp websites. However, even this simple action may cause serious inconvenience to users.

Connect Wallet

Imagine this scenario: a new Web3 user (out of curiosity, they have installed many plugin wallets) visits a DApp website and wants to use their browser plugin wallet to connect to it. However, when they click the "Connect Wallet" button provided by the website and select a wallet to use for connecting to the DApp, they may find that the popped-up wallet is not the one they selected. This may cause them to feel confused and suffocated, thinking that their computer has been infected with a virus, so they have performed unexpected operations.

Blockchain wallets are an important entry point for connecting to the blockchain, and in order to occupy this entry point, various wallets have used various methods they can think of. Among them, the most headache-inducing for DApp developers and DApp users is the tampering of global variables by various wallets.

In the current browser wallet implementation logic, wallet functionality is exposed by injecting global variables into the browser (for example, the wallet of the Ethereum platform will inject its functionality onto "window.ethereum"), so that DApps can call the wallet's provided methods to interact with it.

However, because many wallets will inject themselves into the same "window.ethereum" variable, this leads to the situation where the wallet registered later will override the previously registered wallet, so that only the last registered wallet can be invoked in this way.

Sometimes, in order to use the wallet they want to use normally, DApp users have to temporarily disable other wallet plugins, or directly install only one wallet. In this way, it is contrary to the original intention of the wallet developers. Even if a new wallet is more outstanding, it is difficult to attract users who are already using other wallets.

Some friends may wonder, why must they be injected into the same variable? Suppose there are two wallets: A and B, in fact, as long as A injects itself into "window.a" and B injects itself into "window.b", to invoke which wallet, just call the corresponding methods provided by the respective objects, and the problem of wanting to invoke A but instead invoking B can be avoided. This can indeed solve the competition problem, but the problem is that, in this way, if a DApp is to support multiple wallet connections, the developer must predefine all the wallet names they want to adapt in the code, and when the user selects a certain wallet, call the relevant methods of that wallet. This makes the related code maintenance quite troublesome. Injecting all wallets into the same object uniformly can avoid this trouble.

Solution

In order to break free from the aforementioned dilemma, there are two similar standards in the community.

Ethereum's solution: EIP-6963

The Ethereum community proposed the EIP-6963 proposal in May 2023.

The basic logic is very simple, which is to abandon global variables and instead use agreed-upon events to solve the problem of wallet registration and discovery.

Specifically, after the plugin wallet is successfully loaded, it triggers the unified "eip6963:announceProvider" event to notify the DApp that a new wallet is available. The DApp then listens to this event to know which wallets are currently available.

In this way, by using a set of abstract event listening logic, the problems caused by directly using global variables are avoided, and the wallets currently available in the user environment can be automatically discovered. In this way, the dilemma is self-resolved.

Community standard: Wallet Standard

EIP-6963 is an Ethereum ecosystem standard, but not only Ethereum, other chain platforms may also have similar problems. For example, wallets on the Solana chain generally inject themselves into the "window.solana" variable, which also leads to competition.

So can the Solana ecosystem also implement this standard? Although EIP-6963 is only intended to solve the wallet discovery problem in the Ethereum ecosystem, the ideas contained in it can actually be applied to all chain platforms. So, can we go further and provide a universal standard, so that wallets and DApps of all chain platforms can enjoy the convenience provided by EIP-6963? In theory, there is no problem at all, and some developers have already done this, which is the Wallet Standard.

The core work of the Wallet Standard is to provide two functions: "registerWallet" and "getWallets", the former for wallets and the latter for DApps.

The wallet calls "registerWallet" and passes in a wallet object, which encapsulates the functionality provided by the wallet (such as the Connect method for connecting the wallet). Inside the function, it first triggers a RegisterWalletEvent event, and the parameter of the event is actually a callback function used for the DApp to call when it listens to the RegisterWalletEvent event, and this callback function actually passes the wallet object, so the DApp can get a reference to the wallet object and interact with the wallet.

DApp developers do not need to write their own code to listen for and receive the wallet object, as this part has already been built into "getWallets" by the Wallet Standard. However, "getWallets" only listens to events, and how to handle the events is still up to the developer. For example, where should the obtained wallets be placed? Some wallets may already be loaded before the DApp is loaded, while others may be loaded later, how to maintain the status of these wallets? For the above details, Wallet Standard also provides the "@wallet-standard/react" package, and developers can directly use the React Hooks provided by it to obtain the desired data, including the wallet list, the currently connected wallet, and the methods provided by the wallet.

Wallet Standard Features

In addition to obtaining the Wallet object, Wallet Standard also defines some Features formats.

In fact, wallets have some basic functions, such as connecting and listening for wallet events. Wallet Standard provides "standard:connect", "standard:events", and other features. After wallet providers implement these features, DApps can directly determine whether the wallet supports certain operations based on these values.

The "standard:*" mentioned above is its internally defined features, and in fact, their values are not particularly rigidly required, so they can be extended as desired. Different chain platforms will also have their unique features, for example, Solana directly agrees on "solana:*". Common features of the Solana platform include "solana:signTransaction", "solana:signMessage", and so on.

Current Status of Wallet Standard

Currently, there are not many projects that have implemented the Wallet Standard, and it is worth mentioning Solana and Sui.

In the Solana adapter of Ant Design Web3, support for automatic detection of Wallet Standard wallets has also been implemented. Developers basically only need to enable it through "autoAddRegisteredWallets", without the need to configure a bunch of wallet metadata, greatly improving the development and user experience.

The logic for connecting wallets on ZAN.TOP also encountered the same problem in the early days. However, now, thanks to the configuration provided by Ant Design Web3, it has easily adapted to the EIP-6963 standard. Users should have already experienced this when binding addresses at https://zan.top/personal/account?chInfo=ch_wxdyh.

Implementations in Various Blockchain Ecosystems

Currently, different blockchain platforms have different attitudes towards the Wallet Standard (or EIP-6963). Here are a few examples:

Bitcoin

So far, Bitcoin seems to have no similar standard. There is a project that has implemented the Wallet Standard, but it has not attracted much attention and has not submitted new code for a long time.

Currently, developers can only manually maintain the state or use some development packages to assist. For example, in the Bitcoin adapter implementation in Ant Design Web3, for different wallets, it will retrieve from different global variables and store them in a unified state. This is actually equivalent to the library developers taking over the tedious state maintenance work. Moreover, this only solves the wallet conflict problem, and the issue of not being able to automatically detect available wallets still exists.

Ethereum

The Ethereum platform already has the EIP-6963 standard, and most related libraries and wallets also provide support.

Solana

As mentioned above, the official implementation is provided at: https://github.com/solana-labs/wallet-standard

Sui

Sui has already implemented support for the Wallet Standard, and the usage method can be found in the official documentation: https://docs.sui.io/standards/wallet-standard

Support from DApp Development Libraries

wagmi

wagmi provides support for EIP-6963 through the mipd library (https://github.com/wevm/mipd). The specific method can be found in wagmi's documentation.

RainbowKit

RainbowKit (https://www.rainbowkit.com/) is based on wagmi's internal logic, so it has also provided built-in support for EIP-6963.

Ant Design Web3

The Ethereum and Solana adapters of Ant Design Web3 (https://web3.ant.design/) have provided very good support for both standards, and it is very convenient for developers to enable them.

For Ethereum DApp developers, they only need to add the eip6963 configuration, paying attention to the lines 23-25 related to EIP-6963:

And if you are a Solana ecosystem DApp developer, the method is similar. It provides the autoAddRegisteredWallets property:

Conclusion

EIP-6963 and Wallet Standard can greatly improve the user experience of connecting wallets and reduce the barriers to entry for new wallet providers. It is hoped that in the future, more chain platforms, wallets, and DApp developers can provide or implement relevant standards, which will contribute to the better development of Web3.

This article was written by gin-lsl from the ZAN Team (official account @zan_team).

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。