YDai implements the draft ERC 2612 via the ERC20Permit contract it inherits from.
This allows a third party to transmit a signature from a token holder that modifies the ERC20 allowance for a particular user.
These signatures used in calls to permit in ERC20Permit do not account for chain splits.
The chainID is included in the domain separator.
However, it is not updatable and not included in the signed data as part of the permit call.
As a result, if the chain forks after deployment, the signed message may be considered valid on both forks.
Short term, include the chainID opcode in the permit schema. This will make replay attacks impossible in the event of a post-deployment hard fork. Long term, document and carefully review any signature schemas, including their robustness to replay on different wallets, contracts, and blockchains. Make sure users are aware of signing best practices and the danger of signing messages from untrusted sources.
- ToB Audit Yield Protocol Finding 8
- Access Control
- High Severity
- ERC20Permit Signatures
- Replay on Forks
- Include ChainID Opcode
- Youtube Reference
- High Risk severity finding from ToB’s Audit of Yield Protocol