Core Contracts

Summary

The _calculateReward function also applies a typeShare factor that further reduces the effective rewards for a gauge. Since the period emission is already determined separately for each gauge type (via _calculateRWAEmission or _calculateRAACEmission), multiplying by the typeShare factor unnecessarily diminishes the reward allocation. This results in significant reward reduction and misalignment with the intended revenue distribution model.

Vulnerability Details

What Went Wrong:
The function calculates:

The intention behind typeShare is to represent the share allocated to a specific gauge type (for example, a 50/50 split between RAAC and RWA). However, since the period emission (periodEmission) is already separated by gauge type using functions like _calculateRWAEmission and _calculateRAACEmission, applying the typeShare factor again results in a double reduction of the rewards for an individual gauge.
Why It Matters:
This extra multiplication reduces the rewards available to gauges far beyond the intended amount. Consequently, the funds meant for gauge rewards may be significantly lower than expected, with excess tokens potentially left unclaimed in the contract.

Impact

Under-Allocation of Rewards:
Gauges receive much lower rewards than intended due to the extra reduction from the typeShare factor.
Locked Funds:
The miscalculation may lead to a substantial amount of reward tokens remaining locked within the contract.
Economic Disruption:
This error undermines the intended revenue-sharing model, potentially eroding stakeholder incentives and affecting the protocol’s long-term economic balance.

Tools Used

Manual Code Review: We scrutinized the reward calculation logic in _calculateReward and determined that the use of the typeShare factor is redundant given the separate period emission calculations for different gauge types.

Recommendations

Reevaluate the Use of typeShare:
If the period emissions are already segregated by gauge type, consider removing the multiplication by typeShare to prevent double penalizing the rewards.
Adjust the Reward Calculation:
Alternatively, revise the reward calculation to ensure that the typeShare factor is applied appropriately—only once—so that the final reward allocation reflects the correct split between gauge types.
Implement Comprehensive Testing:
Create unit and integration tests to verify that reward distributions for each gauge type are accurate and that no funds are unnecessarily reduced or locked.