Proposal: last minute vote mitigation

As more LDO tokens become available on the market, more possibilities for governance takeover open. And it’s probably a good time to harden our governance process.

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.

Currently, we are afraid of the following possible scenario:

  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.

To eliminate such risk, we propose to split voting timeframe into two phases:

  1. The general phase, lasting 48-72h, is conventional voting, where one can vote both for and against.
  2. Objection phase (12-24h) is a timelock, when one can vote against or change their vote to oppose the decision.

It allows us to have timelock+veto-like behavior for our voting script, without giving up on decentralization and DAO performance. Moreover, it can be implemented with a reasonably small set of changes to the single contract and still gives 3rd-parties and StETH holders a reasonable period of time to react to government decisions.

Yes, it makes votings more conservative by default, giving more power to DAO to oppose the changes, but it can be seen as a natural point for a mature protocol to have a higher barrier to introduce a new change.

You can read about the decision process in more details in this ADR.

Will be deeply grateful for any feedback, further thoughts on this topic or your opinion on phases’ lengths.

9 Likes

I support the proposed solution that would allow us to have something like ‘better Timelock’.

Speaking about the particular phase durations, my opinion here is that having 72h + 24h seems reasonable for voters across different timezones and provides some ‘backward-compatibility’ for the general phase. We could preserve the current omnibus schedule (starting the votes on Tuesdays and running the general phase till Friday, but enacting them on Saturday).

4 Likes

I like this approach, it’s pretty elegant way to avoid this type of attack. Regarding timeframe, I propose to go with 48h + 24h. And regarding the idea, it’s interesting that I have never saw this idea before, maybe someone else saw the similar idea in different protocol?

3 Likes

I also support this mechanism but agree the objection phase should be 24h since a well-timed gov attack would likely aim for Saturday or Sunday night (2am or later) in key timezones.

By allowing 24 hours for objection you ensure that all timezones will have a chance to see and respond if needed.

2 Likes

I’m not sure that Friday night and Saturday are a good days to have an objection round. We’ll probably have an issue with getting a quorum on Weekends. Seems reasonably sane to have 48+24 schedule starting on Tuesday, ending on Friday as usual. We still have time to prepare an omnibus on Monday and no troubles, because of weekend.

1 Like

I agree that the particular schedule is rather contradictory. Need other opinions and suggestions, I suppose.
Though, what we have as a consensus already: the objection phase should last for 24 hours.

I also support the proposal. It seems crucial not only to have additional 24 hours for objections, but also to have automated detection and DAO members notifications about the suspicious votes that should be addressed during these additional 24 hours.

3 Likes

The main problem here seems to be the creation of a covert vote and possibility to use flashloaned tokens, through which, for example, the Beanstalk attack was carried out.

To solve the problem of covert vote the introduction of a 24-hour window for the execution of the vote seems reasonable.

The rest (voting in the last block) is exactly how the DAO works. If a person has voting power that meets the minimum requirements, he is free to vote at any time. This should motivate other token holders to be more active even if it seems that the quorum is not being reached.

1-block flashloans are not a problem here, Aragon voting does not allows flashloaned funds to vote. That might change with multi-block MEV, though.

4 Likes