Browser Extension - eth_signTypedData_v4 "Error - ChainId Mismatch"

[Quicksaver]

Describe the bug With the Trust Wallet browser extension, we cannot use the request method eth_signTypedData_v4, as it either fails the sign request, or does not even allow to click the confirm button to proceed.

To Reproduce With the extension enabled, the following in your browser console will cause the "ChainId Mismatch" error in the screenshot below:

await window.ethereum.request({
  method: 'eth_signTypedData_v4',
  params: [
    (await window.ethereum.request({ method: 'eth_requestAccounts' }))[0],
    JSON.stringify({
      domain: {
        name: "Foobar",
        version: "1"
      },
      message: {
        nonce: "a-unique-nonce-hash"
      },
      primaryType: "Auth",
      types: {
        EIP712Domain: [
          { name: "name", type: "string" },
          { name: "version", type: "string" }
        ],
        Auth: [
          { name: "nonce", type: "string" }
        ]
      }
    }),
  ]
});

If I explicitly set a chainId on the domain, sometimes it will trigger the same error, other times it will let me confirm the sign request, however it will fail with error code -32603 and message "The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type undefined":

await window.ethereum.request({
  method: 'eth_signTypedData_v4',
  params: [
    (await window.ethereum.request({ method: 'eth_requestAccounts' }))[0],
    JSON.stringify({
      domain: {
        chainId: window.ethereum.chainId,
        name: "Foobar",
        version: "1"
      },
      message: {
        nonce: "a-unique-nonce-hash"
      },
      primaryType: "Auth",
      types: {
        EIP712Domain: [
          { name: "chainId", type: "string" },
          { name: "name", type: "string" },
          { name: "version", type: "string" }
        ],
        Auth: [
          { name: "nonce", type: "string" }
        ]
      }
    }),
  ]
});

Expected behavior The same code works just fine with Metamask for instance, and also on Trust Wallet for mobile even. Only the browser extension seems affected.

Screenshots

Additional context Tested Chrome version only on both Windows and MacOS.

[vodis]

The same issue with 'personal_sign' at extension only. Environment:

• Trust Wallet Extension Version 0.0.229
• Google Chrome Version 109.0.5414.119 (Official Build) (x86_64) We are using @wagmi/core library: const signature: string = yield signMessage({ message: message as string }) Got error:

[J1psy-HUSSLE]

I DONT KNOW!!!!Sent from my iPhoneOn Feb 23, 2023, at 19:50, Trustwallet @.***> wrote: @Quicksaver @vodis We'd be happy to look into this for you kindly file a support ticket below https://forms.gle/7KbQyuY5NoxyrhNz5

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[kikaannen]

@y3fers0n @hewigovens Circling back on this reported issue, is there any feedback you can share? Is there any other information you need from our part to resolve this? Since it has been a month, we really need more insight on this matter.

[JoaoArturCosta]

Hi, the solution is to provide the ChainId like so

{ domain: { name: '', version: '1', chainId: 97 }, message: { nonce: 'your_message' }, primaryType: 'Auth', types: { EIP712Domain: [ { name: 'name', type: 'string' }, { name: 'version', type: 'string' }, { name: 'chainId', type: 'uint256' } ], Auth: [ { name: 'nonce', type: 'string' } ] } }

[bonustrack]

@JoaoArturCosta Can you not enforce a chainId? Currently it's blocking voting on snapshot.org using the mobile app internal browser, on others wallets it's working fine, we only have report of this issue for TrustWallet

[y3fers0n]

@JoaoArturCosta Can you not enforce a chainId? Currently it's blocking voting on snapshot.org using the mobile app internal browser, on others wallets it's working fine, we only have report of this issue for TrustWallet

Hello, why don't you send the chainId?

[JoaoArturCosta]

Hi, I've already provided the solution above, which is indeed to enforce the chainId, but nowhere is it marked as required or even mentioned. I found the solution by trial and error and also it seems a bit weird that only the browser extension needs the chainId parameter, everywhere else it isn't needed