Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.
The ERC-20 approve race occurs when an owner replaces one non-zero allowance with another while the approved spender can still use the old allowance. Transaction ordering can let the spender consume the old amount before the replacement confirms, then consume the new amount afterward.
ERC-20 defines approve(spender, value) as an overwrite. The ERC-20 specification also warns user interfaces to set an allowance to zero before setting another value.
Suppose Alice has approved a spender for 100 tokens and submits approve(spender, 50). The spender sees the pending transaction and spends 100 first. Alice's transaction then sets the allowance to 50, which the spender can also use. Alice intended a remaining limit of 50 but can lose 150 across the two transactions.
The spender must already be authorized, observe or otherwise anticipate the change, and obtain favorable ordering. This is not a way for an arbitrary address to steal an allowance.
Find every approval update made by contracts and every interface that asks users to replace a live allowance. Distinguish an exact replacement from a delta. Review transaction batching, allowance revocation, failure handling, and whether the spender can pull funds between approval operations.
Test adversarial ordering: spend before decrease, spend between zero and reset, duplicate submitted transactions, and partial spending before an update. Include tokens that require a zero-first approval and tokens that return no Boolean value.
SafeERC20 helps normalize transfer return behavior and provides allowance helpers, as documented in the OpenZeppelin ERC-20 API. It does not make two separately confirmed transactions atomic.
If a non-zero allowance must be replaced, first revoke it and wait for that transaction to confirm. Then inspect and reconcile any spending that landed before revocation before deciding whether to grant a new amount. A confirmed zero prevents further spending under the old grant, but it cannot undo an earlier spend; blindly granting 50 after the spender used the old 100 still permits a cumulative 150.
For contract integrations, prefer a single transaction that grants only the required authority and consumes it in the intended operation, where the token and wallet support that flow. Delta-based increases and decreases express changes more clearly, but a decrease can conflict with a concurrent spend and may revert instead of applying.
EIP-2612 removes the separate on-chain approval transaction by accepting a signed permit with a deadline and nonce. It prevents signature replay, but it is not a general cure for allowance replacement: the EIP-2612 security section states that the ERC-20 approval race still applies.
Repository analysis can identify direct non-zero approval replacements and missing zero-first flows. It cannot determine pending-transaction ordering, a wallet's signing behavior, or all token-specific allowance semantics from an interface alone.
Does setting an allowance to zero eliminate the race?
No. Confirmation stops further use of the old grant, but the owner must account for spending that landed before revocation before issuing any replacement allowance.
Are unlimited approvals the same issue?
No. An unlimited approval creates persistent exposure to a compromised or malicious spender; the overwrite race concerns changing a live allowance.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Understand how Ether can reach a contract without its receive logic and how to review exact-balance assumptions safely.
Learn how adversarial gas consumption can block progress, waste sponsored gas, or break calls, plus practical review, testing, and mitigation guidance.
Learn when block timestamps are safe for coarse scheduling, when they create exploitable assumptions, and how to test timing boundaries across EVM networks.