# Vault cannot be deployed properly for newer Curve pools

Notional leveraged vault calls lp_token() on newer Curve pools lacking that member; fallback returns zero address, bricking vault deployment.

- Payout: Contest reward
- Severity: medium
- Program: Notional
- Credited: usmannk
- Disclosed: 2023-02-27
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-notional-judging/issues/22
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-notional%3AM-1
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:misconfiguration

**Target:** Curve leveraged vault deployment / CurvePoolMixin
**Root cause:** Deploy code assumes all Curve pools expose lp_token(), but newer pools (e.g. CRV/ETH) only expose token(); the call hits the fallback and returns address(0).
**Steps:**
1. Deploy a leveraged vault targeting a newer Curve pool such as CRV/ETH `0x8301ae4fc9c624d1d396cbdaa1ed877821d7c511`
2. Deployment calls `CURVE_POOL.lp_token()` in CurvePoolMixin.sol#L25
3. Pool has no `lp_token` member; fallback executes and returns zero address
4. LP token address stored as address(0); later `totalSupply` calls fail, vault stuck
**How found:** Code-reading of the deploy path against the actual ABI of newer Curve pools; noticed CRV/ETH pool exposes token() not lp_token().
**Insight:** When integrating external contracts by interface, verify the ABI against the specific deployed version — Curve changed pool interfaces across versions, and a missing member silently hits the fallback returning zero instead of reverting.