# Old delegatee not deleted when delegating to new tokenId

VoteEscrowDelegation.delegate failed to remove old delegatee, letting one token's balance count toward multiple tokenIds and multiply voting power.

- Payout: Contest reward
- Severity: high
- Program: Golom
- Credited: Lambda
- Disclosed: 2023-04-05
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-07-golom-findings/issues/169
- Library page: https://bugbountylibrary.com/r/c4%3A2022-07-golom%3AH-04
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:governance

**Target:** VoteEscrowDelegation.sol delegate() / governance voting
**Root cause:** delegate() adds the new tokenId to delegatedTokenIds but never removes the tokenId from the previous delegatee's list, so the same balance is counted for multiple delegatees.
**Steps:**
1. Bob owns token 1 (balance 1000) and tokens 2,3,4,5.
2. Call `delegate(1,2)`, `delegate(1,3)`, `delegate(1,4)`, `delegate(1,5)`.
3. Each call appends tokenId 1 to the new delegatee without removing prior entries.
4. Call `getVotes`; token 1's 1000 balance is counted for tokens 2,3,4,5, quadrupling voting power.
**How found:** Code reading of delegate() revealed the new tokenId is pushed to delegatedTokenIds but the old delegatee entry is never cleaned up, implying double counting.
**Exploitation:** Attacker with one large-balance token delegates it to many tokenIds they control, each retaining the balance in delegatedTokenIds, multiplying governance weight to swing votes.
**Insight:** In delegation/escrow accounting, check that reassignment paths remove the prior mapping entry; any append-only delegatedTokenIds list without a corresponding delete is a double-count vector.