# Wrong call order for `setTopPoolIdsWithWeights`, resulting in wrong distribution of rewards

Calling setTopPoolIdsWithWeights before updateAll lets newly-added pools accrue LUM rewards for the entire interval since their last update, inflating emissions.

- Payout: Contest reward
- Severity: high
- Program: Magicsea
- Credited: PUSH0
- Disclosed: 2024-07-15
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2024-06-magicsea-judging/issues/107
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-magicsea%3AH-3
- Tags: domain:web3 impact:funds-loss impact:integrity kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** MasterchefV2 / Voter.setTopPoolIdsWithWeights reward accounting
**Root cause:** updateAll computes elapsed time since each pool's last update using the pool's current weight; if weights are set before updateAll, new pools apply their new weight retroactively over the whole stale interval.
**Steps:**
1. Deploy MasterChef with lumPerSecond=1000, add farms A and B, Alice deposits into farm A.
2. skip(1000) seconds.
3. Call `_voter.setTopPoolIdsWithWeights([0,1],[500,500])` BEFORE `_masterChefV2.updateAll([0,1])`.
4. Call `getPendingRewards(ALICE,[0,1])` -> 499999 LUM accrued immediately.
5. Compare: calling `updateAll` first then `setTopPoolIdsWithWeights` yields 0 pending rewards.
**How found:** Read the documented call-order comment on setTopPoolIdsWithWeights, reasoned that updateAll uses current weight over elapsed time, and hypothesized that setting weights first applies new weights retroactively to stale lastUpdate timestamps; confirmed with a forge test comparing both orders.
**Exploitation:** Admin (or any caller of the documented sequence) sets weights before updating pools; newly added top pools retroactively earn emissions for the entire period since their last update, over-distributing LUM.
**Insight:** When a reward accumulator uses (now - lastUpdate) * currentWeight, any admin parameter change to weight must be preceded by an updateAll on every affected pool; check the documented call order against the actual math rather than trusting the comment.