57221 sc high incorrect processing fee calculation causes venue payouts to be misallocated

Submitted on Oct 24th 2025 at 14:06:45 UTC by @Oxv1bh4 for Audit Comp | Belongarrow-up-right

  • Report ID: #57221

  • Report Type: Smart Contract

  • Report severity: High

  • Target: https://github.com/immunefi-team/audit-comp-belong/blob/main/contracts/v2/platform/BelongCheckIn.sol

  • Impacts: Permanent freezing of unclaimed yield

Description

Brief / Intro

The processingFeePercentage is intended to be applied as a fraction of the platformSubsidyPercentage when customers pay with LONG tokens. Due to a logic error, it is instead computed on the total payment amount rather than on the subsidy, causing venues to receive substantially fewer LONG tokens than intended.

Vulnerability Details

In the BelongCheckIn.sol::payToVenue function (link below), when customers pay with LONG tokens:

  • platformSubsidyPercentage is the LONG subsidy the platform adds for the merchant.

  • processingFeePercentage is the portion of that LONG subsidy collected by the platform as a processing fee.

However, the function calculates the processing fee on the total LONG payment amount instead of on the subsidy amount.

Relevant code excerpt:

This subtracts processing fees calculated over the entire customer payment (customerInfo.amount) instead of the platform subsidy portion.

Impact Details

Affected party: Venue / Merchant

Because processingFeePercentage is applied on the total payment rather than on the platform subsidy, venues receive less LONG than intended.

Example:

  • Payment: 1,000 LONG

  • Customer Discount: 5%

  • Platform Subsidy: 3%

  • Processing Fee: 2.5%

  • Correct payout: 979.25 LONG

  • Current payout: 955 LONG

  • Loss per payment: 24.25 LONG

Repeated across many payments, this yields cumulative financial loss and reduced venue revenue.

Severity: High — aligns with permanent freezing of unclaimed yield.

References

  • https://github.com/immunefi-team/audit-comp-belong/blob/main/contracts/v2/platform/BelongCheckIn.sol?utm_source=immunefi#L184

  • https://github.com/belongnet/checkin-contracts/blob/main/docs/guides/BelongCheckinOverview.md?plain=1#L79

Proof of Concept

The reporter updated the test case payToVenue() (both payment) (w/o promoter) in test/v2/platform/belong-check-in.test.ts to demonstrate the difference between the expected escrow-to-venue transfer (where processing fee is applied to the subsidy) and the actual transfer (where processing fee is incorrectly applied to the total amount).

Test snippet:

Run the test with: npm run test


Note: Links and code snippets are preserved from the original report.

Was this helpful?