Yes, a separately confirmed approval generally remains active after a later swap fails. The approval and swap are independent transactions, so failure of the second does not rewind the first.
Read the sequence by hash
Find the approval receipt and the swap receipt. Confirm the token, owner and spender in the approval. Then read the current allowance rather than relying only on what the original confirmation requested.
ERC-20 defines the stored allowance, while REVERT rolls back the failing execution’s changes. That rollback does not extend to a previously completed transaction.
If a wallet bundled approval and swap within one atomic transaction that fully reverted, the outcome can differ: changes made inside that reverted transaction do not persist. Do not assume the two-step model when there was only one atomic execution.
Decide whether to retain the permission
If you plan a corrected retry using the same verified spender, the allowance may still be useful. If you abandon the trade or no longer trust the application, review revocation.
Do not approve a second unknown spender just because the first swap failed. Determine whether the failure involved permission at all. A deadline or minimum-output rejection can occur despite sufficient allowance.
A failed swap can therefore leave you with fewer native coins from gas and an active permission, even though input tokens stayed in place. Reconcile all three facts separately: token balance, network fee and allowance.
Sources & verification (2)
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 - EIP-140: REVERT instruction
Execution rollback, unused gas and revert reason behavior.
https://eips.ethereum.org/EIPS/eip-140