56881 sc high temporary claim freezing

Submitted on Oct 21st 2025 at 13:41:16 UTC by @shadowHunter for Audit Comp | Belongarrow-up-right

  • Report ID: #56881

  • Report Type: Smart Contract

  • Report severity: High

  • Target: https://github.com/belongnet/checkin-contracts/blob/main/contracts/v2/platform/Factory.sol

  • Impacts:

    • Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

Description

Brief / Intro

A temporary claim freezing vulnerability exists in RoyaltiesReceiverV2 when factory parameters are updated via the Factory. Specifically:

  • If fees are reduced for a beneficiary after partial payouts, subsequent claims by other parties may revert temporarily.

  • This can freeze funds, delaying payouts to platform or referral beneficiaries until the contract state or allocations are reverted back.

Note: This is not due to incorrect factory params but due to past claims which have not yet been claimed. So the issue occurs for genuine inputs.

Vulnerability Details

1

Initial Setup

RoyaltiesReceiverV2 initialized with:

  • Creator: 50%

  • Platform: 50%

  • No referral

Funded with 100 ETH.

2

Step — Partial Release

Creator claims 50 ETH. Platform has not yet claimed.

3

Step — Fee Update via Factory

Factory updates royalties to:

  • Creator: 40%

  • Platform: 60%

Already-paid creator (50 ETH) exceeds new allocation (40 ETH).

4

Step — Platform Claim Fails Temporarily

Platform calls release() which reverts as it demands 60 ETH even though only 50 ETH is left.

Effect: Payout is temporarily frozen to Platform.

Root Cause

  • RoyaltiesReceiverV2 calculates claimable shares dynamically based on current factory parameters.

  • Factory setFactoryParameters() allows reducing a beneficiary’s share after payout.

  • Contract does not account for historical payouts exceeding new allocations, causing temporary reverts.

Impact

  • Funds intended for platform/referral beneficiaries can be temporarily frozen.

  • An attacker or even a benign update can cause griefing by reducing an already-partially-paid beneficiary's allocation, leading to reverts for other beneficiaries until state is reconciled.

Recommendation

  • Make new allocations apply only to future claims (do not retroactively reduce already-paid beneficiaries’ effective allocations).

  • Before updating fees, compute and adjust for historical payouts (e.g., record and preserve already-accrued shares or introduce a pending-claims adjustment mechanism) so that past payouts cannot exceed new allocations.

Proof of Concept

chevron-rightView PoC (Foundry test)hashtag

Output: Release to Platform reverts due to insufficient ETH

Was this helpful?