TempleGold
TempleDAO
Foundry
25,000 USDC
View results
Previous Next
Submission Details
Severity: high
Invalid

Inflated vote counts manipulation due to lack of cooldown period between delegations

topstar

https://github.com/Cyfrin/2024-07-templegold/blob/main/protocol/contracts/templegold/TempleGoldStaking.sol#L145-L147

https://github.com/Cyfrin/2024-07-templegold/blob/main/protocol/contracts/templegold/TempleGoldStaking.sol#L543-L550

https://github.com/Cyfrin/2024-07-templegold/blob/main/protocol/contracts/templegold/TempleGoldStaking.sol#L552-L572

Summary

An attacker could manipulate the delegation mechanism to gain disproportionate influence in the voting process.

Vulnerability Details

The _delegate and _moveDelegates functions can be exploited by an attacker to manipulate the vote counts.

An attacker can set up multiple addresses and stake tokens in each. By frequently changing the delegation between these addresses and a central master address, the attacker can artificially inflate the vote count of the master address. This manipulation is facilitated by the frequent delegation changes which may not be adequately accounted for in the vote-moving logic.

Here we can see how the delegation works:

function _delegate(address delegator, address delegatee) internal {
address currentDelegate = delegates[delegator];
uint256 delegatorBalance = _balances[delegator];
delegates[delegator] = delegatee;
​
emit DelegateChanged(delegator, currentDelegate, delegatee);
_moveDelegates(currentDelegate, delegatee, delegatorBalance);
}
​
function _moveDelegates(
address srcRep,
address dstRep,
uint256 amount
) internal {
if (srcRep != dstRep && amount > 0) {
if (srcRep != address(0)) {
uint256 srcRepNum = numCheckpoints[srcRep];
uint256 srcRepOld = srcRepNum > 0 ? _checkpoints[srcRep][srcRepNum - 1].votes : 0;
uint256 srcRepNew = srcRepOld - amount;
_writeCheckpoint(srcRep, srcRepNum, srcRepOld, srcRepNew);
}
​
if (dstRep != address(0)) {
uint256 dstRepNum = numCheckpoints[dstRep];
uint256 dstRepOld = dstRepNum > 0 ? _checkpoints[dstRep][dstRepNum - 1].votes : 0;
uint256 dstRepNew = dstRepOld + amount;
_writeCheckpoint(dstRep, dstRepNum, dstRepOld, dstRepNew);
}
}
}

As you can see there is no cooldown period for delegations.

Exploit Steps

  • Multiple Addresses Setup: The attacker stakes tokens in multiple addresses.

  • Delegation to Master Address: The attacker delegates the voting power from all these addresses to a single master address.

  • Frequent Delegation Changes: The attacker repeatedly changes the delegation between various addresses to manipulate the vote count.

  • Final Delegation to Master: The attacker delegates everything back to the master address, gaining more voting weight and consolidating the manipulated vote count.

Impact

This allows an attacker to gain disproportionate voting power, potentially influencing governance decisions in their favor. This can undermine the integrity of the voting process and lead to governance decisions that do not reflect the true will of the stakeholders.

Tools Used

Manual code review

Recommendations

Implement a cooldown period between delegations to prevent frequent changes

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.