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.
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).
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
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:
- Node Operators Commitee to start staking limit increase motions.
- 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 specification.md for full specification.
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.
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 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 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 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.
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.