Tadle

Summary

SystemConfig::updateReferrerInfo allows any address (except the referrer) to update referral rates. While there are safeguards to ensure the referrer's rate doesn't fall below the base rate, this still allows anyone else to potentially manipulate of fee distribution.

SystemConfig.sol#L46-L48

Impact

An attacker could set up a separate account to update their own referral rates, potentially allocating up to 70% of the referral fees to themselves as the "authority". This could lead to unfair distribution of referral fees.

Proof of Concept

Let's introduce Alice (attacker) and Bob (maker/offer owner) to the attack scenario.

Before Bob settles an offer, Alice could her referral fee to 100% and get all of the fees for herself whenever Premarkets::_updateReferralBonus executes.

Tools Used

Manual review

Recommended Mitigation Steps

While there's an argument that this will be resolved by enforcing access control on the client, there's no clear way to resolve the issue on the smart contract itself. Here are some ideas though:

• Enforce a maximum referrer rate (e.g., 70% of total rate) to ensure some fees always go to the authority or protocol.

• Implement access control on the updateReferrerInfo function, allowing only authorized addresses (e.g., admin or governance) to update referral rates.

• Consider implementing a timelock or a cooldown period for rate changes to prevent rapid manipulations and so that the offer maker could react to fee updates and inform authorized bodies of the update.