Shower thoughts about a Referral program for CSM

Hey everyone!

Anticipating the Community staking module (CSM) launch Lido DAO contributors have started considering possible ways of collaboration with Ethereum ecosystem projects to support wide participation of community stakers in CSM and develop partnerships with projects that contribute to Ethereum decentralization by providing tools for home stakers to setup and maintain their nodes and validators.
As mentioned in the initial CSM proposal, this collaboration can be built as a referral program, where ecosystem partners can get incentives by engaging their users to participate in CSM as Node Operators.

This post reflects my personal vision of how this referral program can look like. By publishing it, I want to encourage discussion amongst the Lido DAO and wider staking community to discuss different angles of such a program, so that different opinions can be taken into consideration before putting forth a referral program proposal to the DAO.

Purpose of the Referral program

Everything starts with a purpose, and a referral program is not an exception, huh

The purpose of the referral program is to establish sustainable channels of community staker engagement in Community Staking Module.

Target program participants — who they are?

Prospective participants would likely be software providers offering tools for Ethereum node/validator installation, setup, and management. Other organizations and communities (e.g. DAOs, universities, non-profits) that have potential to bring new community stakers to Ethereum might be also considered prospective participants.

Application process for participants: permissioned or permissionless?

Adopting permissionless referral participant onboarding could lead to the potential for abuse of the referral program. In light of this, my take is that the program should be managed by a Committee that is charged with vetting/filtering participants and abuse analysis/disqualification. The Committee should be established and granted authority via a DAO vote.

Acceptance criteria for the program can include presence and relevance of audits, size of the userbase, potential for growth, ease of use, list of existing features, etc.

Rewards share or dedicated incentive pool?

A rewards sharing approach is believed to be a more sustainable model of partnering rather than a limited incentives pool approach. The DAO’s previous decision to replace the initial Referral Program for Ethereum with the Tiered Rewards Share Program is a notable example of it of such an evolution to a more sustainable mechanism.

Moreover, in case of a limited pool there might be a case where bigger providers empty the pool leaving no opportunity for smaller ones to earn rewards.

From my point of view, participants should receive a share of the DAO’s staking rewards from the CSM (DAO’s part of the rewards, not validators’ one!).

Fixed or variable rewards?

In the previous paragraph I’ve outlined my take: rewards for program participants can come from the rewards share that would normally go to the DAO treasury. But how exactly?

Let’s take two substantially different methods for rewards allocation for referral partners as examples:

  1. Calculate rewards based on the number of validators initiated by the referral program participant multiplied by a fixed amount of rewards per validator (i.e. all participants get the same reward x validator)
  2. Calculate rewards based on number of active validators engaged by the referral program participant and validators performance metrics

In the option #1 all validators in the module are considered equal, meaning rewards would be smoothed between all participants. It creates room for participants to abuse the system by entering as many validators as possible that weren’t meant to be “active”. Another downside of this option is that this approach is not sustainable for both the Lido DAO and participants: sometimes the CSM rewards might be higher than average (in this case participant gets less rewards that it could’ve got), sometimes the rewards might be lower (meaning the DAO should pay bigger part of its rewards to participants).

Option 2, on the contrary, takes into account validator performance and can also take into account MEV stealing and validators operating below the performance threshold.

So, my vote is for the following possible approach:

For a participant to get rewards for the validator in the given period, the validator should meet the following requirements:

  • The validator should be active (i.e deposited, online, and not exited or slashed)
  • It wasn’t spotted in MEV stealing
  • Its performance rate is above some threshold. This performance threshold should be the same as a threshold for NO rewards.

Rewards for participants are calculated in the same way as Node Operators rewards but with the other rewards rate: referrer_rewards_rate ≤ (module_rewards_rate - operator_rewards_rate)

Rewards distribution: direct transfers or claim-based?

The CSM Performance Oracle could perform direct transfers to participants at the time of the report transaction. This approach eliminates the need for participants to manually claim rewards, streamlining the process. However, it (a) meaningfully increases gas cost overhead for the protocol, (b) may be inefficient (e.g. if the period rewards are very small, it may not be worth the transaction cost), and (c) removes optionality for recipients to who may have preferences around rewards claiming for local legal and tax reasons.

With a claim-based approach, participants can claim their rewards in the same way as Node Operators for the CSM would. This approach implements a unified claim procedure, reducing Oracle gas costs and allows participants to claim rewards on demand.

While the claim-based approach appears to be suitable, I welcome feedback from potential participants to ensure a well-informed decision.

Rewards-share structure

”Stop beating around the bush, tell me the numbers!” — you might have thought at this point…:slightly_smiling_face:

Well, at that point we’ve come to the spiciest topic — rewards for participants. So, what do we have as a constant value? A protocol rewards share = 10% that is applied on staking rewards and split between node operators, and the DAO Treasury for the Curated module. For CSM there is one more “actor” in here — the referral program participant.

Another constant value for CSM is the Node Operators rewards rate that will be set by the DAO closer to the CSM launch. So the question here is what should be the proportion of the Lido Treasury and participants’ rewards rates. There are several things that the DAO has to take into account defining this proportion. On the one hand, participants’ fee should be enough to be attractive for partners and cover their maintenance costs of the CSM integration. On the other hand, the Lido Treasury rewards rate should be sustainable to the DAO in a long-term. Another aspect to consider is the potential growth of the CSM.

Currently it is proposed to start with 1% of stake allocation, gradually increasing this share up to 10%. While, let’s say, the minimal % of the DAO rewards rate might seem acceptable for CSM having 1% of stake allocation, the same % wouldn’t be sustainable with 10% of CSM stake allocation. “But 90% of stake will still go to curated module where the Lido Treasury fee is 5%!” — it is not true actually. By the CSM launch, the Lido protocol may possibly have other modules, with different rewards-share structures. And all these modules should be mutually agreed upon.

The presence of another Rewards Share Program may also impose restrictions on the overall economic structure of the entire NO set.

So the rewards-share structure for such a program, as well as its duration, are still unsettled for me and requires a holistic analysis by the Lido DAO, as well as the opinions of DAO members and potential participants.

Okay, why did I even write all that?

Although the CSM is expected to be launched in Q3-Q4 2024, it is already important to identify some configurations that require additional development for this program. It is equally important to provide insight into the potential of such a program for providers who may be interested in participating.
I see this post as a starting point for discussions about the possibility of launching such a program and its design. I invite community members to share their opinions and thoughts on the aspects outlined.