SignTypedData failed with "A generic request processing error has occurred"

Description of the issue:
I’m using ethers v5.7.2 to send request eth_signTypedData_v4 to request message sign to connected wallet

Here is the code I’ve been using for requesting this signature

import { Web3Provider } from '@ethersproject/providers'

const typedData = {
  types: {
    'Hubble Exchange': [
      { name: 'action', type: 'string' },
      { name: 'notice', type: 'string' },
      { name: 'chainId', type: 'string' },
      { name: 'nonce', type: 'int' },
    ],
  },
  domain: { name: 'Hubble Exchange', version: 'v2', chainId: 1 },
  primaryType: 'Hubble Exchange',
  message: {
    action: 'Hey sign this message',
    notice: 'Only sign this on example.com',
    chainId: '1',
    nonce: 0,
  },
}

const signer = (new Web3Provider(window.ethereum)).getSigner()

const signature = await signer._signTypedData(
  typedData.domain,
  typedData.types,
  typedData.message
)

Here is the error I get from brave wallet

{code: 4200, message: 'A generic request processing error has occurred'}

For reference ethersjs sends eth_signTypedData_v4 request

async _signTypedData(domain: TypedDataDomain, types: Record<string, Array<TypedDataField>>, value: Record<string, any>): Promise<string> {
        // Populate any ENS names (in-place)
        const populated = await _TypedDataEncoder.resolveNames(domain, types, value, (name: string) => {
            return this.provider.resolveName(name);
        });

        const address = await this.getAddress();

        try {
            return await this.provider.send("eth_signTypedData_v4", [
                address.toLowerCase(),
                JSON.stringify(_TypedDataEncoder.getPayload(populated.domain, types, populated.value))
            ]);
        } catch (error) {
            if (typeof(error.message) === "string" && error.message.match(/user denied/i)) {
                logger.throwError("user rejected signing", Logger.errors.ACTION_REJECTED, {
                    action: "_signTypedData",
                    from: address,
                    message: { domain: populated.domain, types, value: populated.value }
                });
            }
            throw error;
        }
    }

Is the issue occurring on a specific network?
no

What operating system are you using?
MacOS

Brave Version (check About Brave):
Version 1.61.104 Chromium: 120.0.6099.115 (Official Build) (arm64)

Additional Information:

I see in your example that version is set to ‘v2’ should this be ‘v4’?

Here are the official docs for how to sign with window.ethereum

Is there a difference in using signer._signTypedData vs signer.signTypedData https://docs.ethers.org/v6/api/providers/#Signer-signTypedData?

Can you explain how it is set to ‘v2’ in above example?

There is no diff using signer._signTypedData vs signer.signTypedData
the one with _ is from ethers v5.7.2 (they added _signTypedData to be backward compatible for signTypedData and also support ‘v4’ with _[underscore] version)

Hey, please help me debug this.

I ran your code locally and found the issue.

the “type” for nonce should be not be “int”.

changing to “uint256” worked for me

const typedData = {
      types: {
        'Hubble Exchange': [
          { name: 'action', type: 'string' },
          { name: 'notice', type: 'string' },
          { name: 'chainId', type: 'string' },
          { name: 'nonce', type: 'uint256' },
        ],
      },
      domain: { name: 'Hubble Exchange', version: 'v2', chainId: 1 },
      primaryType: 'Hubble Exchange',
      message: {
        action: 'Hey sign this message',
        notice: 'Only sign this on example.com',
        chainId: '1',
        nonce: 0,
      },
    };
1 Like

For reference:

From https://eips.ethereum.org/EIPS/eip-712
Definition : The atomic types are bytes1 to bytes32 , uint8 to uint256 , int8 to int256 , bool and address . These correspond to their definition in Solidity. Note that there are no aliases uint and int . Note that contract addresses are always plain address . Fixed point numbers are not supported by the standard. Future versions of this standard may add new atomic types.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.