Does not connect to specified network apparently randomly

[Quicksaver]

I try to connect the sequence wallet to the bnb network, but the resulting web3 provider object always connects to the polygon network.
This makes it impossible to use the provider directly (which is much simpler to adapt our code to implement the sequence wallet).

Symptoms:

• this happens both for testnet or mainnet
• every once in a while I will refresh the page and try again and it will connect to the bnb network, this happens apparently randomly, then I refresh again and it connects to polygon again
• a wallet_switchEthereumChain to try to switch it to the wanted network always fails with a 4001 code, apparently rejected by the sequence wallet itself (I'm assuming this is by design due to how the sequence wallet handles multinetwork, however makes it impossible to control the provider object in this way) (this was likely a symptom of Events are not triggering #326 , although I'm not sure why I had 4001's, but I can't reproduce those anymore at least)
• if I try it directly from the browser console, it always connects to the correct network, which is a bit maddening as it's the exact same code...

Code:

import { sequence } from '0xsequence';

let provider;

const getSequenceName = chainId => {
  switch (chainId) {
    case 97:
      return 'bsc-testnet';
    case 56:
    default:
      return 'bsc';
  }
};

// For debugging in console
if (typeof window !== 'undefined') {
  window.Oxsequence = sequence;
}

const connect = async ({ chainId }) => {
  const name = getSequenceName(chainId);
  console.log({ chainId, name });

  provider = await sequence.initWallet(name);
  console.log({ provider, name });
  try {
    // const connection = await provider.connect();
    // The `networkId` parameter in here was me trying to select the network once again, the same thing happens
    // regardless of if passing it or calling connect without it.
    const connection = await provider.connect({ networkId: chainId });
    console.log({ connection });
    console.log({ chainId: await provider?.transport.provider.getChainId() });
    return !!connection?.connected && provider?.transport.provider;
  }
  catch (ex) {
    // eslint-disable-next-line
    console.error(ex);

    return null;
  }
};

Result screenshot:

[tolgahan-arikan]

Yep I can also confirm that passed network options aren't taking affect, because saved session is loaded right after creating the Wallet, and default network from saved session takes precedence. We will work on this to make it behave as expected.

Meanwhile, sequence actually supports passing chainId with all operations, so signMessage, sendTransaction etc. can be used with explicit chainIds, that should allow to overcome this issue till it's fixed.

Thank you for all the reports btw, we appreciate you taking time to post these in detail 🙏 🙏

[davidchingmy]

I have similar issue where I try to switch network using Wagmi's switchNetwork, Sequence seems to throw an error with code=4001. I also tried to put chainId within Wagmi's prepareWriteContract but gettingChainMismatchError: Chain mismatch: Expected "Binance Smart Chain Testnet", received "Chain 137".. Is there any quick workaround for Wagmi-Sequence integration?

[Quicksaver]

Update on this from our side, given the multi-chain nature of Sequence (i.e. passing a chainId to each transaction method as suggested 👌 ), it's relatively straightforward to overcome this limitation.

This however required us to use the Sequence methods, rather than using web3js with the Sequence provider, which greatly hinders using Sequence with ethers or web3js or other existing libs; we wound up having to rewrite our entire blockchain/connection code from scratch to allow calling arbitrary methods like Sequence's rather than going through web3js; this is of course a plus for us in terms of compatibility and control with more potential wallets, but still a hell of a lot more work than we wanted, as we were expecting web3js to just work.

Given the benefits that we hope Sequence bring us, it's work well spent for us, but other projects might think twice if they can't use their existing code. 😄

[pkieltyka]

thanks for the feedback :) we'll look to keep improving the library to smooth out these edges