# Rewards can be allocated for less than minimal reward period with the help of bogus proposal

Rewards.sol checks minimumRewardPeriod against a user-supplied lastProposalId, allowing a bogus proposal to bypass the waiting period and steal rewards.

- Payout: Contest reward
- Severity: medium
- Program: Nouns Dao 2
- Credited: hyh
- Disclosed: 2024-03-03
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2024-03-nouns-dao-2-judging/issues/32
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-03-nouns-dao-2%3AM-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** Rewards.sol client-incentives contract
**Root cause:** The minimumRewardPeriod check uses t.lastProposal.creationTimestamp from a user-supplied lastProposalId without verifying that the proposal is eligible, so any ended proposal can serve as an anchor.
**Steps:**
1. Attacker with >proposalThresholdBPS votes creates a bogus proposal timed to end before the desired reward distribution.
2. Wait until the bogus proposal's endBlock has passed.
3. Call the reward distribution function with lastProposalId set to the bogus proposal's ID and votingClientIds for the target proposals.
4. The check `t.lastProposal.creationTimestamp > $.lastProposalRewardsUpdate + $.params.minimumRewardPeriod` passes because the bogus proposal's creationTimestamp is old enough.
5. Rewards are allocated to the attacker's chosen proposals without waiting for the minimum reward period.
**How found:** Code review of Rewards.sol revealed that the minimumRewardPeriod check uses a user-supplied lastProposalId and does not filter for eligible proposals, allowing any ended proposal to satisfy the time check.
**Exploitation:** Attacker creates a bogus proposal in advance, waits for it to end, then calls the reward distribution with lastProposalId pointing to it, bypassing the minimumRewardPeriod and allocating rewards to proposals they benefit from ahead of other eligible proposals.
**Insight:** When a time-based check relies on a user-supplied identifier, verify that the referenced entity is actually eligible; otherwise an attacker can anchor the check to an irrelevant but old entity.