57872 sc low processing fee computed on full long amount instead of subsidy in paytovenue underpaying venues and enabling long payment dos under misconfiguration

Submitted on Oct 29th 2025 at 10:24:40 UTC by @Rhaydden for Audit Comp | Belongarrow-up-right

  • Report ID: #57872

  • Report Type: Smart Contract

  • Report severity: Low

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

Description

Issue description

In the LONG payment branch of BelongCheckIn.payToVenue, the processingFeePercentage is applied to the full pre-discount customerInfo.amount instead of to the platform subsidy.

This is not in line with the doc that says “processingFeePercentage: portion of LONG subsidy collected by the platform as processing fee.” Therefore, processingFee should be a percentage of grossSubsidy, not a percentage of the full amount.

Reference in code: https://github.com/immunefi-team/audit-comp-belong//blob/a17f775dcc4c125704ce85d4e18b744daece65af/contracts/v2/platform/BelongCheckIn.sol#L471-L485

Relevant snippet (original behavior):

// contracts/v2/platform/BelongCheckIn.sol
// ...
// platform subsidy - processing fee
uint256 subsidyMinusFees =
    _storage.fees.platformSubsidyPercentage.calculateRate(customerInfo.amount)
    - _storage.fees.processingFeePercentage.calculateRate(customerInfo.amount);
_storage.contracts.escrow
    .distributeLONGDiscount(customerInfo.venueToPayFor, address(this), subsidyMinusFees);

// customer paid amount - longCustomerDiscountPercentage (3%)
uint256 longFromCustomer =
    customerInfo.amount - _storage.fees.longCustomerDiscountPercentage.calculateRate(customerInfo.amount);
// ...
uint256 longAmount = subsidyMinusFees + longFromCustomer;
// ...
  • With defaults (3% subsidy, 2.5% processing, 3% discount):

    • Buggy: processingFee = 2.5% × full_LONG

    • Correct: processingFee = 2.5% × (3% × full_LONG)

Result: the venue is underpaid. The missing LONG is not transferred to anyone and it remains in the venue’s escrowed longDeposits. If processingFeePercentage > platformSubsidyPercentage, the subtraction underflows and LONG payments revert, preventing redemption of escrow subsidy amounts.

circle-exclamation

Apply processing fee to the subsidy, not the full amount.

Suggested change:

Proof of Concept

The following PoC demonstrates that processingFeePercentage is applied to the full LONG amount instead of to the subsidy amount during LONG payments, causing venue underpayment.

Save as poc-processing-fee-on-subsidy.test.ts and run with: pnpm test test/v2/platform/poc-processing-fee-on-subsidy.test.ts -s

TypeScript PoC:

chevron-rightLogs from PoC (5 LONG payment; default fees)hashtag

As seen in the logs:

  • Venue receives 4.875 LONG (buggy).

  • Correct would be 4.99625 LONG.

  • Shortfall is 0.12125 LONG (≈ 2.42% of full amount), matching “processing on full minus processing on subsidy.”

Was this helpful?