Optimizing Lido On-chain Voting Timelines for Inclusive Governance

Proposals
22

Hello!

After conducting thorough research on what can be affected by the change of the voting timeline, Lido contributors identified the list of necessary changes.

Here is the summary of all affected protocol’s parts:

  • GateSeal: redeploy with new duration. The value is calculated as governance reaction time * 2 + 1. Therefore, the new value is 11 days;

  • Oracle Daemon Config: change FINALIZATION_MAX_NEGATIVE_REBASE_EPOCH_SHIFT. The value is calculated as epochs per day * governance reaction time * 2. Therefore, the new value is 2250;

  • Voting UI: it’s the main user interface that needs to be thoroughly tested with new voting parameters;

  • Documentation: adjust different sections to reflect new information;

  • Other minor changes: update on-chain and off-chain protocol infrastructure, services, landing pages, Forta alerts, Dune dashboards etc.

It’s important to note that, given Easy Track motions will still have a 72-hour duration, an Easy Track factory can potentially front-run ongoing DAO decision votes if not objected to by 0.5% of the total LDO supply (assuming the DAO vote started before the ET motion, with up to a 2-day precedence). This is accepted as is, without changes. Easy Track motions can only be initiated by trusted callers, and as a last mitigating option, there is an Emergency Brakes lever to pause Easy Track entirely.

This proposal to change voting duration to 72h+48h will be brought to the off-chain vote in December, and on-chain changes will be released during the following voting slots.

9 Likes