# supplyNativeToken will strand ETH in contract if called after ACTION_DEFER_LIQUIDITY_CHECK

Ironbank TxBuilderExtension.supplyNativeToken reads msg.value after deferLiquidityCheck creates a new context where msg.value is 0, stranding user ETH in the contract.

- Payout: Contest reward
- Severity: high
- Program: Ironbank
- Credited: 0x52
- Disclosed: 2023-05-24
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-05-ironbank-judging/issues/361
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-05-ironbank%3AH-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:chained technique:source-review vuln:accounting-error vuln:business-logic

**Target:** TxBuilderExtension.supplyNativeToken / deferLiquidityCheck callback
**Root cause:** supplyNativeToken uses context-sensitive msg.value to size the WETH deposit; after ACTION_DEFER_LIQUIDITY_CHECK the IronBank callback runs in a new context where msg.value is 0, so no ETH is deposited and it remains in the contract.
**Steps:**
1. Call `execute` with ACTION_DEFER_LIQUIDITY_CHECK first, which calls `ironBank.deferLiquidityCheck` and triggers `onDeferredLiquidityCheck` in a fresh context.
2. Within that callback, execute ACTION_SUPPLY_NATIVE_TOKEN, invoking `supplyNativeToken`.
3. `WethInterface(weth).deposit{value: msg.value}()` deposits 0 because msg.value is 0 in the new context.
4. `ironBank.supply(address(this), user, weth, 0)` supplies nothing; the originally sent ETH stays in TxBuilderExtension.
**How found:** Code reading of supplyNativeToken's use of msg.value combined with tracing the execution path through deferLiquidityCheck's external callback creating a new context.
**Exploitation:** User submits a batched tx with defer-liquidity-check before a native-token supply; their ETH is never converted/supplied, leaving collateral undeposited and ETH stuck in the contract (recoverable only by owner, and stealable per related report #368).
**Escalation:** Chained with uninitialized-owner issue (#368) to make stranded ETH stealable; also causes unfair liquidation due to missing collateral.
**Insight:** When a contract re-enters itself via an external callback (deferLiquidityCheck pattern), msg.value does not propagate to the new context; cache msg.value in storage at the entrypoint for any payable multi-action batcher.