[Investigation]: Further EIP-2612 support for Redesign Confirmations

[digiwand]

What is this about?

We need to investigate the following EIP-2612 support further and potentially address:

• Backwards Compatibility

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

    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.

• Security Considerations

  • Check

    it is important to ensure owner != address(0) to avoid permit from creating an approval to spend “zombie funds” belong to the zero address.

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