Is OpenGSN compatible with EIP2612?

Hello everybody! I’m curious if OpenGSN and contracts implementing EIP2612 permit() are compatible. Could I call a function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external trough OpenGSN.

More specifically, the main logic of the protocol I’m working on requires the user have previously approved the use of some USDC, which only implements EIP2612 permits and not EIP2771 metaTx. So even if I implement EIP2771 in my protocol I still could not remove ETH from my app because the user would need it to make the initial approval of tokens. Would I need to wait until USDC upgrades to EIP2771? Or is there any workaround that does not compromise security?

Hello @SuperCS92
Well, the GSN relies on ERC-2771 Meta-Transactions, where the signature is verified by a separate Forwarder contract and the target relies on the Forwarder to tell it who the real sender is.
ERC-2612 on the other hand makes the token contract itself validate the signature.
This means that in order to call a permit method you need a separate signature. However, you can make a call to the permit method as part of your Paymaster’s flow, for example, and the user does not need to have any ETH to execute such call.

We have an example of doing so in a Permit Token Paymaster. The paymasterData here is an ABI-encoded call to function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s).