# addFee will stop accumulating fee once rewardToken has reached max supply

RewardDistributor.addFee early-returns once rewardToken hits 1B max supply, skipping fee accounting so staker rewards are permanently locked.

- Payout: Contest reward
- Severity: high
- Program: Golom
- Credited: shenwilly
- Disclosed: 2023-04-05
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-07-golom-findings/issues/320
- Library page: https://bugbountylibrary.com/r/c4%3A2022-07-golom%3AH-05
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** RewardDistributor.addFee (Solidity contract)
**Root cause:** The max-supply guard returns before the fee-accounting lines, so once totalSupply exceeds 1B the function never records feesTrader/feesExchange/epochTotalFee.
**Steps:**
1. Stake GOLOM to earn fee rewards from RewardDistributor.
2. Drive rewardToken.totalSupply() above 1000000000 * 10**18.
3. Traders keep trading; GolomTrader calls `addFee(addr, fee)`.
4. Guard `if (rewardToken.totalSupply() > 1000000000 * 10**18) return;` fires, skipping fee accounting.
5. feesTrader/feesExchange/epochTotalFee never updated; ETH fees stuck in contract, stakers get nothing.
**How found:** Code review of addFee's early-return guard, noticing the return precedes the fee-accounting statements and reasoning about the max-supply boundary condition.
**Exploitation:** No active exploit; the flaw triggers naturally once max supply is reached, permanently locking protocol fees sent by traders and denying stakers their rewards.
**Insight:** When a guard clause early-returns to prevent minting, check whether it also skips state updates (accounting) that must still happen; separate the mint cap from the bookkeeping path.