# Did Not Approve To Zero First Causing Certain Token Transfer To Fail

Connext's Aave portal repayment and swap paths call safeIncreaseAllowance/safeApprove without zeroing first, so USDT-style tokens revert and transfers get stuck.

- Payout: Audit contest
- Severity: medium
- Program: Connext
- Found by: xiaoming90
- Disclosed: 2022-10-17
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-06-connext-findings/issues/154
- Library page: https://bugbountylibrary.com/r/c4%3A2022-06-connext%3AM-05
- Tags: area:web3 domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:dos

**Target:** Solidity bridge contracts (BridgeFacet, AssetLogic)
**Root cause:** safeIncreaseAllowance and safeApprove are called on tokens whose approve() reverts when the existing allowance is non-zero (e.g. USDT), without first resetting allowance to zero.
**Steps:**
1. Identify tokens like USDT whose approve() reverts if current allowance != 0.
2. In `_reconcileProcessPortal`, `SafeERC20.safeIncreaseAllowance(IERC20(adopted), s.aavePool, totalRepayAmount)` is called; if a residual allowance remains after backUnbacked, the call reverts.
3. In `_swapAssetOut`, `SafeERC20.safeApprove(IERC20(_assetIn), address(pool), _amountIn)` is called without zeroing prior allowance, reverting for such tokens.
4. Observe that both paths run during Aave portal repayment, so the revert blocks the fast-transfer repayment flow.
**How found:** Code review of allowance handling in repayment/swap paths, noting the USDT approve-nonzero-revert special case and residual allowance after backUnbacked.
**Insight:** When integrating arbitrary ERC20s, remember USDT reverts on approve to non-zero even via safeIncreaseAllowance; always reset allowance to zero before setting a new value.