April Slashing Incident: Key Limit Follow-up

Summary

This vote is a signaling vote intended to gauge community sentiment with regards to whether and when RockLogic GmbH (“the Node Operator”) may resume increasing their validator count. There has been discussion on the forums with regards to what the general approach should be following node operator-related incidents which may cause a large impact (financial or otherwise) to the protocol and protocol users. This vote seeks to get community sentiment on the options having been discussed so that closing actions can be taken.

Context

In April 2023, a slashing occurred involving validators operated by the Node Operator (for more details please see the post mortem, and the detailed discussion on the forums). As a part of incident response measures, a key limit was voted in by the DAO, limiting the total number of validators (also referred to as “keys”) being operated by the Node Operator to a maximum of 5800 (less the 11 slashed means 5789 which are currently active); note these are slightly more validators than the operator was running at the time of the slashing. The slashing resulted in relatively minor financial penalties to stakers, which were covered through use of the DAO slashing cover fund, as voted on by the DAO. Since then, the Node Operator has performed remediative actions improving their internal processes and node infrastructure, the technical issue with the Prysm key manager has been fixed, and steady updates have been provided by the node operator throughout the process detailing their actions and the resulting improvements.

An analysis using a framework for consideration of next steps after a slashing was employed examining the facts and circumstances around the event, follow up actions, and the current state. This analysis is currently being discussed on the forums, and based on discussions two directions / options seem to be prevailing. This vote seeks to determine whether the general community is aligned with either of these options, or a possibly a different direction.

The full list of possible options as proposed in the framework is:

• Do nothing
• Warning (do nothing w/ the condition that the next time the consequence is one/any of the below)
• Limit the Node Operator’s key count for a certain period of time
• Decrease the Node Operator’s key count (by prioritizing those keys for exit)
• Offboard the operator (with the ability to rejoin the permissioned set at a later time)
• Offboard the operator (without the ability to rejoin the permissioned set at a later time)

Based on analysis of the facts as per the framework, taking into account the nature of the incident, its impact, follow-up actions, and the Node Operator’s overall value/participation in the ecosystem, the two options being discussed are variants of the “Limit the Node Operator’s key count for a certain period of time” consequence, since a key limit was already placed on the Node Operator shortly following (on April 18th) the slashing. The first option suggests to lift the limit immediately, and the second option suggests to lift the limit once the next cohort of Lido on Ethereum operators (aka Wave 5*) has been onboarded and caught up in terms of stake allocation. A third option, “None of the above” has also been added for those who wish to express that neither of the aforementioned options is agreeable, or to indicate further discussion and consensus building would be necessary. Community consensus is important to be able to conclude the overall matter, and so that the Node Operator will have clarity with regards to what their next steps should be.

*The Wave 5 onboarding round has been suggested to take place in two stages:

• Stage 1 is nearing completion, as the DAO has voted to add two new operators to the Lido on Ethereum operator set, and the operators are currently going through testnet onboarding
• Stage 2 is underway, with an estimated completion date of early September for the evaluations, and late September / early October for mainnet onboarding of new additions

Actions

Vote “Lift Key Limit (KL) immediately” if:

• you agree that none of the more strict options are relevant in this case (e.g. offboarding the operator)
• you agree that the Node Operator may increase their validators as soon as they are ready to

Vote “Lift Key Limit (KL) after Wave 5 catches up” if:

• you agree that none of the more strict options are relevant in this case (e.g. offboarding the operator)
• you agree that the Node Operator may increase their validators, but only once the next cohort of operators has joined and reached (any of the cohort members, not all) a number of validators roughly equal to the number of validators that the node operator is currently operating (~5800)

Vote “None of the above” if:

• none of the above rationales & actions are agreeable, or
• you believe that additional discussion or analysis is needed