Part 2

Zaros
PerpetualsDEXFoundrySolidity
70,000 USDC
View results
Submission Details
Severity: medium
Valid

Configuring Fee Recipient Can Revert Wrongfully

Summary

In MarketMakingEngineConfigurationBranch there is a function configureFeeRecipient used to configure the fee recipient and their share. The fee preventing the fee being over the max configurable fee is wrong and can lead to reverts even when lowering the recipient's shares.

Vulnerability Details

In MarketMakingEngineConfigurationBranch there is a function configureFeeRecipient used to configure the fee recipient and their share. There is a check trying to prevent the fee being over the max configurable fee:

if (share > 0) {
UD60x18 totalFeeRecipientsSharesX18 = ud60x18(marketMakingEngineConfiguration.totalFeeRecipientsShares);
if (
totalFeeRecipientsSharesX18.add(ud60x18(share)).gt(
ud60x18(Constants.MAX_CONFIGURABLE_PROTOCOL_FEE_SHARES)
)
) {
revert Errors.FeeRecipientShareExceedsLimit();
}
}

However, this check is wrong as it can revert even when trying to lower a recipient's share.
Let's have the following situation:

  1. Recipient A's fee share is 0.9e18 (this is the maximum).

  2. Owner tries to lower it to 0.7e18.

  3. The check adds 0.9e18 to 0.7e18 and enforces that the result is less than 0.9e18 -> the call reverts.

  4. Recipient A's fee share cannot be lowered.

Impact

Wrong reverted calls and non working max configurable fee logic.

Tools Used

Manual Review

Recommendations

Move this check after modifying the shares of the recipient and revert if the already changed totalFeeRecipientsShares is greater than the allowed maximum.

Updates

Lead Judging Commences

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

MarketMakingEngineConfigurationBranch::configureFeeRecipient can cause DOS when attempting to change share value of an existing address

Support

FAQs

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