Core Contracts
Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Previous Next
Submission Details
Severity: medium
Invalid

Fee Type Misclassification Enables Gaming of Distribution Ratios

chainsentryaudits

Summary and Impact

The FeeCollector contract's collectFee() function allows any user to arbitrarily classify fees under any category, leading to incorrect fee distributions and potential manipulation of protocol metrics. This undermines the protocol's core financial accounting and distribution mechanisms.

According to the documentation, RAAC is designed to "bring real estate on-chain and deeply integrate it within on-chain finance rails for seamless accessibility, composability, stability and capital efficiency." The fee collection system is crucial for this stability, as it funds essential protocol operations through carefully balanced distribution ratios.

The current implementation violates this principle by allowing fees to be misclassified, directly impacting:

  • Protocol revenue reporting accuracy

  • Distribution ratios between veRACC holders, treasury, and repair fund

  • Financial metrics used for protocol governance decisions

Vulnerability Details

The vulnerability exists in the FeeCollector's open fee classification system:

function collectFee(uint256 amount, uint8 feeType) external override nonReentrant whenNotPaused returns (bool) {
if (amount == 0 || amount > MAX_FEE_AMOUNT) revert InvalidFeeAmount();
if (feeType > 7) revert InvalidFeeType();
// Transfer tokens from sender
raacToken.safeTransferFrom(msg.sender, address(this), amount);
// Update collected fees
_updateCollectedFees(amount, feeType);
emit FeeCollected(feeType, amount);
return true;
}

The only validation performed is feeType > 7, allowing any user to classify fees under categories meant for specific protocol operations. This contradicts the protocol's documented fee types:

// Protocol Fees: 80% to veRAAC holders, 20% to treasury
feeTypes[0] = FeeType({
veRAACShare: 8000, // 80%
burnShare: 0,
repairShare: 0,
treasuryShare: 2000 // 20%
});
​
// Insurance Fees: 50% veRACC, 20% repair, 30% treasury
feeTypes[3] = FeeType({
veRAACShare: 5000, // 50%
burnShare: 0,
repairShare: 2000, // 20%
treasuryShare: 3000 // 30%
});

This vulnerability can be systematically exploited to:

  1. Direct more funds to repair fund by classifying fees as insurance fees

  2. Skew protocol metrics by inflating specific fee categories

  3. Manipulate governance decisions based on fee type metrics

Tools Used

  • Manual Review

Recommendations

Implement proper access control for fee classification

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 month ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.