EIP-712 Signature Validation Failing with viem/wagmi & OZ ECDSA.recover Despite Matching Digests

[keplerdigitals-avia]

Hi everyone,

I'm encountering a persistent EIP-712 signature validation issue when trying to deploy an ERC1155 contract using a factory pattern (ERC1155Factory.sol) and client-side signing.

Context:

• Frontend: React app using wagmi (useSignTypedDataAsync) and viem. Signing is handled by MetaMask.
• Backend: Node.js/Express API using ethers.js (v6+). Receives the config data and the user's signature, then calls the factory contract.
• Contract: Solidity ^0.8.13, using OpenZeppelin's EIP712 and ECDSA.recover for validation. Deployed on Sepolia.
• Flow:
  1. Frontend gets nonce from the factory contract via API.
  2. Frontend prepares EIP-712 domain, types, and message (using BigInt for nonce).
  3. User signs using MetaMask via signTypedDataAsync.
  4. Frontend sends config data (name, symbol, baseURI, ownerAddress) and the userSignature to the backend API.
  5. Backend API calls ERC1155Factory.deploy1155ForUser(name, symbol, baseURI, ownerAddress, userSignature).
• Problem: The backend call consistently fails during estimateGas with execution reverted: "ERC1155Factory: Invalid signature or owner". This indicates the require(signer == owner) check inside the contract (using ECDSA.recover) is failing during simulation.

Debugging Steps & Findings:

1. EIP-712 Domain/Types: Verified strict consistency between frontend (viem), contract (ERC1155Factory.sol), and backend (ethers.js).
2. Nonce Handling: Confirmed nonce is fetched correctly and passed as BigInt to signTypedDataAsync.
3. Flattened Structure: Initially, we used a nested struct (ERC1155Config) in the EIP-712 type. Suspecting encoding differences between viem and Solidity, we flattened the structure (DeployERC1155(string name, string symbol, string baseURI, address owner, uint256 nonce)) across the contract, frontend types/message, and backend validation/hashing.
4. Digest Matching: Crucially, after flattening, logs confirm that the digest calculated by viem (hashTypedData) in the frontend exactly matches the digest calculated by ethers.js (TypedDataEncoder.hash) in the backend just before the contract call.
   • Matching Digest Example (from last test): 0xb6172fa3ab619dc3f892b1ebb95361f4b85700e1bdcee9f7a40bca019b975593
5. Forge Tests Pass: Isolated tests written in Forge (using vm.sign on the calculated digest) for the exact same flattened contract logic pass successfully. ECDSA.recover correctly validates the signature generated by vm.sign.
6. Native ecrecover Test: Temporarily replacing ECDSA.recover with native ecrecover in the contract also failed to recover the correct address from the viem/MetaMask signature, suggesting the issue lies with the signature format/interpretation itself. (We reverted back to ECDSA.recover afterwards).
7. Signature Format (v): The v value in the signature generated by the frontend appears correct (e.g., 0x1c = 28).

Core Problem:

Even with matching EIP-712 digests (confirmed across viem and ethers.js with the flattened structure) and using the standard OpenZeppelin ECDSA.recover, the signature generated by viem/wagmi/MetaMask (0x840f... in the last test) is not considered valid by the contract during estimateGas.

Specific Data (from last failing attempt):

• Factory Address (Sepolia): 0x3360648578FAFB04Eb3B46FdE7A1CF62126B30BD
• Signer Address: 0xBE1D984e4B9d66F4848a23423435762db7eAF1BD
• EIP-712 Domain:

  {
    "name": "ERC1155Factory",
    "version": "1",
    "chainId": 11155111,
    "verifyingContract": "0x3360648578FAFB04Eb3B46FdE7A1CF62126B30BD"
  }

• EIP-712 Types (Flattened):

  {
    "DeployERC1155": [
      { "name": "name", "type": "string" },
      { "name": "symbol", "type": "string" },
      { "name": "baseURI", "type": "string" },
      { "name": "owner", "type": "address" },
      { "name": "nonce", "type": "uint256" }
    ]
  }

• Message Signed:

  {
    "name": "try token",
    "symbol": "TRY",
    "baseURI": "https://mondomaine.xyz/api/nft/metadata/",
    "owner": "0xBE1D984e4B9d66F4848a23423435762db7eAF1BD",
    "nonce": "0" // Passed as BigInt(0) to signTypedDataAsync
  }

• Matching Digest (Frontend & Backend): 0xb6172fa3ab619dc3f892b1ebb95361f4b85700e1bdcee9f7a40bca019b975593
• User Signature (from viem/MetaMask): 0x840f97e4b53948734113c668ad6fcc12eca26ec4eb8c3925fe8bc128b6ebf37b4a5f549c75b2d34103c63e3ef3544e8161c9842f9a01734a1544613550739d201c

Question:

Has anyone encountered similar validation failures with ECDSA.recover for signatures generated by viem/wagmi/MetaMask, specifically when the EIP-712 digest is confirmed to be correct? Are there known subtle incompatibilities, signature formatting issues (beyond the standard v value), or encoding nuances that could cause this?

Any insights or suggestions on how to further debug the signature interpretation on the EVM side would be greatly appreciated!

Thanks!