LIP-13: Easy Track payments limit

Easy Track proved to be a safe and effective tool that helped to streamline DAO operations and to reduce the voter fatigue. We’d like to extend it further, adding more Motion types and having the community concentrated on the more contentious DAO votings.

But before that, we need to resolve the existing security concerns, at least partially. As you can get from the specification, Easy Track core is a EVMScriptExecutor contract which is responsible for enacting the Motion. The core is allowed to make payments from the DAO treasury and has a relevant Aragon ACL permission for that, but it does not limit amount, frequency or destination of these transactions. Thus, the Motion, draining the treasury to an unspecified address, can be created and, even, enacted if it is not objected within the 72h timelock period. And, the possibility to overlook such a case grows if we increase the number of the Motions. Also, further development of Easy Track can introduce a vulnerability and this risk should be considered.


To mitigate this risk, we’re going to harden the overall security by introducing limits and budgets. We want each Easy Track committee to operate more freely, but within the budget and in limits defined by the Lido DAO. We’ll achieve that in several steps:

  1. A simple security cap for the amount of funds that can be moved by Easy Track from the treasury per transaction. It’s a simple, but effective measure that will be useful in all the possible undesirable scenarios.
  2. Extensive limit and budget security system that allows us to set individual strict constraints on each type of the Motion.

We need to implement at least the first step to be safe while establishing more routine operations using Easy Track, which becomes one of the top priorities now, because of the growing voters’ apathy.


This proposal focuses on the first step, and you can find its thorough description in the related LIP. The second step requires additional time and effort to think it out, and it’ll be in a separate proposal. Here I will describe briefly what we’re going to do:

  • We’ll revoke the Aragon ACL permission that gives Easy Track access to the treasury
  • And replace it with a special parametrized permission with built-in logic that checks if the token is in the list and if the amount is under the limit.
  • That’s it.


We’ve analyzed the latest operations and can propose the following limits as secure and high enough to keep things running smoothly:

  • 1,000 ETH
  • 1,000 stETH
  • 5,000,000 LDO
  • 100,000 DAI

If you can see why it might be too strict or too loose, your feedback would be greatly appreciated.


Very good idea! I think it might be worth looking at historical payment sizes to see if there is a sharp cutoff around a certain amount, and to have the bottleneck be for payments larger/smaller than that. Conceptually, though, I think this is very good!


Most of the payments from Lido DAO Treasury are made in LDOs; the largest single payments are Curve LP rewards (3m LDO this month). The plan is to have some room above max payments, but at the same time provide absolute backstops for amounts managed without active DAO approval.


I greedily support the effort to charge ET with periodic payouts backed by well-defined transparent reasons and visible history.

For example, the previous omnibus votes (#112-#114) had challenging quorum issues cause the whole omnibus was devoted only to exactly one regular referral payout.

We are on the way to route referrals through the ET in the following weeks, but this strongly depends on the financial ET hardening to make it more serene and “Lido-style” :beach_umbrella: .

1 Like

Hi, I am representing Pay3 ( We build enterprise payment solutions for DAOs. We have worked on treasury budget payments streamlining in the past. I want to understand if there is an opportunity to work on this project. Please let me know. Thanks

Hey-hey! Sorry, this exact proposal calls for internal handling; it’s adding safeguards for our custom Easy Track mechanics =)


The snapshot has passed, so the team would be looking into including the change in the next Aragon voting this Thursday, Feb 17th

1 Like

The limits were implemented in Aragon vote #115 & enacted!