LIP-3: Easy Track Motions for DAO routine operations


Lido DAO governance currently relies on Aragon voting model. This means DAO approves or rejects proposals by direct governance token voting. Though transparent and reliable, it is not a convenient way to make decisions only affecting small groups of Lido DAO members. Besides, direct token voting doesn’t exactly reflect all the decision making processes within Lido DAO and is often used only to adopt an existing consensus.
There are a few natural sub-governance groups within the DAO, e.g. validators commitee, financial operations team and LEGO commitee. Every day they need to take routine actions only related to their field of expertise. The decisions they make hardly ever spark any debate in the community, and votings on such decisions often struggle to attract wider DAO attention and thus, to pass.

Proposed solution

We propose Easy Track frictionless motions as a solution to this problem.
Easy Track motion is a lightweight voting considered to have passed if the minimum objections threshold hasn’t been exceeded. As opposed to regular Aragon votings, Easy Track motions are cheaper (no need to vote ‘pro’, token holders only have to vote ‘contra’ if they have objections) and easier to manage (no need to ask broad DAO community vote on proposals sparking no debate).

Use cases for Easy Track motions

There are three types of voting run periodically by the Lido DAO that are proposed to be wrapped into the new Easy Track motions.

  • Node Operators increasing staking limits
  • Funds being allocated to reward programs
  • Funds being allocated to LEGO program

Sub-governance groups

There’s sub-governance group within the Lido DAO for each of the voting cases listed above. Those groups have been formed intentionally or in a more natural way, and at this point creating and maintaining periodical Aragon votings falls within their remits.
The proposed improvement will require formalizing sub-governance groups:

  1. Node Operators Commitee to start staking limit increase motions.
  2. Financial Operations Team to start funds allocation motions (i.e. LEGO and reward programs).

Node Operators Commitee should include withdraw addresses of active node operators partnering with Lido, while Financial Operations Team should consist of established DAO members’ addresses and should be created or modified via normal Aragon votings. Financial Operations Team will be represented as a Gnosis Safe Multisig with access to corresponding Easy Track features.


To create a feature as flexible and extendable as possible, we propose implementing Easy Track functionality within several contracts rather than building a single contract for it.
The main contract will be the Easy Track Registry, and separate Executor contracts will inherit from it to make different types of Easy Track motions possible.
This architecture aims to support further extension by adding new types of Easy Track motions without replacing the whole system.

The statement below is abstract, you can visit for full specification.

Easy Track Registry

Easy Track Registry is the main contract containing the basic motion logic and data shared by all the Easy Track types, including who has started the motion, when, for how long LDO holders will be able to submit objections, what would be the minimum disapproval objections threshold, current objections submitted.
Registry will also store motion related encoded byte type data. We propose using byte data type due to various sets of parameters required for different motion types.
Besides, Easy Track Registry will store a list of active motions (the ones created but neither enacted nor canceled yet). Once enacted or canceled, the motion will be permanently deleted, since there is really no need to interact with past motions in any way.
The registry contract should be owned by DAO and include some methods only accessible to Lido DAO, i.e.:

  • setting motion duration;
  • setting objections threshold;
  • setting maximum active motions count;
  • adding or removing motion types.

Easy Track Executors

Logic for specific motions will be stored in Executor contracts.
List of Executors added is stored in the Registry and only the DAO can add more or remove them. In similar way, each Easy Track Executor stores the Registry contract address in order to control access to Executor’s methods.
Both on motion creation and motion cancelation, permission checks will be run to make sure the caller address matches the Easy Track Registry address.

Node Operators Easy Track Executor

Node Operators Easy Track Executor is an Executor contract for Node Operators Commitee to start or cancel motions to increase their staking limits.
Multiple sanity checks will be implemented, check the full documentation for details.

Rewards Easy Track Executors

Rewards Easy Track Executors implements logic to control the whitelist of allowed LDO recipients and to transfer LDO into one or multiple allowed recipients addresses.
There are three types of operations managed by Rewards Easy Track motions and thus three executor contracts to manage each type of motions:

  • adding a recipient address into allowed recipients list (i.e. adding a new reward program into Lido rewards stack)
  • removing a recipient address from allowed recipients list
  • transfering LDO into a whitelisted recipient address (i.e. refilling an ongoing Lido reward program)

Any of these actions can only be initiated as a motion by trusted Financial Operations Team Multisig.

Lego Easy Track Executor

LEGO is Lido Ecosystem Grants Organization funded from the Lido Treasury. Funds allocation is a routine process handled by Financial Operations Team and thus can be optimized with Easy Track.
Lego Easy Track Executor implements logic to allocate LDO, stETH or ETH for LEGO grants and make sure the methods can only be called by trusted Financial Operations Team Multisig.

Sanity and security

