Core Contracts

Summary

The FeeCollector contract is designed to collect fees from various protocol operations and later distribute them among stakeholders (e.g., veRAAC holders, burn mechanism, repair fund, and treasury) via the distributeCollectedFees function. Fees are initially collected using the collectFee function, which transfers RAAC tokens from a fee payer to the FeeCollector contract and then records the collected amount by updating internal fee counters.

However, RAAC tokens impose taxes on transfers. The collectFee function, as currently implemented, does not account for these tax deductions. It records the full amount specified by the caller even though the actual tokens received are less than that amount. As a result, when distributeCollectedFees is later invoked, the contract calculates total collected fees based on these inflated figures. Because the FeeCollector’s actual token balance is lower than the recorded fees, the distribution process fails and reverts with an InsufficientBalance error, causing a denial of service for fee distribution.

The provided test suite demonstrates this vulnerability by simulating multiple fee collections where each fee type is collected with a nominal amount, and then verifying that the actual token balance is less than the sum of recorded fees, resulting in a revert during distribution.

Vulnerability Details

How It Begins

1. Token Transfer and Taxation:

   • The RAAC token charges transfer taxes on all transfers (e.g., a percentage of the transferred amount is deducted as tax, which is sent to a burn address or fee collector).

   • In the _update function of the RAAC token, the tax is applied as follows:

     uint256 totalTax = amount.percentMul(baseTax);

     uint256 burnAmount = totalTax * burnTaxRate / baseTax;

     ​

     super._update(from, feeCollector, totalTax - burnAmount);

     super._update(from, address(0), burnAmount);

     super._update(from, to, amount - totalTax);

     This implies that if a sender transfers amount tokens, the recipient (in this case, the FeeCollector) receives only amount - totalTax.

2. Fee Collection Oversight:

   • The collectFee function in FeeCollector transfers tokens from the caller to itself:

     raacToken.safeTransferFrom(msg.sender, address(this), amount);

   • It then calls _updateCollectedFees(amount, feeType) using the full amount provided, not the net amount actually received. This means the internal state over-records the fees by the tax amount.

3. Distribution Failure:

   • Later, when distributeCollectedFees is invoked, the contract calculates the total fees from its internal state:

     uint256 totalFees = collectedFees.protocolFees + collectedFees.lendingFees + ... + collectedFees.nftRoyalties;

   • It then checks:

     if (contractBalance < totalFees) revert InsufficientBalance();

     Because the FeeCollector’s actual RAAC token balance is lower than the recorded total (due to tax deductions on transfer), this check fails and the function reverts.

Test Suite Overview

The provided test suite performs the following steps:

• Setup:

  • Deploys RAAC token, veRAAC token, Treasury, and FeeCollector contracts.

  • Mints RAAC tokens to several addresses and locks tokens for veRAAC eligibility.

  • A designated fee payer is funded with a large RAAC token balance and approves the FeeCollector.

• Fee Collection Simulation:

  • A loop iterates over 8 fee types, and for each fee type, the fee payer calls collectFee with an amount of 1_000_000e18.

  • Due to transfer taxes, the FeeCollector receives less than 1_000_000e18 tokens for each call, but records the full amount.

• Distribution Attempt:

  • The test calculates the total recorded fees and verifies that the FeeCollector's actual RAAC token balance is lower than the recorded fees.

  • Finally, when distributeCollectedFees is called, it is expected to revert with InsufficientBalance().

The test logs confirm that after fee collection, the recorded fee amounts are inflated relative to the actual balance, leading to distribution failure.

Proof of Concept

Scenario Walkthrough

1. Fee Collection:

   • Suppose the fee payer calls collectFee with an amount of 1,000,000e18 tokens for each fee type.

   • Due to a transfer tax (for example, 5%), only 950,000e18 tokens are actually received.

   • The FeeCollector, however, updates its internal fee counters with 1,000,000e18 for each fee type.

2. Fee Distribution:

   • The total recorded fees sum to 8,000,000e18 (assuming 8 fee types).

   • The actual token balance in the FeeCollector is less (e.g., 7,600,000e18 if each fee lost 50,000e18 to taxes).

   • When distributeCollectedFees is called, the check comparing contractBalance with totalFees fails, causing a revert with InsufficientBalance.

Test Suite Example

Below is the test suite provided in the prompt:

Impact

• Failure to Distribute Rewards:
  The FeeCollector records an inflated fee amount because it does not account for the RAAC token transfer taxes. Consequently, when distributing fees, the contract's actual token balance is insufficient, causing the distribution process to revert.

• Economic Imbalance:
  This error disrupts the intended fee distribution mechanism, potentially leading to under-compensation of stakeholders such as veRAAC holders, the repair fund, or the treasury.

• Protocol Instability:
  Frequent reverts in the fee distribution process can undermine trust in the protocol’s reward system, discouraging participation and destabilizing the overall ecosystem.

Tools Used

• Manual Review

• Foundry

Recommendations

To address this vulnerability, the collectFee function must be modified to account for the tax deductions applied during token transfers. This can be achieved by measuring the FeeCollector’s balance before and after the transfer, and recording the net amount received.

Proposed Diff for collectFee Function