[ERC-2771] Forwarder. Verify returns the wrong address

Hello OpenZeppelin team !

I am working on the Hedera network.
We are currently trying to test and verify that your wonderful library works on our environment.
SO now I am currently working on the [ERC2771] setup.

Trying to test the setup with Hardhat/Ethers.
I have a [Forwarder] -> (.../OpenZeppelin/openzeppelin-contracts/blob/v5.0.0/contracts/metatx/ERC2771Forwarder.sol) contract instance and a [Context] -> (.../OpenZeppelin/openzeppelin-contracts/blob/v5.0.0/contracts/metatx/ERC2771Context.sol) contract instance deployed.

Here are some steps that I have done so far:

  1. I am creating a transaction object using the populateTransaction api on the contract. with the method I want to call with my Meta transaction
  2. Signing it with the ethers function for signing typed transactions: _signTypedData
  3. Adding the signature to the transaction object
  4. Seding it to the verify function form the Forwarder.sol

The verify function returns the wrong address.
Not the address of wallet2 in the GIST.


As a side question ...can you please satisfy my curiosity.
How are we expecting to verify the address from the Request object ... when you guys are adding some additional fields (some of them static) to the ABI encode here :


And the signature is created without them.
I am asking about _FORWARD_REQUEST_TYPEHASH and nonces

Another question I have is. Why are you cutting the domainSeparator and structHash here:


Are we not losing some information that way ?

Thank you very much in advance.
I realize its a long answer ...

Best regards :slight_smile:
Stefan

:1234: Code to reproduce


:computer: Environment

1 Like

They're not cutting anything.

They simply concat the following pieces of information into a single memory block of 66 bytes:

  • 2 bytes containing the values 19 and 1
  • 32 bytes containing the value of domainSeparator
  • 32 bytes containing the value of structHash

In case you're confused with the hexadecimal notation in this piece of code, note that:

66 = 2 + 32 + 32 = 0x2 + 0x20 + 0x20 = 0x42
1 Like

Oh ...That's right. I got confused.
0x20 is 32 in decimal. I am new to the ecosystem
Thank you Sir Barakman :slight_smile:

Do you have any insight on my other questions ?

1 Like

How are we expecting to verify the address from the Request object ... when you guys are adding some additional fields (some of them static) to the ABI encode here

Hey @Stefan_Stefanov, I think this issue in Github will provide you better context on why the typehash differs from the actual ForwardRequestData type

If you need some ethers.js reference for verifying a signature, please refer to the tests (although not merged yet) or their Solidity version

Hope it helps!

Hey !

Thanks a lot for the resources.
The unmerged PR did the trick.
You made my day.

Best of wishes.
Stefan