# Previously nominated delegate can reset the delegation

PartyDAO mint() on burn() resets a contributor's current delegate to a stale recorded delegate, letting an old delegate reclaim all voting power.

- Payout: Contest reward
- Severity: medium
- Program: PartyDAO
- Credited: hyh
- Disclosed: 2022-11-17
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-09-party-findings/issues/361
- Library page: https://bugbountylibrary.com/r/c4%3A2022-09-party%3AM-02
- Tags: domain:web3 kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** Crowdfund/PartyGovernanceNFT mint and delegation logic
**Root cause:** mint() always calls _adjustVotingPower with the delegate recorded at contribute() time, assuming it is the owner's first operation, overwriting any later delegateVotingPower() choice.
**Steps:**
1. Bob contributes 0.01 ETH via `contribute(Mike, ...)` recording Mike as delegate
2. Melany transfers a high-voting-power tokenId to Bob via `safeTransferFrom`
3. Bob calls `delegateVotingPower(Linda)` to set Linda as current delegate
4. Anyone calls `burn(Bob)`; votingPower>0 triggers `party_.mint(Bob, votingPower, delegationsByContributor[Bob]=Mike)`
5. mint() calls `_adjustVotingPower(Bob, +power, Mike)`, redirecting all of Bob's voting power to Mike
**How found:** Code reading of burn()->mint()->_adjustVotingPower flow, noticing mint assumes first operation for owner and ignores existing delegation set via delegateVotingPower().
**Exploitation:** Attacker (old delegate Mike) waits until contributor has re-delegated to a new delegate, then calls public burn(contributor) to force mint() and reset delegation back to himself, capturing the contributor's full voting power.
**Insight:** When a mint/mint-like path passes a stored delegate, check whether the owner may have since re-delegated; stale stored delegation can silently override current choice and be triggered by any public caller.