# `setStartBlock()` doesn't change the block at which already existing pools will start accumulating points

SophonFarming's setStartBlock() updates global startBlock but not existing pools' lastRewardBlock, so pools accrue points from the old start block.

- Payout: Contest reward
- Severity: medium
- Program: Sophon
- Credited: 0xAadi
- Disclosed: 2024-05-13
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-05-sophon-judging/issues/108
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-05-sophon%3AM-3
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** SophonFarming staking/farming contract
**Root cause:** updatePool() derives accrual start from each pool's lastRewardBlock, but setStartBlock() only changes the global startBlock and never syncs existing pools' lastRewardBlock.
**Steps:**
1. Deploy SophonFarming with startBlock=1.
2. Owner calls `setStartBlock(100)`.
3. Alice calls `depositDai(amountToDeposit, 0)` at block 90.
4. Roll to block 99 and call `withdraw(0, type(uint256).max)`.
5. Observe `pendingPoints(0, alice) == 74999999999999999999` despite startBlock 100 not reached.
**How found:** Code reading of updatePool() vs setStartBlock(): noticed lastRewardBlock is the per-pool accrual origin and setStartBlock never touches it, then wrote a Foundry test to confirm points accrue before the new startBlock.
**Insight:** When a global config variable gates reward accrual, check whether per-pool cached state (lastRewardBlock) is re-derived from it; setters that only update the global leave stale per-entity origins.