# Rewards can be stolen from other proposals and votes by extending auction revenue period with the help of bogus proposals

Attacker with >proposalThresholdBPS votes front-runs a popular proposal with a bogus proposal, extending the auction revenue window so their clientId captures rewards meant for the rival.

- Payout: Contest reward
- Severity: high
- 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/46
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-03-nouns-dao-2%3AH-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:solidity technique:chained technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** Rewards.sol updateRewardsForProposalWritingAndVoting / proposalDataForRewards
**Root cause:** proposalDataForRewards returns all proposals unfiltered, so the user-supplied lastProposalId sets t.lastProposal.creationTimestamp used as endTimestamp for getAuctionRevenue, even if that proposal is ineligible/bogus.
**Steps:**
1. Attacker holds >proposalThresholdBPS of votes and is affiliated with a clientId beneficiary of an already-passed low-attention `proposal 0`.
2. Observe a high-attention `proposal 1` about to be created.
3. Front-run `proposal 1` creation with a bogus `proposal 2` (same creation time); it need not be eligible, only end before reward call.
4. Call `updateRewardsForProposalWritingAndVoting(proposal_2_id, ids)` with ids covering the uncovered period.
5. `getAuctionRevenue` uses `proposal 2.creationTimestamp` as endTimestamp, capturing all auction revenue up to that moment for `proposal 0`'s clientId undiluted by `proposal 1` votes.
**How found:** Code reading of Rewards.sol: noticed t.lastProposal comes from user-supplied lastProposalId via unfiltered proposalDataForRewards, and its creationTimestamp feeds getAuctionRevenue's endTimestamp before eligibility checks.
**Exploitation:** Attacker pays only extra proposal-creation gas; the bogus proposal is filtered out of eligibility later but its creationTimestamp still anchors the auction revenue window, redirecting the larger share of auction revenue to their affiliated clientId.
**Escalation:** Repeat systematically for each upcoming popular proposal to continuously capture extended auction revenue periods.
**Insight:** When a reward/accounting window is bounded by a user-supplied ID's timestamp, check whether that ID is validated for eligibility before the timestamp is consumed; front-running with a cheap ineligible record can stretch the window.