57671 sc high royaltiesreceiverv2 shares referralshare uses dynamic values which may result in failure to release funds properly
Submitted on Oct 28th 2025 at 02:30:23 UTC by @i0x1982us for Audit Comp | Belong
Report ID: #57671
Report Type: Smart Contract
Report severity: High
Target: https://github.com/immunefi-team/audit-comp-belong/blob/main/contracts/v2/periphery/RoyaltiesReceiverV2.sol
Impacts:
Temporary freezing of funds for at least 24 hour
Description
Brief / Intro
referralShare decreases as referralCode is used more often, resulting in a larger platformShare. This may result in the contract not having enough balance to pay, causing releaseAll / release to fail and rewards to be frozen.
Vulnerability Details
RoyaltiesReceiverV2.shares() is used to calculate the shares corresponding to creator/referral/platform.
creator=factory.royaltiesParameters().amountToCreatorreferral=factory.getReferralRate(creator, referralCode, royaltiesParameters.amountToPlatform)platform=factory.royaltiesParameters().amountToCreator-referral
All three values are variable, especially referral, which gets smaller as usedCode[referralUser][code] increases.
This leads to a problem: if referral is released first, and then shares get smaller, the contract balance reserved/expected for distribution will not match the new shares, potentially causing releases to revert due to insufficient balance.
Example values (from the report):
amountToCreator = 80%
amountToPlatform = 20%
usedToPercentage[2] = 30%
usedToPercentage[3] = 10%
usedCode[referralUser][code] = 2 (referralCode used 2 times)
So:
creator = 80%
referral = 20% * 30% = 6%
platform = 20% - 6% = 14%
Royalties balance = 1000
Note: factory.setFactoryParameters() may also cause similar problems as above by changing referral percentages or other parameters after prior releases.
Impact Details
Rewards are not distributed properly and may be locked until there is enough balance for another reward. Donated rewards may also be partially split and locked.
Proof of Concept
The following test demonstrates the issue. In this example setFactoryParameters() is used instead of modifying usedCode[referralUser][code], but the effect is the same: referral percentage is reduced from 6% to 2%, platform percentage increases from 14% to 18%, and a subsequent distribution reverts with insufficient balance.
Add this to accesstoken.test.ts:
Console output when running the test:
References
Target file: https://github.com/immunefi-team/audit-comp-belong/blob/main/contracts/v2/periphery/RoyaltiesReceiverV2.sol
(End of report)
Was this helpful?