Lido DAO governance currently relies on Aragon voting model. This means DAO approves or rejects proposals via 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 the Lido DAO and is often used only to rubberstamp 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 comunity, and votings on such decisions often struggle to attract wider DAO attention and thus, to pass.
Easy Track frictionless motions are 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 traditional 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 four types of votings 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 into reward programs
- Funds being allocated to LEGO program
- Funds being allocated to the whitelisted referral partners
See specification.md for full specification.
Every EVMScript factory must implement IEVMScriptFactory
interface.
Methods from this interface are used by EasyTrack at the motion lifecycle.
Every action done by EasyTrack must be allowed to do also by Aragon Voting.
This requirement fills automatically in cases when easy tracks do actions provided by the Aragon application. But for contracts outside the Aragon ecosystem access to Voting must be provided explicitly. To grant such access you can use role-based control access contracts from the OpenZeppelin package. To see an example of how this pattern was used in EVMScript factories see the RewardPrgoramsRegistry.sol
contract.
Each EVMScript factory must provide the method decodeEVMScriptCallData
to decode the calldata used in it.
This provides a flexible way to check which parameters were used to create motion even without access to UI.
Each EVMScript factory must be carefully reviewed and tested before adding to the EasyTrack.
Remember, that EVMScript generated by the factory might be run with potentially dangerous permissions. Be sure, that generated EVMScript makes exactly what it has to do.
When adds new EVMScript factory use only required permissions
Permissions for EVMScript factory must contain only methods used by generated EVMScript.
To use the tools that this project provides, please pull the repository from GitHub and install its dependencies as follows. It is recommended to use a Python virtual environment.
git clone https://github.com/lidofinance/easy-track
cd easy-track
npm install
# in case of pyyaml installation issue, it should be installed manually
# see issue for details https://github.com/yaml/pyyaml/issues/601
poetry run pip install "cython<3.0" pyyaml==5.4.1 --no-build-isolation
poetry install
poetry shell
Compile the Smart Contracts:
brownie compile # add `--size` to see contract compiled sizes
Contains script to deploy main Easy Track contracts with EVM Script factories. Script requires next ENV variables to be set:
DEPLOYER
- id of brownie's account which will deploy contracts. Might be skipped if run ondevelopment
network.LEGO_PROGRAM_VAULT
- address of Lido's LEGO programLEGO_COMMITTEE_MULTISIG
- address allowed to create motions to top up LEGO programREWARD_PROGRAMS_MULTISIG
- address allowed to create motions to add, remove or top up reward programPAUSE_ADDRESS
- address to grant PAUSE_ROLE
Next optional variables can be set:
UNPAUSE_ADDRESS
- address to grant UNPAUSE_ROLECANCEL_ADDRESS
- address to grant CANCEL_ROLE
Contains script to validate deployed setup of EasyTrack in mainnet network.
Script accepts next optional ENV variables:
GRANT_PERMISSIONS_VOTING_ID
- id of voting where permissionsCREATE_PAYMENTS_ROLE
andSET_NODE_OPERATOR_LIMIT_ROLE
granted toEVMScriptExecutor
. If this variable is passed, the simulation will not create new voting to add permissions toEVMScriptExecutor
.
Creates Aragon's Voting to grants permissions to EVMScriptExecutor required to execute EVMScripts generated by EVMScript factories. After voting creation checks that after execution all permissions will be granted correctly.
Script requires next ENV variables to be set:
DEPLOYER
- id of brownie's account which will deploy contracts. To create a voting account must have LDO Tokens. Might be skipped if run on adevelopment
network.EVM_SCRIPT_EXECUTOR
- address to grant permissions.
Creates Aragon's Voting to revoke all granted permissions from EVMScriptExecutor. After voting creation checks that after execution EVMScriptExecutor will has no any permissions.
Script requires next ENV variables to be set:
DEPLOYER
- id of brownie's account which will deploy contracts. To create a voting account must have LDO Tokens. Might be skipped if run on adevelopment
network.EVM_SCRIPT_EXECUTOR
- address to grant permissions.
Sends transactions to renounce DEFAULT_ADMIN_ROLE
, PAUSE_ROLE
, UNPAUSE_ROLE
, CANCEL_ROLE
roles from EasyTrack contract deployed in mainnet 0xF0211b7660680B49De1A7E9f25C65660F0a13Fea
.
Script requires next ENV variables to be set:
DEPLOYER
- address of the account that renounces roles
The fastest way to run the tests is:
brownie test
Run tests with coverage and gas profiling:
brownie test --coverage --gas
Current brownie version has problems with coverage reports for some contracts. Contracts which use immutable
variables don't get on the resulting report. Details can be found in this issue. Easy Track uses immutable
modifier in next contracts:
- TrustedCaller.sol
- EVMScriptExecutor.sol
- AddRewardProgram.sol
- IncreaseNodeOperatorStakingLimit.sol
- RemoveRewardProgram.sol
- TopUpLegoProgram.sol
- TopUpRewardProgram.sol
The workaround for the coverage problem is removing the immutable
modifier from the above contracts. Without modifier above contracts will be listed in the coverage report