Core Contracts

Summary

Currently, FeeCollector contract allows veRAAC holders to claim protocol rewards with the claimRewards function. This function executes the following lines to get the reward amount:

The issue with that computation is that it considers the current voting power snapshot, not historical voting power.

This means new veRAAC holders can indeed come in late and claim rewards as if they had been locking RAAC tokens since the the protocol launch. This will lead to new holders claiming too much rewards, with potentially others veRAAC holders unable to claim their due fees because of insufficient contract balance.

Vulnerability Details

Current implementation is wrong because:

• If User A had 1000 veRAAC for a year and earned 100 RAAC in rewards

• User B comes in now with 1000 veRAAC

• Both users would be able to claim the same amount of rewards, which is unfair to User A who locked RAAC tokens for a longer time

The code is trying to use TimeWeightedAverage but isn't properly integrating it into the reward calculation. The distributionPeriod and TimeWeightedAverage library are imported but not effectively used in the reward distribution logic.

Impact

The impact of this issue is high as it leads to new holder getting too much rewards with potential non-claimable rewards for other veRAAC holders.

Tools Used

Manual review

Recommendations

A proper implementation should calculate rewards based on the time period during which users actually held veRAAC