Community Staking Module Committee

Proposals
21

GM!

Here is a quarterly update from the CSM multisig committee for Q2 2025. During Q2 2025, no incidents were identified that resulted in reported MEV stealing by the committee.

There were 2 incidents that led to a block being proposed with a null fee recipient.

Node Operator 91 self-reported an issue related to a client. The block reward was compensated directly to the Lido EL Rewards Vault.

Node Operator 57 self-reported a misconfiguration issue and compensated the block reward directly to the Lido EL Rewards Vault.

In both cases, the committee members agreed that there was no malicious intent and no additional fee was necessary.

3 Likes
22

I’m happy to see the MEV Stealing prevention system working! This report is a clear indicator of that. No reported penalties and just two unfortunate situations with the config, followed by immediate compensation. Robust!

3 Likes
23

GM!

Here is a quarterly update from the CSM multisig committee. There were no transactions in Q3 2025, so the update covers Q4 2025.

No incidents resulting in reporting MEV stealing were identified by the committee. That said, the committee has an additional responsibility since CSM v2 that was not outlined in the original post: adopting the Community Stakers Identification Framework and initiating an update of the ICS trees on-chain.

Following the completion of 2 ICS rounds in Q4 2025, the following EasyTrack motions have been started by the committee:

All motions were executed and the ICS data was updated in CSM contracts on mainnet.

3 Likes
24

Hello CSM community– I’m writing to formally ask the CSM committee to halt the unbonding for the validators under CSM #34 – the underlying wallet was compromised in social engineering attack peginsurance.eth | Address: 0x6bd36310...6f8d0fd13 | Etherscan

5 Likes
25

Since @MF_DROO self‑reported ownership of operator #34 and the CSM committee has reason to believe that the incident occurred and the operator was seized by an unknown actor, the committee has temporarily locked the bond of the aforementioned operator. The lock will expire in 8 weeks, and should it be extended, the CSM committee will consider a separate request.

The confirmation transaction can be found below:

4 Likes
26

RE: Lock Extension
how it is going with verifying the incident and any further steps for me?

1 Like
27

Contributors are still evaluating options, and the analysis is ongoing. It would be fair to prolong the lock until the final resolution.

2 Likes
28

The committee cannot advise on further actions at the moment and has agreed to extend the bond lock in the meantime. An additional 100 weis have been locked to extend the lock until Jun 29. The confirmation transaction can be found below.

3 Likes
29

While Lido contributors are heads down preparing for the upcoming release of the staking router and the modules, the committee has agreed to extend the current lock. The new lock expires on Aug 21. The confirmation transaction can be found below.

2 Likes
30

Proposal to add SimpleDVT Home and Community Stakers to ICS

The recent proposal to wind down the SimpleDVT Module regular clusters, which passed DAO vote on June 22nd, established that Home and Community Stakers from SimpleDVT would be eligible to claim the Identified Community Staker (ICS) operator type if they don’t already have it.

In line with that decision, this post presents the proposed list of new ICS participants for the Community Staking Module Committee’s consideration, along with the reasoning and the checks performed, so that the committee can make an informed decision about adding them to the ICS list.

Proposed list
The proposed list was formed as follows:

  • All Home and Community Staker participants from SimpleDVT were included;
  • Participants that already have ICS or have any of their addresses already present in the ICS list were excluded;
  • Participants that have their addresses associated with an ICS operator were excluded.

