WC v2 Proposal namespaces with respect of smart contract wallets

[niallkh]

More users currently are starting using smart contract wallets multichain, especially safe multisig. Smart contract wallet can be deployed selectively on specific chain. Current implementation of @walletconnect/ethereum-provider doesn't respect this and sends ethereum mainnet as required network. See chains, // REQUIRED chain ids. Dapp should work equally on different chains without specifying required network. Because smart contract wallet may be not deployed on required chain, but deployed on optional chains. Wallet can't continue working with dapp because it violates wallet connect protocol 2.4. Session Namespaces MUST contain at least one account in requested chains.

Dapp should be able to send proposal without required chains and not empty optional chains.
From dapp development perspective I think that required chains make sense in rare cases, for instance, if dapp's contracts are deployed only on one chain. When dapp works on several chains it doesn't make sense to provide them as required because wallet may be deployed only in part of them, they should be provided as optional.

According to CAIP-25 required chains are optional. The requiredScopes array MUST contain 1 or more scopeObjects, if present.

References:
wevm/references#330
https://github.com/orgs/WalletConnect/discussions/2383

Steps to reproduce:

1. Suppose that we have Smart Contract Wallet on polygon.
2. Open https://app.uniswap.org/
3. Choose polygon network in chain selector
4. Connect WC v2

Expected:
Wallet receives proposal with required polygon or with empty required chains. Wallet approves session.
Actual:
Wallet receives ethereum as required and polygon as optional. Wallet rejects session as it's not deployed on ethereum.

1. Open https://app.safe.global/ -> deploy wallet on gnosis
2. Use WalletConnect
3. Open https://layer3.xyz/ in other tab
4. Sign in -> WalletConnect
5. Copy WC uri -> insert in safe

Expected:
Continue work with layer3, sign personal message on gnosis.
Actual:
error - "Connection refused: Incompatible chain detected. Make sure the Dapp uses Gnosis Chain to interact with this Safe."

[finessevanes]

@niallkh hey - this is actually something that has come to our attention and we will be making an update to allow empty chains soon.

[Ellu39940]

Let me know if there are updates!

[yagopv]

Latest version include this change.

We are testing @walletconnect/web3wallet latest version and we can send the requiredNamespaces empty

[Sednaoui]

thanks @yagopv ! Great to see this moving quickly.

We contacted the dapps that our wallet had trouble connecting to. Pooltogether mentioned they are using Rainbowkit and Wagmi. They don't explicitly add a required chain in the namespace. I am assuming either Rainbowkit or wagmi default on a certain behavior.

Could you please help communicate this update to them? (I would be more than happy to write down the problem and test. I just don't have connections to these teams..)

[amal]

wagmi issue: wevm/references#330

[yagopv]

The latest WC release is working for us:

For connecting to a smart contract Wallet (as Safe) through WC 2.0 protocol the dApp can be either:

1. RECOMMENDED: Set 'requiredNamespaces' as undefined and send all the chains the dApp wants to support in the 'optionalNamespaces'. This will work, as the WalletConnect protocol continues to connect even if the smart contract Wallet only approve one chain.

2. Send 'requiredNamespaces' with a single chain, the chain to which the smart contract Wallet is connected. If more than one is sent, the connection probably will fail depending on the wallet implementation

[Sednaoui]

Hello @finessevanes, we encountered the same issue when migrating to v2 with our smart contract wallet, and it prevented us from connecting to any dapp. It's crucial to address this issue and allow for empty chains in order to ensure compatibility with smart wallets.

However, it's worth noting that smart contract wallets are often treated as second-class citizens on EVM equivalent chains. Dapp developers typically assume that an externally owned account (EOA) is connected and that the wallet can defaults to Ethereum mainnet, even when accessed on a different chain on the dapp interface. Consequently, they include it in the required namespaces. Uniswap, SushiSwap, Galxe, Slingshot, Furucombo, and several other dapps follow this behavior.

Additionally, we discovered some dapps that specifically request support for methods that are specific to EOAs, such as wallet_switchEthereumChain and wallet_addEthereumChain. Paraswap is an example of such a dapp.

While I understand the purpose of namespaces, I'm unsure if WalletConnect should make adjustments in this regard. However, it would be beneficial to have warnings in the WalletConnect documentation and best practices on how to support smart contract wallets, such as:

• Only adding required name space for chain id if the dapp supports a single network
• Only adding wallet_switchEthereumChain and wallet_addEthereumChain if the dapp must only supports EOAs

We do need help asap communicating this during the migration phase so that dapps don't default on this behavior. We are ready to help on docs, or message.

[glitch-txs]

Hi, what do you mean by this?

Only adding wallet_switchEthereumChain and wallet_addEthereumChain if the dapp must only supports EOAs

This is usually handled by the dapp and they deside whether to use it or not, in which way of use do they mean an issue?

[Sednaoui]

Hey, the issue lies when a dapp add all their supported methods in requiredScopes when starting a session.

The example I gave is Paraswap, where they added wallet_switchEthereumChain and wallet_addEthereumChain in their required namespaces on session initialization. Any wallet that doesn't support these two methods cannot open a connection with Paraswap. As you know, not all wallets are by default multichain, and not all wallets can add new networks (smart contract wallets cannot in most cases).

The bug is Paraswap side, but I can see also small teams defaulting on this behavior. I think good documentations on which methods to add in the requiredScopes vs optionalScopes is important for dapps to think of all wallets cases.

[davidseegers]

Why did it work fine for Wallet Connect v1?

Also, can the Wallet Connect team use their connections to at least get major apps like OpenSea to adapt the fix? I'm completely locked out of OpenSea with my multisig right now, while that is the wallet that controls our NFT contracts.

[MikeC-BC]

I'd also like to understand how comes it worked fine with Wallet Connect v1. Were there no namespaces there?

[DaniSomoza]

From smart contract wallets like Safe, the current approach has its usability limitations. It often becomes overly restrictive, particularly when a DApp initiates a session proposal including some typical scenarios which result in connection failure:

• If more than one chain is included in the requiredNamespaces.chains property
• If the chain that it is included in the requiredNamespaces.chains property is not the Safe chain.
• If a single unsupported method by Safe, such as eth_signTransaction, is included in the requiredNamespaces.methods property. see the full list here.
• If common events like accountsChanged & chainChanged are present in the requiredNamespaces.events property.

These are frequently encountered scenarios, and the present behavior results in limitations on the user experience and the overall adoption of WalletConnect with smart contract wallets.

As a temporary solution, we are “misrepresenting” our compatibility to the DApp by accepting all events like accountsChanged & chainChanged in the requiredNamespaces.events property. However, this is a suboptimal solution that could lead to further complications and does not truly address the core issue.

[HatimPatwa]

@niallkh Hey there,

Fellow developer here. Have you implemented smart accounts with walletconnect,
I am kinda stuck on the signing part of walletconnect i.e personal_sign, would like to connect with you if you have any input how to do that.