# Possibility to burn all ETH in Crowdfund under some circumstances

Crowdfund with initialContributor=address(0) lets anyone repeatedly call burn(address(0)) to drain all ETH contributions to the zero address.

- Payout: Contest reward
- Severity: high
- Program: PartyDAO
- Credited: Lambda
- Disclosed: 2022-11-17
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2022-09-party-findings/issues/105
- Library page: https://bugbountylibrary.com/r/c4%3A2022-09-party%3AH-02
- 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

**Target:** BuyCrowdfund / CrowdfundNFT burn logic
**Root cause:** CrowdfundNFT._burn can be invoked multiple times for address(0) since no NFT is actually owned there, and the initial contribution is credited to address(0) when opts.initialContributor is unset, so each burn call transfers the initial balance to the zero address.
**Steps:**
1. Deploy BuyCrowdfund with `initialContributor=address(0)` and a nonzero `initialDelegate`
2. Contributor sends 1 ETH via `contribute`
3. Wait until `block.timestamp > duration` so the crowdfund fails
4. Repeatedly call `pb.burn(payable(address(0)))`; each call burns the initial balance (0.25 ETH) to address(0)
5. Repeat until contract balance is 0
**How found:** Code reading of the burn path: noticed that _burn on address(0) has no ownership check preventing repeated calls, and that initialContributor=address(0) is an accepted config, combining the two into a drain.
**Exploitation:** A malicious deployer sets initialContributor=address(0) (a protocol-accepted parameter) and seeds a small initial contribution; after the crowdfund fails, they call burn(address(0)) repeatedly, each call transferring the initial balance to the zero address and draining all contributor ETH. Attacker loses only the seed amount.
**Insight:** When a protocol accepts address(0) as a configurable recipient/owner, check every code path that credits or debits that address — burn/mint/transfer functions often lack a zero-address guard, and repeated calls against address(0) can be a free drain primitive.