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
- 9
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 9 closed, publicly disclosed PartyDAO reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, 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
- Logic error findings disclosed against PartyDAO
- 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.sol#mint` - User can delegate another users funds to themselves and brick them from changing the delegation
PartyDAO's InitialETHCrowdfund lets any caller use contributeFor to seed a governance-card mint for an address that has not yet received its NFT. Because the mint logic only honors a caller's chosen delegate when no delegation exists yet and otherwise preserves whatever delegationsByVoter already holds, an attacker can front-run a victim's finalizing contribution with a one-wei contributeFor and permanently bind the victim's voting power to the attacker. The victim's subsequent large contribution then grants the attacker unearned governance weight until the victim manually redelegates. The judge ruled this a Medium, no-cost temporary vote-stealing/griefing vector and the Party team confirmed it, choosing documentation changes over a code fix.
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: `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: `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: 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.
PartyDAO's governance mechanism suffers from a critical access control vulnerability where the `ArbitraryCallsProposal` contract does not restrict interactions with the `AddPartyCardsAuthority` contract. This oversight allows a malicious 51% majority to mint themselves enough governance tokens to effectively achieve 100% of the voting power. By doing so, the attacker can bypass security guardrails intended to protect the DAO's 'precious' NFT assets, allowing for the unauthorized extraction of these assets.
All reports in this group
- PartyDAO: Some arbitrary proposal calls will fail because `executeProposal()` in `ProposalExecutionEngine` is not payableGovernance attack$0
- PartyDAO: `ETHCrowdfundBase.sol#processContribution` - Impossible to finalize crowdfund because of `minContribution` checkGovernance attack$0
- PartyDAO: `PartyGovernance.sol#accept` - `passThresholdBps` isn't cached for each proposal which can lead to problems if changed through another proposalGovernance attack$0