# `GenerateForecastScores` acidentally updates inferences scores

Allora's GenerateForecastScores wrote a forecaster's score into the inference-score store when only one forecaster existed, corrupting worker reward accounting.

- Payout: Contest reward
- Severity: high
- Program: Allora
- Credited: 0x3b
- Disclosed: 2024-06-24
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-06-allora-judging/issues/79
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-allora%3AH-10
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:high tech:go technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** Cosmos SDK emissions module rewards scoring (Go)
**Root cause:** In GenerateForecastScores, the single-forecaster branch calls InsertWorkerInferenceScore instead of InsertWorkerForecastScore, and uses InfererValues[0].Worker as the address, so forecast data lands in the inference score table.
**Steps:**
1. Enter GenerateForecastScores with networkLosses.ForecasterValues of length 1.
2. Observe branch builds Score{Address: InfererValues[0].Worker, Score: ZeroDec()} and calls `keeper.InsertWorkerInferenceScore(ctx, topicId, block, newScore)`.
3. Forecast score is never recorded; inference score for that worker is overwritten with zero.
4. GetWorkersRewardFractions later reads corrupted last-N scores, miscomputing reward fractions.
**How found:** Code reading of the rewards scoring path: auditor noticed the single-forecaster branch in GenerateForecastScores invoked the inference-score insertion function, an obvious mismatch between function intent and keeper call.
**Insight:** In reward/score accounting modules, audit every keeper insert/update call against the table it targets; single-element edge-case branches (len==1) often copy-paste the wrong store and wrong address source.