# Delegate can keep can keep delegatee trapped indefinitely

A malicious delegate opens proposals continuously so delegatees' tokens stay locked in staking, unable to unstake or redelegate.

- Payout: Contest reward
- Severity: medium
- Program: Frankendao
- Credited: rvierdiiev
- Disclosed: 2022-10-31
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-11-frankendao-judging/issues/23
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-11-frankendao%3AM-9
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** Staking.sol lockedWhileVotesCast modifier / governance delegation
**Root cause:** The lockedWhileVotesCast modifier blocks unstake/delegate whenever the caller's delegate has voted on an active proposal or is the proposer of one; a delegate can keep an active proposal open indefinitely.
**Steps:**
1. Attacker becomes delegate of victim via victim's delegation
2. Attacker opens a proposal from account A so victim's delegate is the proposer of an active proposal
3. Victim calls unstake or delegate; modifier reverts with TokenLocked
4. Attacker alternates proposals between account A and account B to always keep one active
5. Victim remains locked to attacker indefinitely
**How found:** Code review of the lockedWhileVotesCast modifier applied to unstake/delegate, noticing the proposer check lets a delegate self-trigger the lock.
**Exploitation:** Attacker uses two accounts to alternate opening proposals, ensuring at least one active proposal always has the attacker as proposer, so the victim's unstake/delegate calls always revert.
**Insight:** When a lock modifier checks 'delegate has voted OR delegate is proposer', the proposer branch is attacker-controllable without any vote; look for self-triggerable conditions in lock/cooldown guards.