How to Seamlessly Support Web3 Connectivity Options in React.js | by Sean Lawless | November, 2022

Wallet Interoperability for dApps

Give users seamless option to add and add any web3 wallet. Image by Wangxina on Freepik.

An ongoing challenge for user interface (UI) creators of decentralized applications (i.e., dApps) is linking a user’s wallet to read the ownership state and transacting with the smart contracts built into it. Critical to user choice in a world of decentralized security, user wallets remain an ongoing UI and security challenge. Wallet connection requirements present a clear barrier to the adoption of Web3 technologies.

Underlining the main problem is the need for a dApp for the user to have a wallet connected. Furthermore, if the UI can be read-only, informative and intuitive that does not require a wallet connection, default support for this mode is highly recommended. This short story describes the journey ImmutableSoft took to integrate more wallet options into its dApp.

MetaMask introduced the Web3-connected wallet experience with a server API to detect and request wallet connections. Now WalletConnect technology is becoming popular with new wallets and is increasingly being requested by users. The main difference between WalletConnect vs MetaMask is how the wallet is connected to the underlying blockchain and how this connection is set up.

Metamask is a browser plugin with blockchain network provider and all-in-one wallet. The plugin keeps the secret keys of your wallet and uses them through the configured blockchain network provider (default Infura node).

The private wallet keys are retained in the browser plugin, and the server UI (ReactJS, etc.) can directly request to connect to this wallet. WalletConnect is not a plugin but a network conduit. If the Web3 DApp requires a wallet connection, a one-time conduit (ie, a URI link disguised as a QR code) must be generated and shown on the UI.

This QR code (i.e., one-time URI) is a connection request to the Wallet application installed on the user’s mobile phone and is scanned.

WalletConnect can also connect to Ledger devices such as desktop wallets. A user request establishes a local network connection to your wallet application (LedgerLive, etc.) instead of a QR code. WalletConnect takes wallet keys from a potentially more sensitive web browser (plugin) and passes them directly to the Wallet application, allowing any number of security innovations and user choices.

With MetaMask and WalletConnect emerging as a leader in web3 wallet integration, this article explores how to easily and intuitively support any technology when a user is required to connect to a web3 wallet . We also explore how to ensure that your dApp works well in read-only mode, as well as encourage users to perform certain actions, such as adding their wallet before making transactions.

Often a dApp presents connect options the first time it is opened, such as two buttons, ‘Open with MetaMask’ and ‘Open with WalletConnect’. However, this confuses or alienates those who are unfamiliar with web3 or are uncomfortable sharing their wallets. This article promotes solutions for setting connection preferences and defaults for what is available and when to offer connection options. Each dApp has different requirements, and the first step is to identify those requirements – maybe two buttons is the best option, but it usually isn’t.

The immutable ecosystem UI is designed as an application store – a marketplace of digital products licensed by their creators. We believed it was important to display marketable products to every visitor, including search engine crawlers. To support this use case of no-wallet, we introduced Infura as a third party provider. Public endpoints and other providers, such as Alchemy, are also supported.

The server-configured no-wallet provider loads DApp Marketplace products without a connected wallet. Finally, we need to support three (3) different connection options, the read-only provider (Infura), MetaMask and WalletConnect technologies.

It was now important to prioritize the connection technology that the dApp chooses to connect to. Since our goal was seamless wallet connection integration and MetaMask supports it, we chose to be the first to try to locate the plug-in. With MetaMask as a priority, there was no disruption to our current user base. If not established/detected (or the connection is refused by the user), JavaScript will use Infura to load the dApp marketplace while presenting a key button to connect the user’s wallet (that at the location where the wallet balance is usually displayed).

Note that a sane user with the MetaMask plug-in can enter this state by denying the MetaMask connection request. This may allow the use of WalletConnect instead of MetaMask for this dApp session within the browser which remains unconnected with the MetaMask plugin.

When ‘Connect Wallet’ is pressed in the top right, a pop-up appears with options to install MetaMask plugin or use WalletConnect. If WalletConnect is selected, the dApp will display a QR code (or direct application connection to LedgerLive, etc.). The QR code is intended and scanned for the mobile device containing the user’s wallet. This QR code is a URI that establishes a temporary network conduit between your wallet and the dApp.

For security purposes, be aware that all blockchain communication for dApps (from loading the market to transactions) occurs through this conduit, not through a web browser. After successful connection, marketplace smart contracts and data are reloaded through WalletConnect and should look similar to the initial version loaded with Infura, but the user now has the ability to sign transactions with the connected wallet .

For security, the WalletConnect connection is temporary (it does not persist), so there is no additional state that needs to be saved by the DApp to allow the user to choose the continuation of the user experience. A new WalletConnect connection must be established and expected in each browser session. But because MetaMask has a server-directed connection capability that WalletConnect does not, it could be an important design choice to fundamentally separate user choices when serving dApp pages.

Let us review the JavaScript code required to configure a Web3 connection to better understand how these options can be effortlessly attempted by the user without unnecessary interaction. On the first dApp page load, MetaMask or Infura (thanks, ConsenSys!) are the number one and two priorities. First, the beginning of our getWeb3() execution.

and now our whole getWalletConnect() execution.

With Infura-loaded dApps, a key option to connect to WalletConnect is provided, but never auto-selected, i.e. a QR code for WalletConnect is never shown without a user request/click. This behavior is in line with WalletConnect style intentions of configuring a one-time, non-persistent way of connecting dApps to a user’s wallet.

This auto-detection of MetaMask with the WalletConnect fallback allows users to completely avoid having to breeze through the connection process or checking the validity of their installation for casual application store downloaders. Those who do not have Web3 wallets are no longer locked outside the dApp, but have emerged within it and experience clear limits on when to connect their wallets.

Logic for interoperating between web3 instances created for MetaMask (getWeb3()) vs WalletConnect (getWalletConnect()) are below, with parameters type between which is used to differentiate. Immediately after web3 The variable is different for MetaMask or WalletConnect, but both have the same public interface used by dApps to load and transact with smart contracts and data using the same server-side API.

Using the binary tree-based priority scheme outlined above to select a user’s wallet, the UI avoids the need to display the dApp only after the wallet is connected. Users who have MetaMask installed will likely want to use it, and those without them will likely want to use WalletConnect or be completely unfamiliar with Wallet.

Please help us make web3 easier to understand for new users. If you enjoyed this article, please follow me to read more in the future. And don’t forget the posito presnibus (leverage assumptions)!

Leave a Comment