# Amount distributed can be inaccurate when updating weights 

Backd InflationManager updates one pool's weight without checkpointing others, so stale totalAmmTokenWeight causes over- or under-distribution of token rewards.

- Payout: Contest reward
- Severity: medium
- Program: Backd
- Credited: Picodes
- Disclosed: 2022-07-19
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-05-backd-findings/issues/47
- Library page: https://bugbountylibrary.com/r/c4%3A2022-05-backd%3AM-04
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:reward-distribution

**Target:** InflationManager / Minter reward accounting
**Root cause:** executeAmmTokenWeight changes a pool's weight and checkpoints only that pool, but getAmmRateForToken uses totalAmmTokenWeight; other pools' uncheckpointed accrual is then computed against the new total weight over the whole elapsed period.
**Steps:**
1. Two AMM pools A and B each have ammPoolWeight 100; neither has had poolCheckpoint called for a while.
2. Governance calls `executeAmmTokenWeight` to reduce A's weight to 0; only A is checkpointed.
3. When B is later checkpointed, `getAmmRateForToken` computes B's rate using weight 100 against total weight 100 for the entire period since B's last checkpoint.
4. B accrues too many tokens, exceeding Minter's `totalAvailableToNow` expectation; increasing weights instead under-distributes and users lose claims.
**How found:** Code reading of the weight-update path: noticed only the updated pool is checkpointed while the rate formula depends on the global total weight, so other pools' accrual uses a stale multiplier.
**Exploitation:** Requires governance weight change while pools are uncheckpointed; no attacker capital needed, but anyone can front-run/back-run with `poolCheckpoint` to mitigate. Value leaks as over-distribution blocks later claims or under-distribution shortchanges users.
**Insight:** In accrual/points systems where a rate depends on a global total (MasterChef-style), any multiplier change must mass-checkpoint all participants; check whether the update function touches only the modified pool.