blackhole - Desync between bribes being paid and gauge distribution allows voters to receive bribes without triggering emissions

[sherlock-admin2]

blackhole

Medium

Desync between bribes being paid and gauge distribution allows voters to receive bribes without triggering emissions

Summary

The desynchronization between the awarding of bribes by the ExternalBribe contract and the distribution of emissions by the Voter contract allows voters to receive bribes without their gauge receiving the corresponding emissions.

Vulnerability Detail

ExternalBribe awards bribes based on the voting power at EPOCH_END - 1. However, Minter.update_period() and Voter.distribute() can be called sometime after this epoch ends. This creates a window where voters can manipulate their votes, resulting in the following scenario Some voters may switch their vote before their weight influences emissions, causing the voters to receive bribes, but the bribing protocols to not have their gauge receive the emissions.

For example, a project XYZ offers the best yield for 3 weeks. A voter can vote for XYZ during this period and then switch their vote to another gauge immediately after the third voting period ends, allowing them to:

• Receive the third week's bribes for XYZ.
• Redirect their vote to another gauge for emissions, resulting in a misalignment between bribes received and emissions distributed.

Impact

This desynchronization issue leads to:

• Misallocation of rewards, where bribes are paid out without corresponding emissions.
• Potential loss for bribing protocols, as they do not receive the expected gauge emissions.
• Manipulation of the voting and reward distribution system, undermining its integrity and fairness.

Code Snippet

distribute; https://github.com/sherlock-audit/2024-06-velocimeter/blob/main/v4-contracts/contracts/Voter.sol#L550 _vote; https://github.com/sherlock-audit/2024-06-velocimeter/blob/main/v4-contracts/contracts/Voter.sol#L276 earned; https://github.com/sherlock-audit/2024-06-velocimeter/blob/main/v4-contracts/contracts/ExternalBribe.sol#L212

Tool used

Manual Review

Recommendation

It is recommended to introduce a post-voting window before emissions distribution. Specifically, allowing a 1-hour post-voting window for protocols to trigger distribution can mitigate the desynchronization issue. This ensures that:

• Votes cannot be changed immediately after the reward epoch ends.
• The alignment between bribe payments and emissions distribution is maintained.
• The integrity of the voting and reward distribution system is preserved, ensuring fair allocation of rewards.

[nevillehuang]

Spearbit 5.3.4, noted as medium

Invalid per READ.ME

Any issues created by front running the distribute function on voter after epoch flip ( doing actions on the protocol after epoch flip but before the distribute call was executed ) are acceptable risk unless it's high severity

Note velodromes's discussion reducing severity

Discussed this with the team. We acknowledge that it is an issue, although we do think that economic incentives encourage voters to vote later during the epoch (as they will seek to profit maximize, this was discussed elsewhere in another issue). Due to the potential risk of loss for partners, we considered a simple mitigation of preventing voting in another window (an hour long post epoch flip, similar to the votium-style time window) to allow distributions to take place. Distributions are an automation target and will be incentivized down the track. I have thought about it and have also considered an option where users passively call distribute prior to voting (e.g. perhaps in reset but it appears it does not mitigate the issue as it requires ALL pools to be distributed (at a fixed total voting weight supply), prior to allowing votes to change.