ERC-20 Approval Race Condition

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 ERC-20 Permit. The broader front-running attack guide covers the transaction-ordering mechanics behind the race.

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.