# Use of incorrect index leads to incorrect updation of funding rates

Tracer's updateFundingRate() read the just-updated funding index instead of the previous one, so cumulative funding rates reset to the instant value each call, breaking account settlement protocol-wide.

- Payout: Audit contest
- Severity: high
- Program: Tracer
- Found by: 0xRajeev
- Disclosed: 2021-09-16
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-06-tracer-findings/issues/74
- Library page: https://bugbountylibrary.com/r/c4%3A2021-06-tracer%3AH-02
- Tags: area:web3 domain:web3 impact:funds-loss impact:integrity kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Pricing.sol funding rate accounting
**Root cause:** updateFundingRate() computes cumulative funding by adding the instant rate to the value at [currentFundingIndex], but that slot was already overwritten in the same call; it should read [currentFundingIndex-1] to accumulate onto the prior cumulative value.
**Steps:**
1. Read Pricing.sol updateFundingRate() around L155 and L159.
2. Observe cumulative funding/insurance funding computed as instant + storage[currentFundingIndex].
3. Note currentFundingIndex was incremented/updated earlier in the same call, so the previous cumulative value is never read.
4. Result: cumulative rate equals instant rate each call instead of prior cumulative + instant.
5. Fix: use [currentFundingIndex-1] when currentFundingIndex is non-zero.
**How found:** Code review of the funding-rate update path; noticed the cumulative calculation always added the instant rate to zero rather than the prior cumulative, traced to the index used.
**Insight:** In accumulator patterns (funding rates, reward-per-share), verify the read index is the pre-update slot; if the index is bumped before the read, the accumulator silently resets to the delta instead of compounding.