# Incorrect assumptions about bptindex may lead to incorrect input amounts in _deposittoau- rapool

Omnipool._depositToAuraPool decrements assetIndex whenever bptIndex>0, ignoring bptIndex<assetIndex, misplacing deposit amounts and risking fund loss.

- Payout: Contest reward
- Severity: high
- Program: Opal
- Credited: zigtur
- Disclosed: 2024-03-30
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_opal_feb2024.pdf#3.2.7
- Library page: https://bugbountylibrary.com/r/cantina%3Aopal_feb2024%3A3.2.7
- Tags: domain:web3 impact:funds-loss kind:contest platform:cantina sev:high tech:evm tech:solidity technique:source-review vuln:business-logic

**Target:** Omnipool.sol _depositToAuraPool (Balancer/Aura pool join)
**Root cause:** The deposit path adjusts assetIndex by -1 whenever bptIndex>0, without checking bptIndex<assetIndex, unlike the withdraw path which does check. This shifts the amount into the wrong slot of userDataAmountsIn.
**Steps:**
1. Set _underlyingAmountIn=123, _pool.assetIndex=1, _pool.bptIndex=2.
2. Call _depositToAuraPool; the `if (_pool.bptIndex > 0)` branch triggers and decrements assetIndex.
3. Observe userDataAmountsIn becomes `[123, 0]` instead of expected `[0, 123]`.
4. JoinPoolRequest executes with amounts in wrong positions, depositing wrong asset amounts.
**How found:** Compared the deposit path against the withdraw path (_withdrawFromAuraPool), which correctly guards with `bptIndex < assetIndex`; noticed the deposit branch lacked that bound and reasoned through an index example.
**Insight:** When one code path adjusts an index for a removed element (BPT), diff it against sibling paths doing the same adjustment; the missing `bptIndex < assetIndex` bound in deposit vs withdraw is the tell.