List: [SimpleDVT] Proposed Home and Community Stakers for ICS - Google Sheets
(IPFS version: https://ipfs.io/ipfs/bafkreicqwciedu5qlvda67m6w5s2d2gdosxabznnehaodoswq6vv5j2q34)

Next steps
The CSMC will now review this addition, and if approved, the list will then be updated via Easy Track motion. If the motion passes as well, the participants will be able to claim the ICS type and start participating in CSM as an ICS operator or join as part of an Identified Distributed Validator Technology Cluster (IDVTC) operator.

5 Likes
31

Subject: Addressing the CSM Data Void: Transitioning from Static Sheets to Automated Analytics

Hello Lido DAO Contributors, @dgusakov, and @remus,

The recent update from @remus regarding the migration of SimpleDVT Home and Community Stakers perfectly highlights a looming operational bottleneck for the CSM Committee.

Currently, the onboarding and review process relies on static data artifacts (Google Sheets/IPFS lists) to verify ICS operator eligibility. While this works for a one-off migration, expecting the CSM Committee’s domain experts to manually parse static sheets, cross-reference on-chain performance, and calculate bond-health across thousands of future permissionless nodes is not a scalable operational model. It introduces massive administrative friction.

Furthermore, as the original proposal outlines, the CSM Committee holds “override” permissions. If they are executing these overrides based on manual data wrangling rather than a unified, real-time framework, it creates a political liability regarding subjective governance.

The Proposal: An Independent CSM Data Architecture & Override Rubric

To protect the Committee’s bandwidth and eliminate subjective data-wrangling, I propose an independent mandate to build the following framework before the CSM scales:

1. The Automated CSM Validator Dashboard:

Transitioning the CSM from static spreadsheets to a centralized, automated data pipeline (utilizing Dune/SQL and real-time node metrics). This dashboard will automatically track the permissionless fleet, flagging eligible ICS participants and triggering automated “Alert States” when an operator’s LDO/ETH bond approaches critical thresholds.

2. The Objective Intervention Rubric:

A strict, data-driven framework that defines the exact on-chain conditions (slashing thresholds, prolonged downtime) that must be met before the CSM Committee is authorized to execute a manual override. This legally binds the Committee to objective metrics, eliminating centralization fears.

Strategic Value:

By contracting an independent Data Architect to build this Analytics Dashboard and Intervention Rubric, the CSM Committee can launch with bulletproof oversight tooling. The Committee members can focus on execution and DVT strategy, rather than manual spreadsheet verification.

If the delegates and workstream leads agree that automated data infrastructure is critical for the CSM’s scalability, I am prepared to draft the technical scope for this architecture.

32

Thanks for the proposal, @JulianCross!

The case above (that you refer to as a bottleneck) is a one-off case related to Proposal: Wind Down the Simple DVT Module Regular Clusters. Other ICS assessments are done automatically based on the on-chain data and other public information. Anyone can verify the assessment results using scripts - staking-modules/ics_assessment at develop · lidofinance/staking-modules · GitHub that are updated after each assessment round to include the latest data. Hence, I see no need for additional automation here.

It is also worth noting that the points you mentioned (slashing conditions and other stuff) are not related or not directly related to the ICS Framework - Identified Community Stakers Framework.

1 Like
33

Due to missing data about ICS round 5, the analysis of the address was not complete. Taking the latest data into account, the following address should be removed from the proposed list:

Colinka | BeeHive,Community Staker,0x28E3C898d305B535Be6Ae5Ae20f1F79C44c584cB
dimsome,Home Staker,0x25109b421f7DF83DCF025025C56358263189D347
hukutu4 | BeeHive,Community Staker,0xe62638ed1afd68d0ad250dafd68c69b28e9e011e
sodiumstar,Home Staker,0x3cc04875E98EDf01065a4B27e00bcfeDdb76CBA8

These operators have applied and were approved in the ICS round 5.

Updated IPFS link - https://ipfs.io/ipfs/bafkreifo46unquyjfkfpew7gpt2v4m4kkjr7fx3nbpiym46vocrj4mido4

1 Like
34

Based on the CSMC decision the updated of the ICS list has been included into the Easy Track motion - Motion #1067 | Lido

35

GM!

Here is a quarterly update from the CSM multisig committee covering Q1 and Q2 2026 (yes, “quarterly” is doing some heavy lifting this time).

MEV stealing

Q1 2026

During Q1 2026, the committee identified and reported 2 incidents of block proposals with an incorrect fee recipient, resulting in EL rewards stealing penalties. A detailed breakdown can be found in the table below.

Slot NO Validator Amount (round) Transaction
13359274 516 2179449 0.00604 ETH 0xa915…10fc
13399448 446 2117354 0.00364 ETH 0xa915…10fc

Both penalties were reported together on Jan 8, 2026. Both operators have since compensated the reported penalties in full (stolen amount + the 0.1 ETH fixed fine), and no further action is required:

Q2 2026

During Q2 2026, no incidents resulting in reporting MEV stealing were identified by the committee.

Node Operator #34 – bond lock (seized operator)

Following @MF_DROO’s self-report that Node Operator #34 had been seized by an unknown actor, the committee used the penalty mechanism to temporarily lock the operator’s bond, protecting it while the situation is assessed. The lock has since been extended twice. Each action was announced separately in this thread:

  • Initial lock – the operator’s bond (~16.05 ETH) was locked for 8 weeks, until May 11, 2026. Tx 0xf645…2a9b.
  • Extension #1 – the committee extended the lock until Jun 29, 2026. Tx 0x0e21…dc2e.
  • Extension #2 – the committee extended the lock until Aug 21, 2026. Tx 0x5410…232a.

ICS tree updates

Following the completion of the ICS rounds, the committee started the following EasyTrack motions:

Q1 2026

Q2 2026

All motions were executed and the ICS data was updated in the CSM contracts on mainnet. The latest tree state on-chain corresponds to Motion #1039:

  • Tree root: 0x897c27523df17a9f5513651c006b75cba576d3dad2a13dd2334cb50c6b5a003e
  • Tree CID: bafkreigiuxjg7vkjti4ynydrhyr47fit3c5n7peqogehunba2gxignhrqu
3 Likes
36

@dgusakov Understood, and thank you for the direct clarification. If the Python scripts in the staking-modules repository are fully handling the ICS assessment loops without manual bottlenecking, then additional automation redundancy here is unnecessary.

I will review the repo and pivot my analytical focus toward the CMv2 Penalty Framework, where subjective override friction seems more prominent. Appreciate the transparency.

1 Like