EIP-2612 Explained in Detail
EIP-2612 adds permit, nonces, and DOMAIN_SEPARATOR to ERC20 tokens. It lets an owner approve an allowance by signing structured data instead of sending an approval transaction.
The standard is small, but implementation details matter. The signature must be bound to the right token, chain, owner, spender, amount, deadline, and nonce.
Smart contract example
function permit(
address owner,
address spender,
uint256 value,
uint256 deadline,
uint8 v,
bytes32 r,
bytes32 s
) external;
This function changes allowance if the signature and nonce are valid.
EIP-2612 in Auditing
EIP-2612 bugs usually become unauthorized allowance bugs. An attacker who can replay or forge a permit can spend tokens through transferFrom.
Auditors review EIP-2612 together with signature replay, EIP-712, and ecrecover.
Red flags in code
-
The typehash does not match the standard.
-
DOMAIN_SEPARATORomits chain ID or token address. -
Nonces are not incremented exactly once per successful permit.
-
Expired permits are accepted.
-
Signature malleability is not handled by an audited ECDSA library.
How to test or review it
-
Use valid EIP-712 signatures and known bad variants.
-
Confirm replay fails after one successful permit.
-
Test wrong signer, wrong spender, wrong amount, wrong chain, and expired deadline.
-
Verify the nonce changes only on successful permit.
-
Check behavior across proxy deployments and chain forks.