# TOFT leverageDown always fails if TOFT is a wrapper for native tokens

TOFT sendForLeverage on native-token-backed wrappers reverts at leverageDown because erc20 is address(0), permanently burning user TOFT and gas.

- Payout: Contest reward
- Severity: high
- Program: Tapioca DAO
- Credited: windhustler
- Disclosed: 2023-11-16
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-07-tapioca-findings/issues/904
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-46
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** BaseTOFT leverage module (sendForLeverage/leverageDown) on TapiocaOFT/mTapiocaOFT
**Root cause:** When the TOFT wraps the native token, erc20 is address(0), but sendForLeverage is still callable; leverageDown then calls IERC20(address(0)).approve, which reverts.
**Steps:**
1. Deploy/observe TapiocaOFT or mTapiocaOFT with erc20 == address(0) (native underlying).
2. Call `sendForLeverage(...)` on BaseTOFT with a leverage payload.
3. Message is delivered and `leverageDown` executes `IERC20(erc20).approve(externalData.swapper, amount)` with erc20=address(0).
4. Call reverts; failed message is stored and retrying the same payload reverts identically, so TOFT stays burned on the sending side.
**How found:** Code reading: noticed erc20 can be address(0) for native-token wrappers, then traced sendForLeverage -> leverageDown to the unconditional IERC20(erc20).approve call.
**Exploitation:** Any user invoking sendForLeverage on a native-backed TOFT loses gas, airdropped amount, and burned TOFT; retries of the failed message always revert, making the loss permanent.
**Insight:** When a contract supports a sentinel address (address(0)) to mean native asset, audit every downstream path that assumes an ERC20 interface; entrypoints gated only on the ERC20 branch leave the native branch reachable and reverting after funds are already burned.