Core Contracts

Summary

In the FeeCollector contract, fee types 6 (Swap Tax) and 7 (NFT Royalties) are initialized with shares that don't sum to 100% (10000 basis points), but the updateFeeType function enforces a 100% total requirement. This creates a permanent lock where these fee types can never be updated.

Vulnerability Details

The FeeCollector contract manages different types of fees (0-7) where each fee type has four share components:

• veRAACShare

• burnShare

• repairShare

• treasuryShare

In _initializeFeeTypes(), fee types 6 and 7 are initialized as:

However, the updateFeeType function has a strict requirement:

This creates a paradox:

1. The initial values sum to 2000 (20%)

2. Any attempt to update must sum to 10000 (100%)

3. There's no way to transition from 20% to 100% as any update attempt will revert

The inconsistency between initialization and update requirements effectively makes these fee types immutable.

PoC

1. Deploy FeeCollector contract

2. Check feeTypes[6] - will show shares totaling 2000

3. Try to update feeType 6 with any new values that sum to 10000

4. Transaction will revert with InvalidDistributionParams()

5. Same applies for feeType 7

Impact

Medium severity. Fee types 6 & 7 are permanently locked to their initial values, preventing any protocol adjustments to swap tax and NFT royalty distributions. This removes administrative flexibility for these important protocol parameters.

Tools Used

Manual review

Recommendations

Either modify initialization values to sum to 100% or adjust the validation check;

1. Option 1: Fix initialization values _initializeFeeTypes

2. Option 2: Remove strict equality check in updateFeeType