Using the OpenGSN forwarder instead of a custom "minimal" one

Support Defender
1

We want to use OpenZeppelin Defender Relay to pay for our users' gas on an L2 network. All examples that I found so far were suggesting to use a custom MinimalForwarder contract but actually there's already a potentially safer OpenGSN alternative available (this is also mentioned in the official docs) that relies on EIP-712 signatures, though. Other threads here mention that it's actually discouraged to use a custom MinimalForwarder contract in general.

Unfortunately I can't find good docs on how all this is supposed to be assembled in general, but I was parsing through that forwarder's internal transactions to get the gist of it. I also checked @spalladino 's sample gists here that make use of EIP-712 but I can't figure out if this is already compatible with the oGSN's forwarder contract :frowning:

To use that oGSN-unique TrustedForwarder at https://goerli.etherscan.io/address/0xB2b5841DBeF766d4b521221732F9B618fCf34A87 I assume we must have our users sign a transaction using EIP-712, and use the oGSN's domain separator (GSN Relayed Transaction), like here: https://goerli.etherscan.io/tx/0x9d76c72228d20530328e3eefa8d0ef08a6d2594eecf586172ae9e1d4d749a799 to build a signature message that's accepted by the Forwarder, right?

I assume, we also must create a message that asks our Defender Relayer to call the trusted forwarder's execute function, wrapping the actual call we want to execute on our target contract into a ForwardRequest structure. If so, I'm wondering what's the signatureSuffix here :thinking: ?

Also, being in an UUPSProxy context, I'm wondering whether a trusted forwarder can be exchanged by redeploying an implementation contract (it's built as a private immutable variable, that's why it's read from the implementation's storage slot, not from the proxy's) by just constructing the implementation with a new trusted forwarder's address?

1 Like
2

Hi @elmariachi111

Even thought MinimalForwarder uses EIP-712, it indeed has some issues why we discourage use in production environment:

  1. It does not provide signature expiry
  2. Might have gas accounting issues since gas is calculated after a call

We are actually working on implementing a production ready forwarder contract. You can track issue here

Using GSN TrustedForwarder is a valid option, however (1) reason means there will be a different signature message and separator and hence the signing script for TrustedForwarder.

The calling trusted forwarder I would suggest implement as an Autotask in your Defender account: use an autotask webhook to trigger an Autotask which has permission to access a relayer. It lets you sign whatever transaction and data object you need and submit it on to the chain.

Regarding proxies - I think you are on the right track, upgrading contracts to point to a correct Forwarder implementation should work since you store that address is in the implementation.

1 Like