# Leverage Vault on sidechains that support Curve V2 pools is broken

Notional's Leverage Vault on Arbitrum/Optimism misidentifies Curve V2 pools as V1, causing add_liquidity to revert and blocking all deposits.

- Payout: Contest reward
- Severity: medium
- Program: Notional
- Credited: xiaoming90
- Disclosed: 2023-10-09
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-10-notional-judging/issues/88
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-10-notional%3AM-9
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity vuln:business-logic vuln:misconfiguration

**Target:** Leverage Vault contracts on Arbitrum and Optimism
**Root cause:** IS_CURVE_V2 is only set on Ethereum mainnet; on sidechains it defaults to false, so the vault calls Curve V1's add_liquidity without the use_eth parameter, causing a revert when native ETH is sent to a V2 pool expecting WETH.
**Steps:**
1. Deploy Leverage Vault on Arbitrum or Optimism with a Curve V2 pool (e.g., fETH/ETH/xETH).
2. Call deposit function with native ETH.
3. Vault calls `ICurve2TokenPoolV1(CURVE_POOL).add_liquidity{value: msgValue}(amounts, minPoolClaim)` (no use_eth).
4. Curve V2 pool's add_liquidity defaults use_eth to false, expects WETH transfer, and calls WETH.withdraw, which reverts because no WETH was received.
**How found:** Code review of the constructor logic: noticed IS_CURVE_V2 is only set when CHAIN_ID == MAINNET, leaving it false on sidechains; then traced the impact through _joinPoolAndStake and Curve V2's add_liquidity behavior.
**Insight:** When auditing cross-chain deployments, check for chain-specific initialization branches that may leave critical state variables at default values on other chains.