ADR-lite on LIP-19 contracts real-world usage

Lido DAO leverages EasyTrack motions for day-to-day ops. Currently the three “primitives” exists:

  1. Payment processor: single token, multiple recipients with whitelist. reWARDS & Referral committees leverage those.
  2. Funder: single recipient, any tokens the DAO Treasury holds. LEGO refills work on top of that.
  3. NO staking limits setter — protocol-specific action administered by the protocol-specific actors. Node Operators use it to approve new keys to be used for staking.

LIP-19 brings another building block — “Payment processor with timed limits”. It allows the DAO to set a limit on the amount of token transfers administered by the committee during a specified calendar timeframe (monthly, bi-monthly, quarterly, bi-quarterly or yearly). The target is to create building blocks for reliable and safe payment processors for different DAO needs.

The Payment processor consists of four parts:

  1. Whitelist & Limits Registry contract — management of allowed recipients and total amounts spendable is performed here.
  2. TopUp motion factory — the contract for creating payment EasyTrack motions.
  3. AddToWhitelist motion factory — the contract for creating whitelisting EasyTrack motions.
  4. RemoveFromWhitelist motion factory — the contract for creating de-whitelisting EasyTrack motions.

Some committees (reWARDS, Referral) need to be able to send tokens to different recipients. I order to make recipients management transparent, whitelisting and de-whitelisting are performed through EasyTrack motions. LIP-19 brings all the parts necessary to cover those use-cases.

There are the cases with only a single recipient to be — RCC & Gas funding, for instance. This can be implemented with the contracts introduced by LIP-19 as well. The setup would include TopUp motion factory and the Registry contract. The latter would be 1) pre-filled with the single recipient address; 2) grant roles to manage the whitelist to the Lido Agent contract, leaving Lido DAO the option to change whitelist via the Aragon vote. Payment processing would be the same, but the whitelisting would be short-cut:

Note that in both cases Lido Agent contract would have all the roles & rights necessary to perform changes to whitelist & limits, and only Lido Agent would have the rights to change limits.
Thus, LIP-19 provides building parts for both “one committee, multiple changing recipients” and “one committee as a single recipient” scenarios. Note that LIP-19 is focused on single-token payments, so case of LEGO (single budget in two different tokens — DAI & LDO) isn’t supported. In case the single committee would be working with multiple tokens, but with separate limits/budgets, multiple instances of Whitelist & Limits Registry + TopUp motion factory setup can be deployed.