# The total community voting power is updated incorrectly when a user delegates.

Frankendao Staking.sol mis-updates total community voting power on delegate/undelegate, letting totals drift and corrupt governance accounting.

- Payout: Contest reward
- Severity: high
- Program: Frankendao
- Credited: curiousapple
- Disclosed: 2022-10-31
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-11-frankendao-judging/issues/91
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-11-frankendao%3AH-1
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:accounting-error vuln:governance

**Target:** Staking.sol delegate/undelegate voting power accounting
**Root cause:** delegate() unconditionally adds/removes community voting power based only on delegator/delegatee identity, without checking whether the affected tokenVotingPower balance actually crossed zero.
**Steps:**
1. User A stakes and delegates to self, gaining community voting power counted in total.
2. A delegates to B: currentDelegate==_delegator branch calls _updateTotalCommunityVotingPower(A,false) even though A's tokenVotingPower may still be positive.
3. B delegates back to self: _delegator==_delegatee branch adds community voting power again though it was already counted.
4. Repeat delegate/undelegate cycles to inflate or deflate totalCommunityVotingPower.
**How found:** Code review of delegate() branches comparing identity checks against actual tokenVotingPower balances, spotting that zero-crossing was never verified.
**Exploitation:** Repeated delegate/undelegate calls skew totalCommunityVotingPower, corrupting governance quorum/threshold calculations; no direct fund extraction described.
**Insight:** When accounting totals are adjusted on identity transitions (self vs other), verify the balance actually crossed zero rather than trusting the branch condition; delegate/undelegate round-trips are a classic place for double-count drift.