# Adding genuine BribeRewarder contract instances to a pool in order to incentivize users can be DOSed

Permissionless BribeRewarder registration with worthless tokens lets an attacker fill the 5-bribe-per-pool cap across 100 periods, blocking genuine bribes.

- Payout: Contest reward
- Severity: medium
- Program: Magicsea
- Credited: 0xAnmol
- Disclosed: 2024-07-15
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-06-magicsea-judging/issues/190
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-magicsea%3AM-3
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic vuln:dos vuln:governance

**Target:** Voter.sol / BribeRewarder.sol bribe registration
**Root cause:** onRegister() enforces MAX_BRIBES_PER_POOL=5 per pool per period but registration is permissionless with no reward-token whitelist or minimum value, so junk rewarders can occupy all slots.
**Steps:**
1. Deploy an ERC20 with no value and mint arbitrary supply to attacker.
2. Call `rewarderFactory.createBribeRewarder(customNoValueToken, pool)` five times.
3. For each rewarder call `approve` then `fundAndBribe(1, 100, 100e18)` to register across 100 voting periods.
4. Genuine rewarder calling `fundAndBribe(2, 6, 20000e6)` reverts with `too much bribes`.
**How found:** Code review of onRegister() noting the MAX_BRIBES_PER_POOL cap combined with permissionless createBribeRewarder/fundAndBribe and absence of token whitelist or minimum reward amount; confirmed with a Foundry test.
**Exploitation:** Attacker registers 5 worthless-token BribeRewarders per pool spanning up to 100 periods (~4 years), exhausting `_bribesPerPriod[period][pool]` slots so legitimate protocols cannot add real incentives; can be repeated on every new pool to brick Voter/BribeRewarder functionality or target competitors.
**Escalation:** Scaling across all newly created pools or many voting periods to make the bribe/vote incentive system permanently unusable.
**Insight:** When a per-key array has a hard length cap, check whether anyone can append to it cheaply; permissionless registration plus a fixed MAX_* limit is a griefing vector even without value transfer.