---
title: Lido Token Reward Program (TRP) vesting contract discussion
tags: TRP, discussion, DAO
author: Dmitry Gusakov
---

# Lido Token Reward Program (TRP) vesting contract discussion

> **Disclaimer**
> In this doc, we describe only tech specs and requirements for the vesting escrow smart contracts that might be used for Lido TRP in the future.
> This doc has nothing to do with Lido TRP policy.

## Abstract

To make Token Reward Program (TRP) vesting for the Lido DAO contributors transparent, accessible, and tax optimized, we need a smart contract(s) that will control all TRP vesting operations.

## Stakeholders

- Konstantin L - leadership
- Vasily S - leadership
- Eugene P - protocol
- Eric H - legal
- Adrian C - finance
- Izzy - consultant

## Stakeholders' requirements

TRP vesting contract should:

- Handle vesting with cliff (ex. 1-year cliff + 4 years vesting) of multiple TRP packages for each contributor individually
- Actual vesting params should be configurable at the start and immutable in the future
- Allow tax-optimized withdrawals as an option.
- Contributors can choose to use tax optimization or not.
- Tax optimization should allow a contributor to prove that vested tokens do not belong to him/her until the withdrawal. One of the options is to add an admin method that will enable DAO to revoke all tokens from the vesting contract.
- Allow contributor to obtain the currently available amount of the tokens awailable for claim
- Allow delegation of the voting power of the tokens under vesting
- Allow termination of the vesting in the case when the contributor terminates relations with DAO
- Allow contributor to obtain all current vesting (in the case of Factory, there will be a new contract per each vesting)

Also, it is worth having TRP UI for contributors' comfort. TRP UI should:
- Allow connecting wallet to:
- View all vesting data. Locked tokens, vested tokens, cliff time, etc.
- Claim vested tokens

## Analysis

### Possible caveats

- Handling withdrawals from multiple TRP packets
- Changing recipient address to withdraw tokens. Should we do it, or should we not?
- Unblocking quantization (per month, per block, etc.). By default, it will be per block. We need to confirm with Legal that it works for us

### Existing solutions to consider

- https://github.com/banteg/yearn-vesting-escrow
- Vesting, cliff, suspend feature
- No tax optimization
- https://github.com/makerdao/dss-vest/blob/master/src/DssVest.sol
- Vesting, cliff, suspend stuff
- No tax optimization
- [Aragon Token Manager](https://etherscan.io/address/0xf73a1260d222f447210581DDf212D915c09a3249)
- Vesting built-in
- No tax optimization
- https://www.0xsplits.xyz/
- [Simple vesting](https://docs.0xsplits.xyz/modules/vesting) (with no cliff)
- No tax optimization
- https://llamapay.io/
- [Vesting with cliff](https://llamapay.io/vesting/create)
- No tax optimization
- https://sablier.finance/
- Built-in vesting. No cliff
- No tax optimization
- https://www.superfluid.finance/
- Built-in vesting. No cliff
- NO support of the ETH Mainnet
- Looks like there is no tax optimization and vesting
- https://docs.openzeppelin.com/contracts/4.x/api/finance
- In paymentSplitter payments are split by shares and not the amount
- Vesting contract allows simple vesting with no cliff and for individual beneficiary address

### Summary

[Yearn vesting escrow](https://github.com/banteg/yearn-vesting-escrow) seems to fit most of our needs. It already has the following:
- Vesting
- Cliff
- View methods to obtain currently locked and vested amounts
- Vesting termination mechanism with the withdrawal of unvested tokens (required for cases when contributor terminates relations with DAO)

What is missing:
- Tax-optimized withdrawals
- Voting delegation

## Proposed solution

The solution is proposed based on the internal discussion with Protocol and Automation teams.

### Contracts

Use [Yearn vesting escrow](https://github.com/banteg/yearn-vesting-escrow) as a base.

Proposed changes:

- Rename `rug_pull` to `revoke_unvested`
- Add a second type of vesting escrow with the `revoke_all` method that will allow DAO to withdraw all the funds from the escrow
- Add a `aragon_vote` method for Aragon voting, a `snapshot_set_delegate` method for Snapshot voting delegation, and a `delegate` method for further voting power delegation with all available tokens on the contract's balance. Make these methods operate over upgradable middleware to encounter possible changes in voting interfaces
- Refine events and existing methods

A detailed description of the contracts with proposed changes can be found [here](https://hackmd.io/FZEW9MM7QwmUehFtKDmqnw)

### UI

After contracts deployment, implement UI for contributors' comfort that will:

- Suitable for upload on IPFS
- Allow connecting wallet to:
- Claim vested tokens
- View all vesting data
- Locked tokens
- Vested tokens (available for claiming)
- Overall vesting graph (time/vested) displaying all vesting periods with current DateTime point marked

          //  #Graph example#
          //
          //  available tokens
          //   |                                     _/------------
          //   |                                   _/
          //   |                                 _/
          //   |                               _/
          //   |                             _X - you are here
          //   |                           _/
          //   |                         _/
          //   |                        /
          //   |                      .|
          //   |                    .  |
          //   |                  .    |
          //   |                .      |
          //   +==============+========+==============+============---> time
          //        vesting start    cliff end      vesting end        

**Note:** Yearn contracts already have events for each new vesting deployed, so there is no need to implement the view method for all recipient vestings