# Possible tech approaches to the CSM Referral Program

This document addresses the question of the feasible technical options for the CSM Referral Program. Three options are considered.

## Initial assumptions
To keep this document focused on the technical part and given the absence of the approved CSM Referral Program details, we assume that a Referral Program looks like this:
- CSM Node Operator can be created with the optional referral address;
- The referral address can not be changed, removed, or added after the Node Operator creation;
- To be eligible for the referral rewards, the Lido DAO should approve addresses;
- If the Lido DAO does not approve the referral address set for the Node Operator, it is not eligible for referral rewards and is ignored;
- Approved referral addresses are eligible for the portion of the Node Operator's rewards previously allocated to the Lido DAO treasury. Hence, there is no difference in the rewards for the Node Operators with and without referral address set;
- Referral rewards are proportional to the Node Operator's rewards and follow the same rules. Hence, the performance threshold is applicable in the same way;

With that said, we need to come up with a solution capable of identifying Node Operators with the approved referral address and assessing their performance in the same way as CSM Performance Oracle does. Also, an on-chain registry of the approved address can be useful.

## Possible implementations
### Option A. CSM Performance Oracle
The most straightforward approach is to use the existing CSM Performance Oracle to distribute referral rewards. This application already has all the information needed to calculate referral rewards. A separate type of reward recipient can be introduced to ensure the separation of the Node Operator's and referral rewards.

The main caveat with the approach is that we have to alter the existing Staking Router fee approach. Currently, there are two separate params for the `moduleFee` and `treasuryFee`. Once set, a dedicated portion of the rewards will be minted to the module and the Lido DAO treasury, respectively. That means that CSM Performance Oracle will be only capable of distributing `moduleFee`. To overcome this, we need to set `moduleFee` to 10% and `treasuryFee` to 0%. Then, CSM Performance Oracle will distribute Node Operators' rewards and referral rewards. The rest will be pushed back to the Lido DAO treasury. Referrals can claim rewards in the same way Node Operators do.

The proposed fee structure (`moduleFee` 10% and `treasuryFee` 0%) might look confusing for the Lido DAO members and Lido protocol users. That's why it is important to emphasize the following:
- The real fee structure is X% to the Node Operators and Y% to the referrals or Lido DAO in case of no referral for the Node Operator. This distribution is reached using CSM Perf Oracle.
- Once the referral program is suspended (based on the DAO decision), `moduleFee` will be set to X% and `treasuryFee` Y%

#### Pros
- Fully automated approach;

#### Cons
- The fee system needs to be changed;

### Option B. Distribution by a dedicated committee
The alternative approach is to create a dedicated committee responsible for distributing referral rewards manually. The same approach is used for the existing [reward-share program](https://research.lido.fi/t/tiered-rewards-share-program-a-sustainable-approach-to-steth-growth/4851).

This approach will not require any changes to the existing fee distribution. However, it is apparent that operating a dedicated committee is a resource-consuming task that one can consider unsustainable in the long term.

#### Pros
- Usage of the existing and battle-tested approach;
- The actual referral program can be implemented after CSM launch. CSM needs to be capable of only accepting referral addresses upon Node Operators creation;

#### Cons
- Substantial operational burden;
- A separate tool for the rewards calculation is required;
- A dedicated EasyTrack to make direct transfers to referrals is required;

### Option C. Mixed approach
Given the two approaches above, a mixed approach can be introduced. In this approach, the `treasuryFee` is still allocated to the Lido DAO treasury, and a dedicated committee decides on the portion of rewards to be taken from the treasury retrospectively to a standalone vault. Then, CSM Performance Oracle calculates referral rewards distribution and submits it in the form of a Merkle tree root to the vault. Once a new tree root is submitted, referrals can claim their portion of the rewards in the same way Node Operators do in CSM.

#### Pros
- Partially automated approach. Actual rewards are calculated automatically and only total sum should be requested by the committee;
- The actual referral program can be implemented after CSM launch. CSM needs to be capable of only accepting referral addresses upon Node Operators creation;

#### Cons
- Substantial operational burden due to a dedicated committee creation;
- A separate vault smart contract is required;
- A dedicated yet simple, EasyTrack is required to fund the vault;

## Decision outcome
After a series of internal discussions ValSet value stream contributors decided to go with the **Option A**.