# math miscalculation artificially deflates scores

In Allora's GetConsensusScore, zero consensusLosses are replaced with epsilon only in the numerator, not the denominator, artificially deflating scores.

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

**Target:** emissions module rewards calculation (Go)
**Root cause:** When consensusLosses[i] is zero, it is set to epsilon inside the distance loop, but consensusNorm was already computed using the original zero, so numerator and denominator use inconsistent values.
**Steps:**
1. Call GetConsensusScore with reputerLosses and consensusLosses where at least one consensusLosses[i] == 0.
2. consensusNorm is computed as sqrt(sum(consensusLosses^2)) before the zero-to-epsilon replacement.
3. In the distance loop, consensusLosses[i] is replaced with epsilon, changing the numerator to sqrt(sum((rLoss - epsilon)^2)).
4. distance is divided by consensusNorm, yielding a larger ratio than intended.
5. Final score = 1 / (ratio + tolerance) is therefore smaller (deflated).
**How found:** Manual code review of the score calculation formula, noticing that the zero-to-epsilon replacement occurs after consensusNorm is computed and only affects the numerator.
**Insight:** When a normalization factor is computed from an array that is later mutated, check whether the mutation should also apply to the already-computed factor; inconsistent epsilon substitution between numerator and denominator skews ratios.