Support for EIP-2612 (Permit)

[razgraf]

Should we support tokens that have permit enabled?

Permit has provided a really nice UX improvement to the old and clunky allowance system. As per EIP-2612 and the example implementation from OpenZeppelin it doesn't look like we would have to make very intrusive updates to the contracts.

From initial research, we would have to implement createWithPermit / createWithDurationAndPermit methods that take in 4 additional parameters (a deadline and 3 arguments of the elliptic curve based signature). These method would perform an extra call to the token's permit functionality before reaching the internal _create call.

 IERC20Permit(address(asset)).permit(msg.sender, address(this), assets, deadline, v, r, s);

[PaulRBerg]

IMHO this is a "nice to have", a priority 4. Not because of the added complexity in the contracts (this would be implemented as part of a proxy target contract anyway), but due to the overhead it adds to the frontend. Since we have a few dozen priority 1 features to implement in the UI, I'd suggest first building those before even considering EIP-2612.

FWIW, I offer an ERC20Permit implementation as part of my prb-contracts library, so this is a feature that should be discussed in the context of the frontend work. The contracts part is easy-peasy.

[PaulRBerg]

Going to lock this in favor of #11. If we are going to support permit-like signatures, we will do it with Permit2.