Tadle

Tadle
DeFiFoundry
27,750 USDC
View results
Submission Details
Severity: high
Valid

Incorrect Implementation of Referral System Results in Double Rewards for Users

Summary

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.

Vulnerability Details

In the PreMarket:createTaker function, the referralInfo for the msg.sender is retrieved as follows:

ReferralInfo memory referralInfo = systemConfig.getReferralInfo( // ==> referralInfoMap[_msgSender()]
_msgSender()
);

The platform fee is then calculated with this formula:

uint256 platformFee = depositAmount.mulDiv(
platformFeeRate,
Constants.PLATFORM_FEE_DECIMAL_SCALER // 1_000_000
);

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:

uint256 referrerReferralBonus = platformFee.mulDiv(
referralInfo.referrerRate,
Constants.REFERRAL_RATE_DECIMAL_SCALER,
Math.Rounding.Floor
);
  • Authority Referral Bonus:

uint256 authorityReferralBonus = platformFee.mulDiv(
referralInfo.authorityRate,
Constants.REFERRAL_RATE_DECIMAL_SCALER, // 1_000_000
Math.Rounding.Floor
);

The calculated bonuses are then credited to the respective balances of the referrer and msg.sender:

  • Bonus added to the referrer:

tokenManager.addTokenBalance(
TokenBalanceType.ReferralBonus,
referralInfo.referrer, // Adds referrerReferralBonus amount to the referrer’s balance
makerInfo.tokenAddress,
referrerReferralBonus
);
  • Bonus added to the authority (i.e., msg.sender):

tokenManager.addTokenBalance(
TokenBalanceType.ReferralBonus,
_msgSender(),
makerInfo.tokenAddress,
authorityReferralBonus
);

However, the SystemConfig:updateReferrerInfo() function allows the referrer and authority to be set as the same entity:

ReferralInfo storage referralInfo = referralInfoMap[_referrer]; // Gets the storage variable for the referrer
referralInfo.referrer = _referrer; // Sets the referrer to _referrer
referralInfo.referrerRate = _referrerRate;
referralInfo.authorityRate = _authorityRate;

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.

Impact

  • 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.

Tools Used

Manual

Recommendations

Use the correct implementation for referral.

Updates

Lead Judging Commences

0xnevi Lead Judge about 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

finding-SystemConfig-updateReferrerInfo-msgSender

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

Support

FAQs

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