Investigate WalletConnect support

[LukSteib]

Goal

Outline on how to implement WalletConnect support

Context

Current we support metamask only. Although this is the wallet with highest adoption so far, chances are that users would like to interact with our UI using a different wallet.
In the early days we arleady decided that WalletConnect would be a good way to go since this service constitutes a wallet aggregator on its own. So implementing support for WalletConnect would allow us to support a range of other wallets as well.

Tasks

• Understand the current wallet implementation
• Understand WalletConnect preferred way of interaction
• Come up with a plan on how to support walletConnect and make a proposal in this issue

Assets

WalletConnect docs:
https://docs.walletconnect.com/

[valiafetisov]

• There is already a scaffold ready to be filled in with WalletConnect api calls: https://github.com/sidestream-tech/unified-auctions-ui/blob/main/frontend/lib/wallets/WalletConnect.ts
• You can get inspiration from the metamask integration https://github.com/sidestream-tech/unified-auctions-ui/blob/main/frontend/lib/wallets/MetaMask.ts

[aomafarag]

Implementation suggestion

As far as I understood, the implementation would be very similar to that of MetaMask. For that, we need to:

• import WalletConnectProvider from @walletconnect/web3-provider
• initialize WalletConnectProvider as follows (the rpc object requires at least one property):

const provider = new WalletConnectProvider({
  rpc: {
    CHAIN_ID: RPC_URL
    ...
  },
});

Then, we can pass provider to ethers and apply the same logic as with MetaMask.

---

Concern/question

• @walletconnect/web3-provider seems to be not actively supported as of v2.0 of WalletConnect. Instead, support seems to be moving to Web3Modal, which is still a work-in-progress (I guess they only support React for some reason).
• The other option would be to use the signClient directly. However, it has a different logic and is more complicated to use.

[valiafetisov]

• @walletconnect/web3-provider seems to be not actively supported as of v2.0

Can you please link to the source of this conclusion? Do they announce it somewhere? I can see that the latest version was released 3 months ago, but there are plenty of activity inside their monorepo.

const provider = new WalletConnectProvider({
  rpc: {
    CHAIN_ID: RPC_URL
    ...
  },
});

This look fine, although there could've been a better api (on their side) without directly providing them with the list of urls, since this logic is complicated on our side.

• Do you want to outline how would you provide RPC url to them?
• Can we provide just one chain id and recreate WalletConnectProvider in case network changes? (since we support adding chains dynamically)
• Is it possible to change networks within their extension?
• Does localhost networks works with them?

[aomafarag]

Can you please link to the source of this conclusion? Do they announce it somewhere? I can see that the latest version was released 3 months ago, but there are plenty of activity inside their monorepo.

Documentation for the Web3 Provider is only available on the v1.0 website, which has this banner:

This is documentation for WalletConnect Docs v1.0, which is no longer actively maintained.

For up-to-date documentation, see the latest version (v2.0).

Also, there's no Web3 Provider repo in any of WalletConnect's projects on GitHub.

• Do you want to outline how would you provide RPC url to them?

Through .env as usual.

• Can we provide just one chain id and recreate WalletConnectProvider in case network changes? (since we support adding chains dynamically)

I would initially say yes. In MetaMask, for example, we always call getProvider() in case of a network switch, which returns new ethers.providers.Web3Provider(window.ethereum, 'any'). In WalletConnect's case, we could just recreate WalletConnectProvider before returning. However, this needs to be tried out and tested.

• Is it possible to change networks within their extension?

Their provider can listen to accountsChanged and chainsChanged if that's what you mean.

• Does localhost networks works with them?

Again, I would initially say yes, as they don't mention otherwise in their documentation. However, this will also need trying out and testing.

[valiafetisov]

Through .env as usual

We already have RPC_URL env variable and don't want to extend it or provide it via another way. So my suggestion is to adapt out logic which parses RPC_URL into one or an array of chain ids and call/reuse it here