# Boost creator can collect all the fees by setting referralFee to 9_000 and give claimants his address as referrer_ address

Boost creator sets referralFee to 9000, making total referral fee equal FEE_DENOMINATOR so 100% of claim fees go to referrer, starving protocol of revenue.

- Payout: Contest reward
- Severity: medium
- Program: Boost Aa Wallet
- Credited: 0rpse
- Disclosed: 2024-06-22
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-06-boost-aa-wallet-judging/issues/158
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-boost-aa-wallet%3AM-2
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity vuln:business-logic vuln:fee-bypass

**Target:** BoostCore.createBoost / claimIncentive fee logic
**Root cause:** createBoost adds user-supplied referralFee to the base 1000 without a maximum, so referralFee can reach FEE_DENOMINATOR (10_000), routing 100% of claim fees to the referrer.
**Steps:**
1. Call `createBoost` with InitPayload where `referralFee: 9_000` (base 1000 added => 10_000).
2. Have claimants call `claimIncentive{value: claimFee}(0, 0, referralAddress, data)` using the creator's address as referrer.
3. Observe referralAddress receives the full claimFee and protocolFeeReceiver balance delta is 0.
**How found:** Code reading of createBoost: noticed referralFee is summed with the base fee and never bounded, so a max input value saturates the fee denominator.
**Exploitation:** Creator deploys a boost with referralFee 9000; every claimant claim sends the entire fee to the creator-controlled referrer address, so the protocol collects zero fees for that boost.
**Insight:** When a fee is computed as base + user-supplied component over a fixed denominator, check whether the user component can reach the denominator; unbounded fee parameters are a recurring revenue-drain pattern in incentive/claim contracts.