Why does a token ask for a zero approval before a new allowance?

Some tokens reject a direct change from one nonzero allowance to another. Their supported flow first clears the existing allowance, then creates the new one. This can produce two approval confirmations before the swap.

OpenZeppelin’s ERC-20 utilities explicitly account for zero-first approval compatibility. The underlying ERC-20 standard also discusses setting allowance to zero before changing it as a client-side mitigation for approval-change races.

Verify both requests

The first request should reduce the intended token-spender permission to zero. The second should authorize the new amount for the same intended scope. Check the network and spender on each request rather than assuming a second prompt is harmless because the first was legitimate.

A zero allowance is not a token transfer. It should not move your balance to a “reset address,” and it should not require disclosure of your recovery phrase.

Plan for the intermediate state

If the clearing transaction succeeds and you stop, the old permission is removed. The application may then show approval required, which is expected. If the second approval fails, the allowance can remain zero.

In a wallet flow that batches operations, presentation can differ. Do not demand two hashes when the system explicitly and verifiably executes the sequence atomically.

Refresh the swap quote after the allowance work completes. More time and fees may have passed than in a simple approval, and the original route might no longer meet your minimum output. This compatibility step addresses permission updating; it does not cure a malicious or unsellable token.