# Reward index setter skips checkpoint

Admin setters for rate, token, or multiplier that rewrite reward state without checkpointing accrued rewards first

_Area: DeFi accounting and math bugs. Seen in 3 disclosed reports; latest 2025-11-27. Updated 2026-10-24._

## How it works
Reward accounting assumes the parameters that define a unit of reward stay fixed while balances accrue. A setter changes one of those parameters — the reward token, the emission rate, the period end, or the token address used to measure rewards — without first settling what has already accrued. Stored numbers are then reinterpreted under the new parameters, so past accrual and future accrual no longer share a unit. The invariant that breaks: accrued-but-unclaimed rewards must be denominated in the same token, decimals, and rate as the state that will pay them.

## Where it shows up
- Setters that assign a reward token, rate, multiplier, or period end and do not call the checkpoint/update function first.
- Reward measurement via `balanceOf` delta on a token address that is itself mutable (upgrade, registry, oracle).
- Emission rate and period end derived from different constants (e.g. rate uses one duration, `periodFinish` another).
- Stored reward/debt amounts as bare numbers with no token or decimal tag.
- Accounting fields (total collateral, pool balances) pinned to a token address that a setter can replace.

## How to review
For every setter touching reward parameters, check that accrued rewards are checkpointed before the write, and that pending amounts carry their denomination. Verify `rate * period == funded amount` for the actual period used. Where rewards are measured by balance delta, confirm the measured token address cannot change between measurement and accounting, or that the delta is credited to the same ledger it was measured against. The property: after any admin change, previously accrued rewards remain payable in their original unit and total payouts cannot exceed funded amounts.

## Variants seen
- Reward token swapped without clearing pending rewards; old amounts reinterpreted in new decimals/value [E3](https://bugbountylibrary.com/r/c4%3A2021-08-yield%3AH-03.md).
- Token address changed by upgrade; balance-delta claim lands in new token while accounting still references old, orphaning rewards [E1](https://bugbountylibrary.com/r/c4%3A2025-08-flare-fasset%3AM-03.md).
- Rate computed over one duration while period end uses another, over-emitting and draining the pool before late claimers [E2](https://bugbountylibrary.com/r/c4%3A2022-05-velodrome%3AM-15.md).

## Impact and severity
Over-emission drains the reward balance so late users cannot withdraw [E2](https://bugbountylibrary.com/r/c4%3A2022-05-velodrome%3AM-15.md); token swap inflates payouts via decimal mismatch [E3](https://bugbountylibrary.com/r/c4%3A2021-08-yield%3AH-03.md); address change lets one party sweep rewards owed to others [E1](https://bugbountylibrary.com/r/c4%3A2025-08-flare-fasset%3AM-03.md). Severity rises when the setter is callable post-deployment and when accounting and measurement reference different addresses.

## Why fixes fail
Evidence does not show regressed fixes.

## Evidence
- E1: https://bugbountylibrary.com/r/c4%3A2025-08-flare-fasset%3AM-03.md
- E2: https://bugbountylibrary.com/r/c4%3A2022-05-velodrome%3AM-15.md
- E3: https://bugbountylibrary.com/r/c4%3A2021-08-yield%3AH-03.md