# ReraiseETHCrowdfund.sol: Multiple scenarios how pending votes might not be claimable which is a complete loss of funds for a user

ReraiseETHCrowdfund claim reverts when funding fee or rounding shrinks computed contribution below minContribution or above maxContribution, permanently locking pending voting power.

- Payout: Contest reward
- Severity: high
- Program: PartyDAO
- Credited: HollaDieWaldfee
- Disclosed: 2023-06-23
- Write-up quality: 8/10
- Original: https://github.com/code-423n4/2023-04-party-findings/issues/13
- Library page: https://bugbountylibrary.com/r/c4%3A2023-04-party%3AH-04
- 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 vuln:fee-bypass

**Target:** ReraiseETHCrowdfund.sol claim/claimMultiple
**Root cause:** claim computes contribution from pendingVotingPower, which was already reduced by fundingSplitBps, so the reconstructed contribution falls below minContribution (or rounding drops a wei); claimMultiple cannot partition voting power into valid per-card ranges either.
**Steps:**
1. Configure crowdfund with minContribution=1e18, maxContribution=1e18, minTotalContributions=2e18, maxTotalContributions=2e18, fundingSplitBps=100.
2. Contributor contributes 1e18 ETH; pendingVotingPower becomes 0.99e18 after 1% fee.
3. Call `crowdfund.claim(member)`; contribution = 0.99e18*1e4/1e4 = 0.99e18 < minContribution, reverts BelowMinimumContributionsError.
4. Call `claimMultiple([...])`; no partition of 0.99e18 yields per-card contributions in [1e18,1e18], reverts.
5. Alternative: minContribution=0.9e18, maxContribution=1e18, maxTotalContributions=1.5e18; contribute 1e18 then 0.5e18; claim reverts AboveMaximumContributionsError(1.5e18,1e18).
**How found:** Read claim/claimMultiple range checks, noticed contribution is derived from pendingVotingPower which is post-fee, and reasoned that fee deduction and rounding can push reconstructed contribution outside [minContribution,maxContribution]; validated with Foundry tests.
**Exploitation:** No attacker profit path; griefing possible by contributing a small amount for a victim to push their pending voting power outside claimable ranges, permanently locking their contributed ETH.
**Insight:** When a contract stores a post-fee/post-slippage balance and later reconstructs the original amount for range checks, the reconstruction must add the fee back; otherwise any nonzero fee breaks equality-bound configs like minContribution==maxContribution.