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.
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.