👊Voting Multiple Times by Shifting Delegation

In decentralized governance systems that involve delegating voting power, the delegation mechanism is designed to allow users to delegate their voting rights to others. However, poorly implemented delegation logic can lead to an exploit where users can cast multiple votes on the same proposal or pool by shifting or redelegating their balance to other addresses. This exploit undermines the integrity of the governance process, giving certain users disproportionate influence over the outcome of votes.

This section will explain the vulnerability where users can vote multiple times on a single pool by shifting delegation and offer insights on how to mitigate this issue.


How the Shifting Delegation Exploit Works

In decentralized governance systems, voting weight is often calculated based on a user's balance or locked tokens, and users are allowed to delegate their voting power to others. However, if delegation is not properly accounted for, a user can delegate their tokens to multiple addresses (or to themselves via proxy contracts) and cast multiple votes on the same proposal or pool, effectively doubling or tripling their voting influence.

Here’s how the exploit works:

  1. Initial Vote: The user votes on a pool using their locked balance. The vote weight is calculated based on their balance and other factors such as the voting period and weight of the pool.

  2. Delegation: The user then delegates their balance to another address, such as a secondary wallet or a contract, without canceling their original vote. This new delegate now has control over the user’s voting weight.

  3. Repeat Voting: The delegate (or the user acting through the new address) can then vote again on the same pool, using the delegated balance to cast another vote. This allows the user to have multiple votes on the same pool, each contributing to the same outcome.

  4. Further Exploits: The user can repeat this process by creating additional addresses or contracts to receive delegated voting power, allowing them to vote an unlimited number of times on the same proposal or pool.

This exploit is particularly dangerous because it allows users to manipulate voting outcomes by concentrating voting power across multiple votes, which should not be allowed.

Proof of Concept: Exploiting the Delegation System

Consider the following steps a malicious user might take to exploit a governance system:

  1. Step 1: Alice locks tokens in the governance system and votes on a pool with her main address.

  2. Step 2: Alice creates a secondary wallet or a contract address and delegates her locked balance to this new address.

  3. Step 3: Alice uses the new wallet to vote on the same pool again, effectively casting a second vote with the same locked tokens.

  4. Step 4: Alice repeats this process multiple times by creating additional wallets or contracts, each time casting a new vote on the same pool using the same balance.

In each iteration, Alice is increasing her voting influence on the pool by exploiting the delegation system, giving her an unfair advantage over other users.


Impact of the Exploit

  1. Disproportionate Voting Power: Users who exploit this vulnerability can significantly increase their voting power by casting multiple votes with the same locked balance, skewing the results of the vote in their favor.

  2. Unfair Governance: The exploit undermines the fairness of the governance system, as a single user can have more influence than they should based on their token holdings. This can lead to governance decisions that do not reflect the true will of the community.

  3. Potential for Governance Takeover: In smaller DAOs or early-stage governance systems, this exploit could be used to take control of the voting process entirely, pushing through proposals that benefit the attacker or blocking proposals that the majority of token holders support.

Last updated