# CSM Early Adoption

## TL;DR
This document describes a possible approach to the CSM Early Adoption mechanics. It is proposed that a Merkle proof be used as an entry ticket to the CSM on the mainnet during the Early Adoption period. A maximum number of keys per operator is limited to 10 during the Early Adoption Period. On top of the ability to join, such node operators will be eligible for the "bond discount for the first validator".

## Motivation
An Early Adoption period is required to ensure meaningful community stakers' participation in CSM and avoid immediate occupation of all CSM capacity by one or several professional operators. During this period, only curated community stakers are eligible to join CSM. After the end of the period, CSM entry is fully permissionless. To make Early Adoption more attractive for the community stakers, extra benefits like the one described in Appendix 1 should be offered.

## Who is eligible
The CSM has two primary sources of stakers eligible for Early Adoption - [**Rated's list of solos**](https://github.com/rated-network/solo-stakers), and [**Lido CS community participants**](https://www.notion.so/CS-OATs-list-781199daef6046a8ba09941112931fc0?pvs=4), namely OAT holders with sufficient scores at Galxe's Lido space. The best way to get a sufficient Galxe score is to participate in the SimpleDVT/CSM testnets or Lido-hosted events. Both lists might be combined into one before the launch, so there will be no difference in trust and conditions between them.

## Why are per-operator keys limited?
Despite the fact that only curated community stakers will be eligible to join CSM during EA, there is still a chance that huge Node Operators will find a way to pretend to be a community staker. To mitigate the risk of CSM capture by such sophisticated actors, it is proposed to set a **hard limit of 10 validators per operator during the EA**. This will significantly restrict possible options for the huge operators to occupy a significant portion of the CSM stake during EA.

## Using Proof on the CSM side
Implementation of Early Adoption is laying on the separate (might be virtual) CSEarlyAdoption contract with preliminary the following interface:

interface ICSEarlyAdoption {
    function checkAddress(address _address, bytes32[] proof) external view returns (bool);
    function consume(address _address, bytes32[] proof) external;
}

The tree root is only set in the deployment stage and will not be changed afterwards.
During the Early Adoption period, proof is required when `createNodeOperator*` methods are executed to ensure the sender is eligible to join and consume a proof.

    function addNodeOperatorETH(
        uint256 keysCount,
        bytes calldata publicKeys,
        bytes calldata signatures,
        bytes32[] calldata proof
    ) external payable {
        uint256 id = _createNodeOperator();
        
        if (earlyAdoption.checkAddress(msg.sender, proof)) {
            earlyAdoption.consume(msg.sender, proof);
            accounting.setBondCurve(id, earlyAdoptionBondCurve);
        } else if (block.timestamp < earlyAdoptionExpireTimestamp) {
            revert EarlyAccessDenied();
        }
        
        
        accounting.depositETH{ value: msg.value }(msg.sender, id);
        _addSigningKeys(id, keysCount, publicKeys, signatures);
    }

It is proposed to configure a timestamp of when this period ends explicitly on the deployment stage, after which an Early Adoption contract will be ignored, allowing everyone to join CSM. The DAO should be able to change this timestamp later to extend or shorten the duration of an Early Adoption period.

*Operation during EA period*

A Merkle proof might be passed as an optional argument after an Early Adoption period in order to receive Early Adoption incentives.

*Operation after EA period*

## Appendix 1. Incentives for the Early Adopters

### Using CSM bond curves as the incentive for the Early Adopters
Several interesting use cases emerge with introducing the arbitrary [bond curves](https://hackmd.io/QmMkXEjbR1e8IFgN-6yC_g?view#Bond) in CSM. One is to create a specific curve assigned to the Node Operators joining CSM during the Early Adoption period.
#### Early Adoption bond curve
One of the main ideas of the Early Adoption period is to allow proven solo-stakers (from the rated list or identified by Lido contributors) to join CSM during its early stages on the mainnet, prior to the full-permissionless launch. If we assume that CSM mainnet params (bond size and fee) will be something way better than the other market offers, the ability to join it earlier is a benefit on its own. However, if CSM offers "in-market" conditions, there should be some benefit for the early adopters that will incentivize them to join CSM.

One of the options here is to lower the entry barrier in terms of the ETH bond required. With bond curves in place, this might have a form of a modified curve where the **bond required for the very first validator is lower than in the common curve**. At the same time, the rest of the curve is identical to the common one.


When selecting the bond value for this first validator, it should at least cover individual slashing risk. Other risks can be set aside. Here is why:
- MEV stealing
- With only one validator chances of `block_proposal * huge_MEV * malisious_validator_in_the_list` are negligible
- Stale validator
- With a bond covering basic slashing, it will take a single validator about two years to acquire a balance drop exceeding the bond.
- What if Node Operators will create more validators?
- In this case, they will have to supply regular bond amounts for the second and further validators. Hence, total coverage will not differ much from the common curve case.

That said, it is assumed that the "get first validator cheaper" approach might be used as an incentive for the CSM Early Adopters.

## Appendix 2. Common NFT cost considerations
It is possible to mark all eligible addresses by minting an NFT instead of a proof check. It turns this list of stakers into a potential public good as permanent on-chain storage of solo stakers in order to reuse it for other protocols. Unlike a common EIP-721 implementation (e.g. [from OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/api/token/erc721)), there will be the following limitations:
- **Non-transferable**;
- **One NFT per address**;
- **Non-burnable.** Any consumption of NFTs should be accounted for on the protocol side;
- **One-time use.** One NFT equals one use on the protocol side;

The current OpenZeppelin's implementation with such limitations will have the following rough cost estimations:

50000 gas per mint =>
60 gwei gas cost =>
~0.32 ETH per 100 mints

An alternative implementation like [TokenGate](https://github.com/7i7o/TokenGate) might have much lower gas costs:

26000 gas per mint =>
60 gwei gas cost =>
~0.15 ETH per 100 mints

Due to these estimations and the additional cost of implementing such NFT with restrictions and audits, it isn't reasonable to go that way. Hence, a Merkle Proof solution is much less expensive.

## Appendix 3. Mint NFT for Early Adoption node operators

When the Early Adoption period is over, a special, memorable NFT might be minted for all CSM participants. The simplest is OAT at Galxe, but it also might be a separate NFT contract with a unique image on each NFT, like Node Operator ID at CSM, validators graffiti, etc.