The PreMarket:createTaker
function is responsible for calculating and distributing platform fees between a referring entity (referrer
) and the current user (msg.sender
). The function relies on referral information retrieved from the systemConfig
contract to determine how these fees are divided. However, due to the design of the SystemConfig:updateReferrerInfo()
function, it is possible to set both the referrer
and authority
(i.e., the current user) to the same entity. This creates a scenario where the intended distribution of rewards is compromised, allowing a user to manipulate the system and receive a double allocation of fees at the expense of the genuine referrer.
In the PreMarket:createTaker
function, the referralInfo
for the msg.sender
is retrieved as follows:
The platform fee is then calculated with this formula:
Next, in the _updateReferralBonus()
function, this platformFee
is distributed between the referrer
(the entity that referred msg.sender
) and the current user (msg.sender
) as referrerReferralBonus
and authorityReferralBonus
, using the following formulas:
Referrer Referral Bonus:
Authority Referral Bonus:
The calculated bonuses are then credited to the respective balances of the referrer
and msg.sender
:
Bonus added to the referrer
:
Bonus added to the authority
(i.e., msg.sender
):
However, the SystemConfig:updateReferrerInfo()
function allows the referrer
and authority
to be set as the same entity:
This creates a situation where, during the distribution of the platformFee
in PreMarket:createTaker
, both the referrer
and authority
are the same entity. As a result, the genuine referrer is bypassed, leading to a loss for them, while the user (msg.sender
) unfairly receives a double fee.
Double-dip on rewards: By setting themselves as both the referrer
and authority
, a user can unjustly receive both portions of the platform fee, leading to an unfair distribution of rewards.
Cause financial loss to legitimate referrers: The genuine referrers who should be receiving a portion of the platform fee are effectively bypassed, resulting in a loss of their rightful earnings.
Undermine trust in the platform: The ability to manipulate the referral system in this way could lead to a loss of confidence among users, particularly those who rely on the referral bonuses as a source of income or incentive.
Manual
Use the correct implementation for referral.
Valid high severity. There are two impacts here due to the wrong setting of the `refferalInfoMap` mapping. 1. Wrong refferal info is always set, so the refferal will always be delegated to the refferer address instead of the caller 2. Anybody can arbitrarily change the referrer and referrer rate of any user, resulting in gaming of the refferal system I prefer #1500 description the most, be cause it seems to be the only issue although without a poc to fully describe all of the possible impacts
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.