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:
The attacker accumulates at least minimal support value of the LDO token supply (currently 5%).
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.
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.
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:
The general phase, lasting 48-72h, is conventional voting, where one can vote both for and against.
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.
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).
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?
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.
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.
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.
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.
There is one feature request, the current implementation allows you to object only to the balance that the holder had at the time of the previous block regarding the start of voting.
For example, if the holder put his LDO to the money market protocol, then if a controversial vote appears, he will no longer be able to send his objection. Because the holder did not have LDO at the time the voting began.
The situation will be solved if the balance of tokens for objection is taken at the end of the voting time and right before the objections phase. However, this may break the rest of the logic, so I suggest not to do this revision right now.
It’s a good idea but could be misused if implemented in a naive way.
Suppose someone voted against the proposed voting, and before the objection phase started, decided to transfer LDO to someone else. The latter could use the voting power again during the objection phase. So, this is a kinda ‘voting double-spending’ which amplifies objections’ power.
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.
But it actually motivate you to vote later, because you play the game with open information if cast the vote in a last block vs. no information if casting vote at the beginning.
And giving the fact that DAO votings usually choose between “do something” and “do nothing” and those who wants to change are usually more motivated to take part, it gives us a process that skewed towards changes, if implemented the classic way.
Something that I forgot to ask: how would this implementation affect existing any current extensions that we have to the Aragon governance system, specifically Easy Track?
The Snapshot ‘Two-phase voting for Lido DAO’ passed and got the quorum!
Thank you for your participation!
Results: For 61M, against 1.3K
The next step for this proposal is on-chain voting. Stay tuned!
New UI: 
Finally, we have it deployed and running on Mainnet.