DeFi

ERC-20 Approval Race Condition

The ERC-20 approval race condition is a token allowance issue where a spender can use an old allowance before a new allowance change takes effect.

Changing an allowance can leave a window where the spender uses the old approval and then benefits from the new one.

ERC-20 Approval Race Condition Explained in Detail

The ERC-20 approval race condition appears when a token owner changes a spender's allowance from one non-zero value to another. The spender may spend the old allowance before the new approval lands, then use the new allowance afterward.

The risk comes from transaction ordering and allowance semantics.

Transaction example

  1. Current: Alice approved a spender for 100 tokens.

  2. Change: Alice submits a transaction to change approval to 50.

  3. Race: The spender sees the pending transaction and spends 100 first.

  4. After: Alice's approval to 50 executes, leaving more allowance available.

ERC-20 Approval Race Condition in Auditing

Allowance bugs affect routers, vaults, bridges, aggregators, and protocols that manage user approvals. They connect directly to front-running, Permit2, and signature-based approvals such as EIP-712.

Red flags in code

  • Non-zero allowance changed directly to another non-zero value.

  • Protocol asks users for unlimited approvals without clear need.

  • Spender can redirect transferFrom output.

  • Permit or Permit2 integration omits spender, token, amount, nonce, or deadline checks.

  • UI suggests allowance is reduced before the transaction is final.

How to test or review it

  • Test allowance changes under adversarial transaction ordering.

  • Prefer setting allowance to zero before setting a new non-zero value when using classic approve.

  • Review increaseAllowance, decreaseAllowance, permit, and Permit2 flows separately.

  • Verify the spender cannot use approval for a different action than the user intended.

  • Check whether protocol accounting handles fee-on-transfer and non-standard tokens.

Sources