Core Contracts

The `claimRewards(address user)` function allows a user to claim their pending rewards. After computing the pending reward, the function resets the user' in `FeeCollector.sol` reward checkpoint by setting `userRewards[user]` to `totalDistributed` before transferring the rewards. This approach will lead to inaccuracies in reward tracking over

In this function, the following steps are performed:

​

Validation:

The function first validates the user address and ensures that there are pending rewards by calling `_calculatePendingRewards(user)`. If no rewards are pending, it reverts.

​

Resetting Reward Checkpoint:

The function then resets the user's reward checkpoint by assigning:

​

userRewards[user] = totalDistributed;

​

This line updates the user's recorded rewards to the current value of `totalDistributed`.

​

Reward Transfer:

After updating the checkpoint, the function transfers the pending reward to the user via:

​

raacToken.safeTransfer(user, pendingReward);

Finally, it emits a `RewardClaimed` event and returns the pending reward.

​

​

Consider a scenario where a user accumulates rewards over multiple periods:

​

Initial Claim:

The user accrues pending rewards and calls `claimRewards()`. The function calculates the pending reward, resets the reward checkpoint to `totalDistributed`, and transfers the reward.

​

Subsequent Claim:

In a later period, if the mechanism for updating userRewards does not properly account for the rewards already claimed, the pending rewards computed in the subsequent call may be incorrect. This behavior could be observed via unit tests where successive calls to `claimRewards()` produce cumulative rewards that do not align with the expected total, demonstrating the flaw in the reward checkpoint update mechanism.

Reward Accounting Accuracy:

The manner in which the reward checkpoint is reset could lead to discrepancies when tracking cumulative rewards for each user, potentially causing miscalculations in subsequent reward claims.

​

User Incentive Misalignment:

If the checkpoint does not accurately reflect the total rewards claimed over time, users may either overclaim or underclaim rewards, disrupting the fairness of the reward distribution mechanism.

​

System Integrity:

Inaccurate reward tracking could affect the overall economics of the protocol by misallocating incentive tokens, which may eventually undermine user trust.

Review Reward Checkpoint Update:

Verify that the logic used to update `userRewards[user]` accurately reflects the incremental reward accumulation for each user. If the design intent is to accumulate rewards over time, consider modifying the update to increment rather than overwrite.

​

Implement Comprehensive Testing:

Develop unit tests that simulate multiple reward claims over time. Ensure that the cumulative rewards tracked for each user are consistent with the rewards they should receive.

​

Clarify Variable Semantics:

Document the purpose of totalDistributed and how it relates to individual user reward tracking. Clear documentation can prevent ambiguity and guide proper implementation of the reward accounting logic.

​

Consider Alternative Approaches:

If necessary, refactor the reward claiming logic to decouple global reward tracking from user-specific checkpoints. This could involve maintaining a separate variable that tracks the cumulative rewards claimed by each user and ensuring that each claim accurately reflects the incremental rewards earned.

​

By addressing these recommendations, the protocol can ensure accurate reward distribution and maintain user trust in the incentive mechanism.