# LDO governance mechanics

Lido DAO is governed by the LDO token. Any change to the protocol mechanics and configuration, as well as any spending of the protocol treasury has to be approved by a DAO vote. That vote could be a standard Aragon DAO vote (more on that later) or an optimistic "Easy Track" motion.

The "Easy Track" mechanism (https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-3.md) aims at decreasing the friction of the routine DAO operations. Any decisions this mechanism is allowed to take are strictly limited in scope, don't touch the core protocol functionality, cannot trigger code upgrades, and can be objected by any group of people collectively holding 0.5% of the total LDO supply.

In a standard Aragon DAO vote (further referred to as just "DAO vote"), the voting power of an address is proportional to the amount of LDO the address possessed (including vested and not-yet-transferrable tokens) at the block preceding the one the vote was started in. The total voting power is proportional to the total LDO supply at the same block.

Due to these mechanics, it's impossible to vote using flashloaned LDO since flash loans have to be returned within the same block and thus don't reflect in the asset balance at the block end.

For a DAO vote to pass, it's currently required that at least 5% of total voting power (common mistake is to think it's 5% of circulating token supply) supports the outcome AND more voting power supports the outcome than objects to it.

### Upcoming improvements

No timelock is implemented currently so the vote can be executed right after the voting period (currently set to 72h) ends. Also, if more than 50% of total voting power supports the vote outcome, it can be executed instantly even if the voting period hasn't ended yet.

This opens up the possibility of the "last-minute vote" governance attack where an adversary having as little as 5% of LDO total supply in possession during the whole 72h vote period can unexpectedly pass a vote that was seemingly going to fail.

To prevent this attack, the [Two-phase voting mechanism](https://research.lido.fi/t/proposal-last-minute-vote-mitigation/2162) was implemented by the Lido dev team and is expected to be activated by a DAO vote after the audit report is obtained.

It avoids last-minute passing of the vote by removing the instant vote execution mechanics mentioned above and dividing any vote into two phases: the normal phase and the objection phase. During the objection phase, one can only vote against the outcome if previously hadn't voted or change the vote from "for" to "against" otherwise. The vote outcome can be executed if, after both phases, at least 5% of total voting power supports the outcome AND more voting power supports the outcome than objects to it.

The second phase is effectively a timelock with the added ability to object to the vote. Voting power of any participant doesn't change between the two phases, so one cannot obtain extra LDO and use them to object an already running vote.