# deposit in ConvexStakingWrapper will most certainly revert

ConvexStakingWrapper stores crvRewards (a BaseRewardPool) in convexPool, then calls poolInfo on it, which doesn't exist, so deposit always reverts.

- Payout: Audit contest
- Severity: high
- Program: Concur Finance
- Found by: wuwe1
- Disclosed: 2022-05-24
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-02-concur-findings/issues/33
- Library page: https://bugbountylibrary.com/r/c4%3A2022-02-concur%3AH-09
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:dos

**Target:** Solidity staking wrapper contract (ConvexStakingWrapper)
**Root cause:** convexPool[_pid] is set to Booster.poolInfo(_pid).crvRewards, a BaseRewardPool that does not implement poolInfo; later code calls IRewardStaking(convexPool[_pid]).poolInfo(_pid).lptoken, which reverts.
**Steps:**
1. Read ConvexStakingWrapper.sol L94-99: convexPool[_pid] = IRewardStaking(convexBooster).poolInfo(_pid).crvRewards
2. Note crvRewards is a BaseRewardPool (e.g. 0x8B55...503e) with no poolInfo function
3. Reach L238: IRewardStaking(convexPool[_pid]).poolInfo(_pid).lptoken
4. Call reverts since BaseRewardPool lacks poolInfo; deposit is broken
5. Fix: use IRewardStaking(convexBooster).poolInfo(_pid).lptoken instead
**How found:** Code reading: traced where convexPool[_pid] is assigned, identified the concrete contract type (BaseRewardPool) from the Booster's crvRewards field, and checked its ABI against the poolInfo call made later.
**Insight:** When a contract stores an address from an external protocol's struct field, verify the actual deployed contract type implements every interface method you later call on it; crvRewards vs Booster are different contracts with different ABIs.