# ETH can be sold during reinvestment

Notional vault reward-token blocklists checked the wrong ETH sentinel address, letting reinvestment bots sell vault ETH.

- Payout: Contest reward
- Severity: medium
- Program: Notional
- Credited: lemonmon
- Disclosed: 2023-10-09
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-10-notional-judging/issues/74
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-10-notional%3AM-7
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** Leveraged vault reinvestment reward-token validation (Convex/Aura staking mixins)
**Root cause:** _isInvalidRewardToken compares against Deployments.ALT_ETH_ADDRESS (0xEeee...) or only WETH, but trades use Deployments.ETH_ADDRESS (address(0)) or WETH, so ETH is never actually blocked.
**Steps:**
1. Read ConvexStakingMixin._isInvalidRewardToken: blocks TOKEN_1/2, pool, reward pool, booster, ALT_ETH_ADDRESS.
2. Note TradingUtils._executeTrade treats ETH as Deployments.WETH or Deployments.ETH_ADDRESS (address(0)), never ALT_ETH_ADDRESS.
3. Call reinvest with a trade selling ETH (address(0) or WETH) as reward token; blocklist check passes.
4. Same for AuraStakingMixin which blocks WETH but not Deployments.ETH (address(0)).
**How found:** Code-reading: compared the sentinel address used in the blocklist against the ETH address representation actually used in the trading path, spotting the mismatch.
**Exploitation:** A reinvestment bot (buggy or malicious) submits a trade with ETH/WETH as the reward token; the invalid-token guard fails to match, so the trade executes and vault ETH is swapped out.
**Insight:** When a guard blocklists a sentinel address, verify which representation (address(0), WETH, 0xEeee...) the downstream execution path actually uses; mismatched sentinels silently disable the check.