# PoolTemplate.sol#resume() Wrong implementation of resume() will compensate overmuch redeem amount from index pools

resume() in PoolTemplate divides deduction by index share instead of multiplying, causing over-compensation from index pools and LP fund loss.

- Payout: Audit contest
- Severity: high
- Program: InsureDAO
- Found by: WatchPug
- Disclosed: 2022-03-15
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2022-01-insure-findings/issues/283
- Library page: https://bugbountylibrary.com/r/c4%3A2022-01-insure%3AH-11
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** PoolTemplate.sol resume() index pool compensation logic
**Root cause:** _redeemAmount divides _deductionFromIndex by _shareOfIndex instead of multiplying by the share fraction, inverting the proportional allocation across index pools.
**Steps:**
1. Set totalLiquidity=200000e18, totalCredit=100000e18, debt=10000e18
2. Index Pool 1 credit=20000e18, Pool 2 credit=30000e18
3. Compute _deductionFromIndex = debt*totalCredit*1e6/totalLiquidity = 10000e6*1e18
4. For Pool 1: _shareOfIndex=200000, _redeemAmount=_divCeil(_deductionFromIndex,200000)=25000e18
5. For Pool 2: _shareOfIndex=300000, _redeemAmount≈16666e18
6. Observe _actualDeduction exceeds _deductionFromIndex/1e6, reverting on underflow or over-charging pools
**How found:** Code review of resume() arithmetic; noticed division by _shareOfIndex instead of multiplication, then constructed numeric PoC showing over-compensation.
**Exploitation:** When CSD empty and pools hold only 6000e18 and 4000e18, _actualDeduction reaches 10000e18 while _deductionFromPool=0; Pool 1 pays 6000e18 instead of owed 1000e18, LPs lose funds.
**Insight:** When allocating a total across shares, verify the operation is multiply-by-share not divide-by-share; test with unequal share weights and capped pool balances to expose over-charge and underflow.