Standards

ERC20 Permit

ERC20 permit lets a token owner approve an ERC20 allowance with a signature instead of sending an on-chain approve transaction.

Permit lets a user sign an approval off-chain, then someone else submits it on-chain.

ERC20 Permit Explained in Detail

ERC20 permit replaces an on-chain approve() call with a signed message. The signature authorizes a spender, amount, deadline, and token domain. A relayer or spender can then submit the permit on-chain.

Most permit implementations follow EIP-2612 and EIP-712.

Smart contract example

permit(owner, spender, value, deadline, v, r, s);

After a valid permit, allowance(owner, spender) should equal the approved value and the owner's nonce should increase.

ERC20 Permit in Auditing

Permit is a signature-based authorization path. If the digest, nonce, deadline, or signer recovery is wrong, an attacker may create or replay allowances.

Auditors treat permit as both ERC20 approval logic and cryptographic authorization logic.

Red flags in code

  • The signature does not bind spender, value, deadline, token, chain, or owner.

  • Nonce handling allows replay.

  • Expired permits are accepted.

  • Raw ecrecover accepts zero address or malleable signatures.

  • Domain separator handling is wrong across forks or deployments.

How to test or review it

  • Submit a valid permit and check allowance plus nonce increment.

  • Replay the same permit and expect failure.

  • Mutate spender, value, owner, deadline, chain, and token domain.

  • Test expired signatures and malformed signatures.

  • Compare the digest against known EIP-712 expectations.

Sources