57583 sc low promoter bounty bait and switch via updatevenuerules

Submitted on Oct 27th 2025 at 10:46:11 UTC by @jo13 for Audit Comp | Belongarrow-up-right

  • Report ID: #57583

  • Report Type: Smart Contract

  • Report severity: Low

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

  • Impacts:

    • Theft of unclaimed yield

Description

Brief/Intro

Venues decide how much they reward promoters via the bountyType field inside VenueRules. A dishonest venue can lure promoters by first setting the most generous option (Both) and later—right before customers start paying—downgrade the bounty to a cheaper type or disable it altogether. Because customer payloads are signed without any link to a specific rules version, payToVenue simply reads whatever bounty rules are active when the transaction lands. The venue still receives its money, but the promoter ends up with fewer (or zero) credits.

In short, a venue can pull a bait-and-switch on promoter rewards without breaking its own revenue flow.

Vulnerability Details

The loophole is a combination of two design choices:

  • Signed payloads ignore rule versions Customer signatures do not include a rulesVersion or rulesHash. At execution, checkCustomerInfo compares the computed bountyType against the venue’s current rules, not the rules under which the payload was signed.

  • Venue can change rules at any time

  • payToVenue enforces the current rules

Note the signature omits any rules binding; rules are passed separately and compared at call time.

Attack path: bait-and-switch

1

Attract

Venue sets bountyType = Both (or a higher-paying type) to attract promoters and traffic.

2

Lower terms

Before (or during) customer payments, venue updates rules to a lower-paying type (VisitBounty, SpendBounty) or NoType.

3

Execution

Platform signs new CustomerInfo payloads that match the current rules; payToVenue mints promoter credits per the lowered type (or none if NoType). No revert is needed; venue still gets paid.

4

Payout

distributePromoterPayments pays out based on promoter credits. Since fewer credits were minted, the promoter receives less than the originally advertised amount.

Impact

  • Lost earnings for promoters – Rewards shrink or disappear for visits they rightfully drove.

  • Erosion of trust – Promoters and customers cannot rely on published bounty terms.

  • Minimal risk to venue – The venue’s own revenue is unaffected, so the incentive to cheat is high.

Severity: High (economic fairness + reputational damage).

References

  • Code paths

    • contracts/v2/platform/BelongCheckIn.sol: updateVenueRules, _setVenueRules, payToVenue

    • contracts/v2/utils/SignatureVerifier.sol: checkCustomerInfo

  • Data structures

    • contracts/v2/Structures.sol: VenueRules, CustomerInfo, BountyTypes, PaymentTypes

Proof of Concept

Add this test to /home/jo/audit-comp-belong/test/v2/platform/belong-check-in-bsc-fork.test.ts and run:

LEDGER_ADDRESS=0x0000000000000000000000000000000000000001 PK=0x1000000000000000000000000000000000000000000000000000000000000000001 npx hardhat test --grep "promoter rules bait-and-switch" test/v2/platform/belong-check-in.test.ts

Was this helpful?