[Feat]: Further EIP-2612 support - handle 'allowed' values

[digiwand]

What is this about?

Check that an EIP-2612 with allowed specified instead of value works as expected. Is it reflected on the Permit Simulation? Will it be supported by the upcoming Signature API?

Backwards Compatibility

• Instead of value, can support allowed (values are handled differently. Please read doc to add support)

  instead of taking a value argument, it takes a bool allowed, setting approval to 0 or uint(-1).

Scenario

No response

Design

No response

Technical Details

No response

Threat Modeling Framework

No response

Acceptance Criteria

No response

Stakeholder review needed before the work gets merged

• [ ] Engineering (needed in most cases)
• [ ] Design
• [ ] Product
• [ ] QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
• [ ] Security
• [ ] Legal
• [ ] Marketing
• [ ] Management (please specify)
• [ ] Other (please specify)

References

No response

[cryptotavares]

Can we break down each highlighted item into its own ticket?

[digiwand]

Updated this ticket to address the first bulletpoint only. Created https://github.com/MetaMask/metamask-extension/issues/27357 to address the ensure owner != address(0) bulletpoint.

Looking into the second bulletpoint,

There is also an implementation in the token Stake (Ethereum address 0x0Ae055097C6d159879521C384F1D2123D1f195e6) with the same ABI as dai but with different semantics: it lets users issue “expiring approvals”, that only allow transferFrom to occur while expiry >= block.timestamp.

It does appear that this happens onchain, so I think there is no need to address this one. Removed from board