TokenFacet.sol Failure to comply with the EIP-2612 could lead to reverts
According to Eip2612 Doc: Compliant contracts must implement 3 new functions in addition to EIP-20: function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external function nonces(address owner) external view returns (uint) function DOMAIN_SEPARATOR() external view returns (bytes32)
The DOMAIN_SEPARATOR should be unique to the contract and chain to prevent replay attacks from other domains.
https://eips.ethereum.org/EIPS/eip-2612
Compliant contracts must implement 3 new functions in addition to EIP-20:
The semantics of which are as follows:
For all addresses owner
, spender
, uint256s value
, deadline
and nonce
, uint8 v
, bytes32 r
and s
, a call to permit(owner, spender, value, deadline, v, r, s)
will set allowance[owner][spender]
to value
, increment nonces[owner]
by 1, and emit a corresponding Approval
event, if and only if the following conditions are met:
The current blocktime is less than or equal to deadline
.
owner
is not the zero address.
nonces[owner]
(before the state update) is equal to nonce
.
r
, s
and v
is a valid secp256k1
signature from owner
of the message:
If any of these conditions are not met, the permit
call must revert.
In TokenFacet.sol, there is no implementation of DOMAIN_SEPARATOR(). The contract will also be deployed on the L2 potentially, which poses a potential replay attack vulnerability.
Manual Review
Properly implement DOMAIN_SEPARATOR()
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.