A successful approval only proves that a particular permission update executed. The next swap can still need a different spender or a larger amount, or another operation may have consumed the allowance.
Compare the complete allowance identity
Match four items: network, token contract, token owner and spender. Then read the current remaining amount. ERC-20 defines allowance for a specific owner-spender pair; a permission for another token or spender does not substitute.
For an exact-output quote, review the maximum input the transaction may use rather than comparing only with an earlier expected-input estimate. A larger permitted input can require a larger cap.
Check timing and units
Verify the approval receipt confirmed successfully. A pending approval or a wallet’s optimistic display is not equivalent to confirmed permission. If the numbers look wildly different, compare human units with the token’s decimals rather than treating a raw integer as a whole-token amount.
Look for an intervening swap or revocation. Current allowance matters more than the amount originally approved.
If the flow uses Permit2, there can also be a token-level permission to Permit2 and a separate spender permission inside that system. Uniswap’s Permit2 overview describes those layers; checking only one may miss the constraint.
Once the mismatch is understood, approve only the intended token and verified spender for an amount you accept. If everything matches and estimation still fails, retain the error for support rather than repeatedly escalating the cap to unlimited.
Sources & verification (3)
Source-check date is recorded in the article details. URLs are provided for manual verification. Use Copy to keep this page open.
- ERC-20: Token Standard
Allowance, spender, transferFrom, metadata and approval event semantics.
https://eips.ethereum.org/EIPS/eip-20 - Permit2 Overview
Token approval layer and distinction between SignatureTransfer and AllowanceTransfer.
https://developers.uniswap.org/docs/protocols/permit2/overview - ERC-6093: Custom errors for commonly-used tokens
Distinct structured errors for insufficient balance and allowance.
https://eips.ethereum.org/EIPS/eip-6093