Core Contracts

Summary

The FeeCollector contract allows veRAACShare distribution to exceed the specified fee type limits. This breaks core protocol economics by potentially distributing more rewards than intended to veRAACToken holders.

The issue occurs in the fee distribution mechanism where the FeeCollector calculates and distributes rewards to veRAACToken holders. The contract tracks total distributed amounts but fails to properly enforce per-fee-type distribution limits. When fees are collected and distributed, the veRAACShare portion can accumulate beyond the intended percentage cap for each fee type.

The FeeCollector's core promise is maintaining strict fee distribution ratios (80/20 split for protocol fees between veRAACToken holders and treasury). The code assumed the share calculations in _calculateDistribution() would naturally enforce limits. However, the accumulation of totalDistributed across multiple fee types creates an accounting disconnect.

Vulnerability Details

The FeeCollector's core purpose's managing protocol fees across eight distinct revenue streams, from lending fees to NFT royalties. Each stream has carefully designed distribution ratios, like the 80/20 split between veRAACToken holders and treasury for protocol fees. /FeeCollector.sol#_processDistributions() function

The contract tracks total distributions through totalDistributed, where totalDistributed accumulates without validating against the fee type's configured veRAACShare limit but fails to enforce per-fee-type limits during the actual distribution process. This creates a disconnect between intended and actual token flow. like a profit-sharing system where employees somehow receive 120% of the allocated bonus pool.

When the protocol collects 1000 RAAC in protocol fees, veRAACToken holders should receive 800 RAAC (80%). However, the current implementation allows their share to exceed this limit over time. The _processDistributions() function simply accumulates distributions without checking against the configured veRAACShare percentages.

This impacts the protocol's economic design in concrete ways. The treasury, meant to receive 20% of protocol fees for development, receives less than intended. The repair fund, crucial for protocol safety, accumulates reserves below target levels. Meanwhile, veRAACToken holders receive rewards beyond their designated share, distorting incentive mechanisms.

Impact

This allows accumulated distributions to veRAACToken holders to exceed their designated share percentage over time. The implementation shows careful thought in calculating shares.

The implementation shows careful thought in calculating shares: #L450

But here's the part while the calculations look right, the accumulation in _processDistributions() lacks bounds:

Recommendations

The vulnerability is in the interaction between _processDistributions() and _calculateDistribution().

This ensures that shares[0] (veRAACToken holder share) never exceeds the configured limit for each fee type before the actual distribution occurs. The validation works in conjunction with the weighted calculations from _calculateDistribution() to maintain the protocol's economic constraints.