Core Contracts

Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Submission Details
Severity: low
Valid

Inconsistent Fee Share Allocation Validation in updateFeeType

Summary

The updateFeeType function enforces that the fee share values for a fee type must sum exactly to 10000 (representing 100% in basis points). However, the initial fee type values for fee types 6 (Buy/Sell Swap Tax) and 7 (NFT Royalty Fees) are set such that their shares sum to only 2000. This inconsistency can cause update attempts for these fee types to revert unexpectedly.

Vulnerability Details

In the _initializeFeeTypes() function the contract sets the fee type values as follows for fee types 6 and 7:

  • Fee Type 6 (Buy/Sell Swap Tax):

    • veRAACShare: 500

    • burnShare: 500

    • repairShare: 1000

    • treasuryShare: 0

    • Total = 500 + 500 + 1000 + 0 = 2000

  • Fee Type 7 (NFT Royalty Fees):

    • veRAACShare: 500

    • burnShare: 0

    • repairShare: 1000

    • treasuryShare: 500

    • Total = 500 + 0 + 1000 + 500 = 2000

Later, the updateFeeType function includes the following validation check:

if (newFee.veRAACShare + newFee.burnShare + newFee.repairShare + newFee.treasuryShare != BASIS_POINTS) {
revert InvalidDistributionParams();
}

Here, BASIS_POINTS is defined as 10000. This means that any fee type updated via this function must have its four share values sum exactly to 10000. Since the initial fee types 6 and 7 sum to only 2000, there is an inconsistency between the initially set values and the update requirements.

Impact

This discrepancy may lead to scenarios, where fee managers attempting to update fee types 6 or 7 using values that match the original percentages (totaling 2000) will have their transactions reverted due to the check. This forces fee managers either to change the intended fee splits or work around the validation, potentially resulting in an unintended fee distribution model.

Tools Used

Manual Review

Recommended Mitigation

To resolve this inconsistency, consider one of the following approaches:

  1. Adjust the Validation Check: Modify the validation in updateFeeType to accept fee share sums that match the intended design (e.g., allow a sum of 2000 for fee types 6 and 7). This might involve:

    • Allowing a different expected total for specific fee types.

    • Introducing a normalization step that scales the provided values to the expected range.

  2. Standardize All Fee Shares: Update the initial values for all fee types so that they all sum to 10000. Then, adjust the downstream fee distribution calculations accordingly to maintain the intended percentage splits.

Updates

Lead Judging Commences

inallhonesty Lead Judge 4 months ago
Submission Judgement Published
Validated
Assigned finding tags:

Fee shares for fee type 6 and 7 inside FeeCollector do not total up to the expected 10000 basis points, this leads to update problems, moreover they are 10x the specifications

Support

FAQs

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