Easy Track motions are meant to be as frictionless as possible, and thus require reliable security mechanisms and sanity checks. To prevent malicious actions, we propose putting following limitations in place:

  • It should be impossible to set objections threshold at more than 5% of total LDO supply. Nevertheless, default objections threshold should be set a lot lower at 0.5% of total LDO supply. Easy to start – easy to reject.
  • It should be impossible to set motion duration at less than 42 hours. For any motion there should be enough time for DAO to submit objections and reject the motion. For more urgent issues there’s always an option to start a regular Aragon voting.
  • It should be impossible to spam motions. The default limit for simultaneously active motions will be set at 48 and it can only be increase by the DAO to up to 128 motions at a a time.


Beside contracts, Easy Track requires dedicated UI providing functionality similar to Aragon voting app.
We propose building three views to overview and manage Easy Track motions as follows:

  • Motion list view including all the ongoing votings, their current status and time left to submit objections. On this page, it will also be possible to look through historical motions passed and canceled. Data for this historical section will be collected via subgraph.
  • Motion view containing details for specific motion (description, status, current objections submitted) and action button (submit objections).
  • Motion creation view to start new motions. This functionality will be actually only available to respective sub-governance group.

I like the idea of opt-out voting about some specific topics, because it’s a lot of pain for example to ask everyone to vote on node operator keys uploading. Several things: 1) the default limit for simultaneously active motions should be set at 24 or even 12 for start at my opinion. 2) I propose to rename Easy Track Motions → Easy Track Actions.


Is it the same multisig as above? Or the LEGO could use it’s wallet to ask for more funds?

I’m very much pro this proposal, as it eases up most of routine protocol operations currently requiring DAO votes. This being said, we have to make sure that the initiative is safe for the DAO operations (putting absolute limits for funds transferred, for instance)

1 Like

Our idea was to manage both LEGO funding and reward programs via Financial Operations Team Multisitg. We certainly can consider other options, so far multisig looks safer to us.

1 Like
  1. Good point on smaller default active motions value, safety first and we can increase it further later if needed.
  2. I personally don’t see significant difference, both work for me.

I think this is generally a good idea! Some small comments:

Why 42 and not 48 (2 days)?

+1. 48 seems very large, especially for simultaneous ones.


Nice to see you approving this proposal!
42 hours is definitely a typo, and decreasing active motions limit also makes perfect sense, thanks.

1 Like

I generally like the idea of this proposal a lot. From my experience as a node operator, it’s sometimes really hard to get that 5% threshold for a regular staking limit vote. This proposal would definitely benefit that process by a lot!

I agree with the feedback mentioned by @ujenjt that 48 parallel motions are too much. I think that 12 should be the absolute maximum, especially in the beginning.

In regards to the minimum time for these motions, I feel like that depends on the type of motion. 48 hours might be sub-optimal for some use-cases:

Thinking about the past few weeks where we had a sudden spike in new deposits and needed new keys ASAP, I would feel like waiting 48 hours for that would be too much. Sure, we could do a regular Aragon vote in that case, but the goal is to move away from it for decisions that only affect a small group of DAO members. In case of the staking limit increase, these motions would be started by the node operator multi-sig, which means that 50+% of operators should already have verified the correctness of these keys. In that case, I think a 24 hour or even 12 hour window to block the motion would be enough and would enable us to react much faster to whales/institutionals entering Lido.
For some other motions, like transferring LDO token, I see a minimum of 48 hours as reasonable, so maybe we could introduce different times for different types of motions?

1 Like

Thank you for your feedback!
Balance of how effortless and secure easy track motions should be is tricky. We didn’t mean to use Node Operators multi-sig because it will require regular votings to manage the multi-sig itself. So the idea is to look at Lido Node Operators Registry and allow any active Node Operator start motions on their own. 48 hours is indeed too long to react to whales entering Lido, fortunately it won’t be too difficult to adjust limits and thresholds before releasing the feature.

1 Like

Default-pass + time pressure make for dangerous combination (not enough time to review, basically). I’m vehemently against having fast resolution easy track actions, at least for now. 48 hours delay is not that bad, anyway: by my napkin calculation it means losing 0.003% of yearly rewards in the mildly bad scenario (10% growth delayed by 2 days), and likely less than that.


Ah thank you for the clarification! I misunderstood about the multi-sig wallet then. In that case, i think we should keep the 48 hours in place and find some social consensus between node operators on reasonable limits to increase to.

1 Like

Hey, Ivan from Aragon here. We recently launched Govern which addresses the issues raised to a certain extent and we would love to have a chat with Lido’s core contributors on whether this issue persists and how we can help designing the solution


Hey! Thanks for stopping by!
Haven’t checked Govern out yet (but we will!), and we definitely are into chatting about further solutions to our DAO problems.

Hey! We took a look at Govern when designing the stuff, and are just not keen to have a dependency on Aragon Court here. As you can see, EasyTracks are for well-defined, limited repetitive operational tasks, unlike fuzzy mushy stuff Aragon Governs want to cover.

1 Like

Hey, let’s make it happen shoot me an email to ivan(at) :slight_smile: