wagmi.useContractWrite with explicit chainId fails due to non-hex chainId

[ryanberckmans]

wagmi hook useContractWrite takes chainId?: number, a base 10 (decimal) number, but it appears that web3auth expects chainId to be passed as an 0x-prefixex string, and so useContractWrite fails with Error: Cannot convert string to buffer. toBuffer only supports 0x-prefixed hex strings and this string was given: 5 (in this case, '5' is the chainId for Goerli).

The fix might be for web3auth-wagmi-connector to map numeric chainIds from wagmi to hex strings.

It looks like the error occurs when https://github.com/wagmi-dev/wagmi/blob/main/packages/core/src/actions/contracts/writeContract.ts#L145 calls sendTransaction, which afaik delegates to web3auth's signer, and that may be when the numeric chainId fails when it's expecting a hex chainId.

[ryanberckmans]

@chaitanyapotti this issue is still occurring in 3.0.0. I would be interested in knowing if anybody has a working wagmi integration that's able to sign transactions with 3.0.0 and 0.11.x.

[ryanberckmans]

@chaitanyapotti @yashovardhan I hope you guys are doing well.

I wanted to provide some feedback:

Web3auth seems great, but the developer support has not been good.

I filed this issue four weeks ago. It's blocking me from succeeding with the basic use-case of signing erc20 transfers with your wagmi connector.

I've spent quite a bit of time building a nice web3auth wagmi integration that provides code-splitting and lazy loading of the web3auth connector and abstracts over the web3auth login provider with a helpful API. I'd be willing to contribute this to the web3auth community, but first I need developer support to get web3auth working, or else I will have no choice but to abandon web3auth in favor of getting moving quickly solutions like magic link, coinbase wallet, or patch wallet, that may require more work or tradeoffs on my side, but at least they work at all.

[yashovardhan]

Hey @ryanberckmans

Sorry for the terrible experience you had with the support here. Unfortunately this is the case since we typically don't give support on github issues. Our community portal (community.web3auth.io) is where the engineering team is most active in and we do general support there.

We'll look into this issue of your, however please use the community portal for any questions. It will be easier for us to help you out there.

[ryanberckmans]

Hi @yashovardhan,

Thanks for your reply, I really appreciate it.

Sure, I'll use the community portal. But note that most of the entire software world and almost the entire crypto industry uses github issues for feedback and discussions. We've found it helpful to colocate conversation and code, and it probably isn't helping web3auth to deviate from this social norm. If this is important to web3auth, I'd recommend disabling github issues on all your public repos and posting clear instructions to go to the community portal.

For now, can you please create a thread in the community portal for my issue and I will sign up and subscribe to it? Please link the thread here, and then I will subscribe to it and close this issue.

[yashovardhan]

@ryanberckmans

Considering the number of support requests we have, we had to make this decision. For now, since we have already discussed quite a bit about this here, it is kind of redundant to make another thread. For the future it might help you get faster responses.

I will properly investigate this issue and get back to you as soon as possible.

[ryanberckmans]

@yashovardhan thanks. My frustration only reflects my eager desire to use web3auth in production with wagmi 😄

[yashovardhan]

@ryanberckmans can you check if this issue was fixed for you in the 3.0.1 release?

[ryanberckmans]

Hi @yashovardhan

I've verified this bug still exists in the 3.0.1 release. Do you have a link to the fix diff?

My setup:

    "@web3auth/base": "^5.1.0",
    "@web3auth/core": "^4.6.0",
    "@web3auth/openlogin-adapter": "^5.1.1",
    "@web3auth/web3auth-wagmi-connector": "^3.0.1",
    "wagmi": "0.12.6" // this bug also occurs on wagmi 0.10.x/0.11.x

Screenshot of bug (same as it was):

[ryanberckmans]

The error is being thrown during an eth_chainId rpc request. See the request object:

[yashovardhan]

Hey @ryanberckmans

I tried replicate the problems you were facing. Here is the link to the PR where you can find the example: https://github.com/Web3Auth/web3auth-wagmi-connector/pull/60

It is working totally fine for me. Can you help me reproduce this issue?

[ryanberckmans]

@yashovardhan I eventually figured out that I was passing a non-hex chainId in the initial chainConfig. I thought it was related to transaction signing because the client initialized without error, and no error was shown until attempting to send a transaction.

Here's an API fix you can use to help prevent future customers from this issue:

Current:

export type CustomChainConfig = {
    /**
     * The chain id of the chain
     */
    chainId: string;
}

Improved:

export type CustomChainConfig = {
    /**
     * The chain id of the chain as a hex string. Example construction: `0x${chainId.toString(16)}`
     */
    chainId: `0x${string}`;
}

@yashovardhan I spent a long time working on these issues today, and would appreciate it if you can answer these questions for me:

1. When I logged into web3auth with my email in your demo, the ethereum public key is different than when I log in with my email in my app. Why is that? Is this something that would happen to my customers in production-- if they log in with bob@bob.com into my app, and then log into bob@bob.com in another app's web3auth, will those accounts be the same?

2. What if they log in with gmail oauth for bob@bob.com vs. email bob@bob.com?

3. How can I disable or prevent my users from seeing "Enable 2 Factor Authentication (2FA)" prompt when signing in? I don't like this pop-up because it adds and extra step and can cause confusion when the user returns to the app, but the app isn't yet connected because it's hanging on waiting for the user to dismiss the 2FA prompt.

[yashovardhan]

@ryanberckmans thanks for recommendation. I'll talk to the engineering team for suggested change.

Talking about your questions:

1. The keys in web3auth are app scoped, this is because you're getting access to the user's account totally, if you can access the user's account on another app, it can be a security issue. Basically, every application receives a different private key based on their client id.
2. If you're logging in via different social logins with common email, you'll get the same key only if you're using an aggregate verifier. While using two different verifiers, you'll always get a different private key from both. (https://web3auth.io/docs/auth-provider-setup/aggregate-verifier)
3. You can set the mfaLevel value to none for skipping that prompt. (https://web3auth.io/docs/sdk/web/modal/mfa)

Also all these things have been previously answered in the community portal. You can search for these questions for knowing the answers earlier. It will be useful for your workflow.

[ryanberckmans]

Thanks for the quick response and answers, @yashovardhan! I will try to use the community portal more often.

To be honest, I think you guys may reconsider using github issues and discussions for developer customers. Everyone in the industry wants to use them, they are much more convenient because they are colocated with code and everybody already has github accounts. Look at wagmi, they have great issue hygiene and community discussion on github.