---
tags: ADR, governance, LIP, ethereum
author: Aleksei Potapkin, Sam Kozin, Eugene Mamin, Eugene Pshenichnyy
blockchain: etherium
discussions-to: TBA
---

# ADR #5: Last moment vote mitigation

* Status: RFC
* Deciders: Lido dev team, Lido DAO
* Date: 2022-04-29

Currently, an attack on the Lido governance is possible which allows a malicious actor to unexpectedly pass a vote given the actor holds enough LDO and casts their voting power in the last block of the vote.

## Voting mechanics

A Lido DAO vote can be executed if, within the vote timeframe lasting 72 hours, more than 5% of the total LDO supply (current minimal support value) has supported the outcome, AND at least half of the participated LDO supported the outcome. Votes are accepted until the vote timeframe ends, and the vote can be executed right after that. A script that is invoked if a vote passes has the highest level of privilege inside Lido infrastructure.

## Context and problem statement

Recently, the [governance takeover](https://rekt.news/beanstalk-rekt/) happened in Beanstalk through starting the covert voting and casting a vote using flashloaned tokens in the last moment, leaving no time for devs and community to react.

Although the same approach is not viable in the Lido setup (we have a MiniMe gov token that prevents flashloaned tokens from casting a vote with), in general, we're still cautions of the last minute voting.

As governance takes place on L1 and voting costs are significant, most votes barely gather enough voting power to reach the minimal support. And if some malicious (or hacked) major LDO holder decides to overturn the vote in the last moment, there will be no time to vote against and no time for devs and community to take any measures.

### Threat model

1. The attacker accumulates at least minimal support value of the LDO token supply (currently 5%).
2. A vote is started that gains less support than the current minimal value. DAO members expect it to fail since minimal support is not reached.
3. The attacker waits until the final block of the vote timeframe and includes a transaction in that block that votes for the outcome using the accumulated LDO. The vote now satisfies both conditions for execution.
4. The attacker includes a transaction executing the vote in the next block.

Right now, to fend off such an attack, we need to:

1. Identify it. If a malicious vote is created, we should know about in the shortest term possible.
2. Facilitate DAO participants to vote against with all available tokens to be sure that it cannot be overturned in the last moment. We don't know in advance what number of tokens the attacker has in their sleeve, so we can't stop on any particular level of opposition.

Moreover, modifications of the attack are possible:
- Spawning multiple malicious votes in parallel, making DAO spend more time and resources to defend. Attacker will need to backrun just one vote, while the DAO needs to vote against all of them.
- Attacker can change his decision at the last moment.
- Voting can be consealed to avoid excessive attention by DOS attack on our infrastructure or social engineering.

## Decision drivers

- _Degree of mitigation_ — how easy it is to exploit even after mitigation
- _Time to react_ — in case of an attack, it's important for DAO members, 3rd party integrations and stETH holders to have some time to adapt to the associated changes.
- _Influence on the DAO performance_ — whether and to which degree the DAO ops become more complicated after implementing the solution
- _Time to ship_ — how complex the solution is to develop and deliver
- _Decentralization_ — whether the community controls the solution.

## Considered options

- Timelock + emergency stop
Pros:
- Most widespread and proven solution
- Emergency stop rights can be given to community like in [Maker DAO][maker-stop] or [Curve][curve-stop]

Cons:
- Timelock alone does not solve the issue. It just gives some time for a maneuver
- Emergency stop is a complex solution that will require significant time to deliver
- Emergency stop has a separate voting flow that itself introduces a new attack surface

- Increasing the minimal required support for a vote
Pros:
- Makes it harder and more expensive to mount an attack

Cons:
- Makes it equally harder for the DAO to operate robustly
- Does not effectively prevent the attack
- Hard to balance the DAO performance with the security

- Voting power decreasing over time during the voting
Pros:
- Encourages the voters to participate earlier
- Gives the community a chance to overcome the malicious vote, with the community power decreasing over time

Cons:
- Does not prevent the attack completely, the attacker just needs to vote earlier
- Makes it harder for the DAO to operate robustly
- Rather complex and relatively hard to ship solution
- The attacker still remains in a more favorable position in comparison to the honest DAO members since the latter vote after the attacker and thus with the diminished voting power
- More sensitive to DOS attacks: the attacker is motivated to perform a DOS to decrease the voting power of honest actors. Moreover, depending on the availability of those honest actors, a comparatively short DOS could be enough to prevent the DAO from opposing the vote.

- Timelock + veto multisig
- It's a pretty close to our final decision
- Concentration of veto power is generally not desirable
- It'll slowdown the DAO, but this kind of slowdown is inevitable to make a room for everybody to react properly.

## Proposed solution

We propose to split each vote timeframe into two phases:

1. Main phase, where one can vote both for and against.
2. Objection phase, where one is only allowed to vote against.

We propose the Objection phase to last 12-24 hours. It's up to discussion to define the convenient timeframe here.

### Pros
- Allows 3rd parties and stETH holders to adjust their strategies and integrations for the upcoming decision. In this sense, the proposed option is equivalent to a timelock with the added ability to object.
- Requires minimal changes to Aragon Voting contract.
- Gives the power to cancel the vote to the broad community of LDO holders.

### Cons
- Increases chances of governance paralysis because of the opposition having preference.
- Makes governance more conservative in its decisions, giving more power to opposition, but it's not necessarily a cons.

### Other measures
Also, we propose to setup alerting for the following scenarios as a part of proposed solution:
- Any vote that changes its expected outcome closer to its end
- Any new vote that looks malicious by the number of criteria

[maker-stop]: https://makerdao.world/en/learn/governance/emergency-shutdown
[curve-stop]: https://curve.readthedocs.io/dao-ownership.html#agents