# Gamer rewards are reduced due to fund pulls before accrual of rewards

Derby vault rebalancing pulls funds from yield protocols before gamer rewards are computed, shrinking savedTotalUnderlying and underpaying gamers.

- Payout: Contest reward
- Severity: medium
- Program: Derby
- Credited: Auditwolf
- Disclosed: 2022-10-17
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-01-derby-judging/issues/312
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-01-derby%3AM-13
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:reward-distribution

**Target:** Derby yield-optimiser MainVault/Vault rebalancing accounting
**Root cause:** savedTotalUnderlying is cached at rebalance start but can be reduced by fund pulls in rebalanceXChain before gamer rewards are calculated in Vault.rebalance, so rewards use a smaller base than the funds that actually generated yield.
**Steps:**
1. MainVault.pushTotalUnderlyingToController calls setTotalUnderlying, caching savedTotalUnderlying at rebalance start
2. XChainController sends new allocations; MainVault.rebalanceXChain pulls funds from protocols if vault balance is insufficient, reducing savedTotalUnderlying
3. Vault.rebalance is called after tokens are sent/received, computing gamer rewards from the reduced savedTotalUnderlying
4. Rewards are underpaid relative to yield generated on the original balance; worst case triggers negative fee penalty in Game.sol
**How found:** Code reading of the rebalancing flow: noticed savedTotalUnderlying is cached early but mutated by fund pulls before reward accrual, and that rewards are computed on post-rebalance balances that never generated yield.
**Insight:** In multi-step cross-chain rebalancing, check whether the accounting snapshot used for reward/yield accrual is mutated by later settlement steps; reward bases should be frozen at the moment funds were deployed, not recomputed after transfers.