# approve() call with incorrect function signature will make any SoftVault deployed with USDT as the underlying token unusable

EnsureApprove calls USDT approve() via standard IERC20 expecting a bool return; USDT returns no data, so SoftVault with USDT reverts on every approve.

- Payout: Contest reward
- Severity: medium
- Program: Blueberry
- Credited: n1punp
- Disclosed: 2023-07-12
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-07-blueberry-judging/issues/135
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-07-blueberry%3AM-13
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:dos

**Target:** SoftVault / EnsureApprove utility contract (Solidity)
**Root cause:** EnsureApprove uses OpenZeppelin IERC20.approve which expects a bool return; USDT's approve returns no data, so Solidity's return-data length check reverts.
**Steps:**
1. Deploy SoftVault with USDT (0xdac17f958d2ee523a2206206994597c13d831ec7) as uToken
2. Call any function path invoking `_ensureApprove(token, spender, amount)`
3. Compiled call `IERC20(token).approve(spender, 0)` reverts with 'function returned an unexpected amount of data' because USDT returns 0 bytes
4. PoC: contract inheriting EnsureApprove exposing `approveMe(token, amount)`; USDC test passes, USDT test reverts
**How found:** Code reading of EnsureApprove.sol noting it uses standard IERC20.approve instead of SafeERC20/safeApprove, combined with knowledge that USDT's approve lacks a bool return; confirmed via Hardhat PoC against mainnet USDT vs USDC.
**Insight:** When a protocol claims USDT/USDC support, grep for raw IERC20.approve/transferFrom calls instead of SafeERC20 wrappers; non-standard-return tokens (USDT) revert on the ABI return-length check even though the selector matches.