57458 sc medium dos griefing in batch eth payout malicious payee receive can revert and block releaseall for all payees in royaltiesreceiverv2
Submitted on Oct 26th 2025 at 11:41:35 UTC by @koko7 for Audit Comp | Belong: https://immunefi.com/audit-competition/audit-comp-belong
Report ID: #57458
Report Type: Smart Contract
Report severity: Medium
Target: https://github.com/immunefi-team/audit-comp-belong/blob/main/contracts/v2/platform/extensions/ReferralSystemV2.sol
Impacts:
Permanent freezing of unclaimed royalties
Description
Brief / Intro
In RoyaltiesReceiverV2, a payee contract can deliberately revert in its receive() or fallback so that a call to releaseAll(NATIVE_CURRENCY_ADDRESS) reverts. Because the batch loop does not isolate failures per payee, a single reverting payee causes the entire call to fail and no one is paid in that transaction. Funds are not lost (the transaction reverts), but batch ETH payouts can be blocked and operational processes disrupted.
Vulnerability Details
Batch entrypoint iterates payees and releases sequentially:
function releaseAll(address token) external {
RoyaltiesReceivers memory _royaltiesReceivers = royaltiesReceivers;
_release(token, _royaltiesReceivers.creator);
_release(token, _royaltiesReceivers.platform);
if (_royaltiesReceivers.referral != address(0)) {
_release(token, _royaltiesReceivers.referral);
}
}ETH path in
_releaseusessafeTransferETH, which reverts if the recipient’sreceive()/fallbackreverts:
Error handling: there is no error isolation or best‑effort behavior; a single revert aborts the entire batch.
Trust model: among the three payees (
creator,platform,referral), thereferralis typically the least‑trusted external party. A referral contract can intentionally revert to disrupt payouts even if it is technically able to accept ETH.
Impact Details
A single payee can block batch ETH payouts by reverting on receipt of ETH. This is a deliberate griefing vector, not an inability to receive ETH.
The most likely adversary is a malicious
referralpayee seeking to disrupt operations, delay platform revenue, or block creator payouts.Consequences include blocked creator and platform payouts in the same call, and failures in automation that depends on batch releases. Operators may need to fall back to per‑payee releases or switch to an ERC20 payout path.
Severity: Medium (liveness/operational DoS; no direct fund loss) with realistic adversary being the
referralpayee.
References:
Code:
contracts/v2/periphery/RoyaltiesReceiverV2.sol(releaseAll,_release)Transfer helper: Solady
SafeTransferLib.safeTransferETH
Proof of Concept (PoC)
Was this helpful?