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 _release uses safeTransferETH, which reverts if the recipient’s receive()/fallback reverts:

  • 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), the referral is 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 referral payee 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 referral payee.

References:

  • Code: contracts/v2/periphery/RoyaltiesReceiverV2.sol (releaseAll, _release)

  • Transfer helper: Solady SafeTransferLib.safeTransferETH

Proof of Concept (PoC)

chevron-rightPoC test (adds a reverting payee that blocks releaseAll for native ETH; ERC20 path still succeeds)hashtag

Add this test to /home/jo/audit-comp-belong/test/v2/tokens/accessToken.test.ts and run:

LEDGER_ADDRESS=0x0000000000000000000000000000000000000001 PK=0x1000000000000000000000000000000000000000000000000000000000000001 npx hardhat test test/v2/tokens/accessToken.test.ts --grep "RoyaltiesReceiverV2: DoS on releaseAll via reverting payee"

Was this helpful?