Handle tokens that require allowance to be reset

Some token implementations reject a nonzero allowance update when the existing allowance is also nonzero. An integration must distinguish that behavior from a wallet rejection or an insufficient native balance.

Observe the existing allowance

Read allowance for the exact owner, token and spender. If it already covers the proposed spend, no update is necessary. Otherwise, determine whether the supported token path requires resetting it to zero. The ERC-20 specification discusses zero-first client behavior when changing an allowance; implementations and application wrappers still need compatibility handling.

For a wallet-driven sequence, submit the zero approval, wait for a successful receipt, verify the new allowance, and only then request the replacement approval. Each request can be rejected or fail independently. Do not display the swap as ready while either approval remains unresolved.

Contract wrappers differ from wallet flows

OpenZeppelin's SafeERC20 documentation includes forceApprove for compatible handling of tokens that require this reset. A helper used inside a contract does not automatically apply to an externally owned user's token allowance: the owner of the approval depends on the actual call context.

After the final approval succeeds, fetch a fresh swap quote. Resetting permission adds latency, and old calldata may no longer reflect a valid route.

Failure cases worth preserving

If the reset succeeds but the replacement is rejected, the resulting allowance is zero. Explain that state without claiming the original permission remains. If the reset transaction times out, reconcile its status before issuing another. Log the two approval hashes separately from the swap hash.

Test this sequence with a token fixture that rejects nonzero-to-nonzero changes. A mock that always returns true will miss the exact compatibility problem the sequence is intended to solve.