Core Contracts

Summary

The issue is that the performance fee portion (20%) calculated in the distributeRevenue function is never used. The computed performanceShare remains locked in the contract with no mechanism to claim or transfer it, resulting in inaccessible funds.

Vulnerability Details

• Unused Performance Fee Calculation:
  Within the distributeRevenue function, the performance fee is calculated as follows:

  uint256 performanceShare = amount * 20 / 100; // 20% performance fee

However, after this calculation, there is no further logic to transfer or utilize performanceShare. It is not sent to any recipient or available for claim, meaning these tokens remain stuck in the contract.
Lack of Handling for Reserved Funds:
The absence of functionality to process or withdraw the performance fee implies that the intended distribution for performance fees is never realized. This could be a critical flaw if those funds are meant to serve as a revenue source or incentive.

Impact

Locked Funds:
The performance fee tokens remain permanently locked in the contract, reducing liquidity and potentially causing significant funds to be inaccessible.

Economic Disruption:
The inability to utilize the performance fees can disrupt the protocol’s revenue-sharing model, undermining trust and potentially affecting the financial incentives designed for stakeholders.

Operational Risks:
Over time, the accumulation of unused funds may lead to imbalances in the contract’s economics and complicate future upgrades or integrations that rely on these funds.

##Tools Used

Manual Code Review: We examined the contract code and identified that the performanceShare is calculated but never transferred or claimed.

##Recommendations

Implement Performance Fee Handling:
Add functionality to transfer or allow the claim of the performanceShare to its intended recipient. This could be through a dedicated withdrawal function or integrated into existing revenue distribution logic.