# Burning an NFT can be used to block voting

PartyDAO's new lastBurnTimestamp check in accept() lets anyone mint a zero-power NFT and burn it to front-run and block voting.

- Payout: Contest reward
- Severity: medium
- Program: PartyDAO
- Credited: adriro
- Disclosed: 2023-06-23
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-05-party-findings/issues/19
- Library page: https://bugbountylibrary.com/r/c4%3A2023-05-party%3AM-03
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:dos vuln:governance

**Target:** PartyGovernance.sol accept()/burn() governance contract
**Root cause:** The mitigation added to accept() reverts when lastBurnTimestamp == block.timestamp, so any burn in the same block (even of a zero-voting-power NFT) blocks accept() calls.
**Steps:**
1. Alice creates a proposal via `party.propose(...)`.
2. Bob submits `party.accept(proposalId, 0)` to vote.
3. Attacker front-runs: `party.mint(authority, 0, authority)` then `party.burn(dummyTokenId)`.
4. Bob's `accept()` reverts with `CannotRageQuitAndAcceptError` because lastBurnTimestamp == block.timestamp.
**How found:** Reading the new lastBurnTimestamp validation comment in accept() and reasoning that the same-block check can be triggered by any burn, including a zero-power mint/burn, to grief voting.
**Exploitation:** Attacker mints a zero-voting-power NFT (keeping total voting power unchanged) and burns it in the same block just before a victim's accept() call, causing the victim's vote transaction to revert.
**Insight:** When a fix adds a same-block timestamp guard to mitigate one exploit, check whether an attacker can trigger that guard cheaply (e.g. mint zero-power token then burn) to grief legitimate calls.