PartyDAO — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for PartyDAO, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 8
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 8 closed, publicly disclosed PartyDAO reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Governance attack, Reentrancy, Flash loan attack, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Governance attack findings disclosed against PartyDAO
- Reentrancy findings disclosed against PartyDAO
- Flash loan attack findings disclosed against PartyDAO
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
PartyDAO: `PartyGovernanceNFT#rageQuit()` can lead to token loss for users when dealing with zero-balance ERC20 during a `rageQuit()`
PartyDAO's `rageQuit` function fails to correctly enforce minimum withdrawal amounts when a party holds zero balance of a specific requested token. When a user calls `rageQuit` and specifies a minimum withdrawal amount, the contract logic performs a check only if the calculated withdrawal amount is greater than zero. Because the check is skipped for zero-amount withdrawals, the contract burns the user's voting power tokens regardless of whether the user's minimum requirements were met, resulting in a loss of user funds without compensation.
PartyDAO: Single host can unfairly skip veto period for proposal that does not have full host support
PartyDAO's governance mechanism suffers from a vulnerability that allows a single malicious host to bypass the required veto period for proposals. By exploiting the ability to transfer host status, an attacker can repeatedly increment the proposal's host acceptance count using multiple controlled addresses. This forces the system to skip the mandatory security delay intended to protect against malicious or poorly vetted proposals, potentially allowing an attacker to execute harmful actions that would have otherwise been stopped by the veto process.
PartyDAO: `PartyGovernanceNFT` advertises but does not honor the ERC-4906 standard
The PartyGovernanceNFT contract incorrectly claims compliance with the ERC-4906 standard for dynamic NFT metadata updates. While the contract advertises support for the standard, it fails to emit the required MetadataUpdate and BatchMetadataUpdate events when voting power changes occur. This leads to stale metadata being displayed on external platforms like NFT marketplaces and block explorers, potentially enabling deceptive trade practices where NFTs are sold based on outdated voting power data.
PartyDAO: `ETHCrowdfundBase.sol#_processContribution` - Possible DoS on finalization of crowdfund under certain conditions
The crowdfund contract is susceptible to a Denial of Service (DoS) attack when minTotalContributions equals maxTotalContributions. A malicious actor can front-run legitimate contributions to ensure the final contribution amount results in zero voting power due to integer rounding errors. This effectively prevents the crowdfund from finalizing, forcing participants to wait until the contract duration expires to recover their funds.
PartyDAO: `ETHCrowdfundBase.sol#processContribution` - Impossible to finalize crowdfund because of `minContribution` check
PartyDAO's crowdfund mechanism contains a vulnerability where specific, invalid configurations of `minContribution` and total contribution thresholds can lead to a permanent denial of service. If the `minContribution` is set to be larger than the remaining capacity to reach `maxTotalContribution`, users are unable to contribute, and the host cannot finalize the crowdfund. This locks user funds until the contract reaches its expiration duration, preventing any premature resolution or recovery.
PartyDAO: `PartyGovernance.sol#accept` - `passThresholdBps` isn't cached for each proposal which can lead to problems if changed through another proposal
PartyDAO's governance mechanism fails to freeze the pass threshold for individual proposals, instead relying on a global state variable that can be modified mid-vote. This design allows attackers to alter the success conditions of pending proposals by executing separate governance updates to adjust the passThresholdBps. Consequently, attackers can maliciously lower thresholds to pass unpopular proposals or raise them to block legitimate ones, undermining the integrity of the voting process.
All reports in this group
- PartyDAO: Some arbitrary proposal calls will fail because `executeProposal()` in `ProposalExecutionEngine` is not payableGovernance attack$0
- PartyDAO: The 51% majority can hijack the party's precious tokens through an arbitrary call proposal if the `AddPartyCardsAuthority` contract is added as an authority in the party.Flash loan attack$0