# Lido proposal

:large_blue_circle: easy to implement
:black_circle: medium to implement
:red_circle: hard to implement
:heavy_check_mark: implemented
:question: not sure about implementation

## Tier 0. Software Setup Helper

Improving the node operator’s experience in the initial and probably the most challenging stage is what such integrations might do.

Tier 0 integration must be capable of:

- [x] **Setting up Ethereum validation tools (such as CL and EL nodes, validator client and MEV-boost)**
- [ ] **Setting Lido feeRecipient in the CL node** :large_blue_circle: -> Implementation in brain
- [ ] warn users when they need to take action: message them through the Telegram warning system (or directly integrate the ejector - check for other similar utilities)

- [ ] **Generating correct deposit data for subsequent uploading into CSM** :red_circle: -> fork of deposit cli and ??
- We can let the users generate their own keys or we can generate them in the machine. In any case, there should be a check during the Deposit Data - also a check in the Brain to check that if TAG = LIDO withdrawal address needs to be a specific one. Do Sanity checks here (in Brain) and also in the UI to register (Tier 2)
- [ ] **Configuring the MEV-boost client to use relays from MevBoostRelayAllowedList** :black_circle: -> Implementation in brain, if tag === lido then configure relays in mev boost. It might require to implement a way to configure relays dinamically in mev boost.
- Is it possible to configure relays through API ??
- ⚠️ Can MEV BOOST accept keystore-level sets of relayers? (differnt sets per different keystores/validators)
- ⚠️ Can it be at consensus client level to use one MEV Boost instance or another depending on the keystore/validator? - Ask Lion
- ⚠️ If not, can we display a message to the user saying: "You are using Lido, you must choose between this subset" - and relayers outside of the subset are not selectable.
- IF at least one of the validators in the brain is tagged as Lido, restrict relayers to Lido list. https://etherscan.io/address/0xf95f069f9ad107938f6ba802a3da87892298610e#readContract
- What happens when LIDO changes this list? The solution should be dynamic. How often should we check? 1/day? then disconnect from not allowed. If that means that they are all unselected, use local builder / select 1 at random from the allowlist.

## Tier 1. Operator Statistics Monitor

By utilizing available CSM view functions, it is possible to implement a comprehensive interface that displays a node operator’s personal statistics by providing their ID. Integrations should not assume any CSM on-chain interactions other than an optional wallet connection to identify the node operator.

Tier 1 integration must be capable of:

- [ ] **Displaying NO keys and queue info: available to deposit (in the queue), stuck, refunded, exited, deposited** :black_circle:
- [ ] **Displaying NO bond and rewards info: total amount, amount lower and higher than required, non-claimed rewards** :black_circle:
- [ ] **Alerting of Penalties and Exit requests** :black_circle:

The last one is not just information to note but a specific node operator state that requires actions from them, so the integration should consider it carefully to notify the node operator explicitly.

## Tier 2. Operator Manager

⚠️ Is this expected to be local or is it simply a webapp?
Is it expected to be different than this:
- https://operators-holesky.testnet.fi/
And if so, in what aspect?

This scenario builds upon the prior tier by incorporating interactions that occur on-chain.

- [ ] **Adding a new node operator** :black_circle: **Requires write on SC**
- [ ] **Visualization of Required bond to upload keys** :black_circle: ->
- [ ] **Uploading new keys**
- ⚠️ Again, how do the keys are generated and shared with Lido? Are we referring to "uploading keys to the CSM so it can track and deposit"?
- ⚠️ What are the differences between the methods
- `addValidatorKeysETH`
`addValidatorKeysStETH`
`addValidatorKeysWstETH`
`addValidatorKeysStETHWithPermit`
`addValidatorKeysWstETHWithPermit`

- [ ] **Visualization of the Current bond amounts** :black_circle: -> Implementation in brain UI
- [ ] **Claiming rewards** :black_circle: -> **Requires write on SC**
- [ ] **Visualization of the Rewards available to claim** :black_circle: ->
- [ ] **Setting up a dedicated manager and reward addresses** :black_circle: ->

The integration need not include a graphical user interface; it could be implemented as a command-line interface (CLI) tool for Node Operator management.

## Tier 3. Full-featured operator UI

This tier builds on what the earlier tiers do and adds visual features that work really well with a graphical interface:

- [ ] **Shows Node Operator lifecycle graphs, e.g., earnings, performance, events** :black_circle:
- [ ] **Compares Node Operator with average NOs stats** :black_circle: ->