[DIP-29] Increase of validator limit per operator

[Ivan]

Proposal Summary

This proposal, if passed, will require the ssv.network DAO Multi-Sig Committee (hereinafter: “MC”) to batch and execute relevant transactions to update relevant smart contracts to enable operators on the ssv.network to run operators with 1000 validators per operator, from the previously available 500 validators per operator.

Motivation

Ever since the launch of the ssv.network mainnet in December 2023, operators were limited to having only 500 validators per operator. This was due to the DAO’s research showing that at that point in time, having a higher limit would result in an unreasonable resource usage on operator machines and would make the ssv.network less efficient as a whole. However, this limit increase has been requested by both the professional and solo operator community for a very long time.

Therefore, since December 2023, the DAO has understood that this limit needed to be raised. With this in mind, the DAO has been hard at work to optimize resource usage and increase this cap in order to reduce operational overhead for operators and satisfy the ssv.network community’s needs. This has been achieved with the new Alan fork, which went live at the end of 2024. Now, with sufficient statistical data, the initial cap can be raised to 1000 validators per operator while maintaining the existing computational resources used. This effectively reduces operator overhead.

This reduction in overhead will result in more streamlined operations for operators, less cost and potentially improved performance across the board.

Proposal particulars

1. ssv.network Specification
2. Execution Parameters

ssv.network Specification

This proposal announces that the basic requirements in order to be interoperable with the ssv.network are going to change. All future tools building on top of the ssv.network will be required to enable operators to have a total validator count per operator at 1.000 validators.

These basic requirements are maintained by the development services provider of the ssv.network DAO.

Execution Parameters

The proposed upgrade includes the functionality of enabling operators to have 1.000 validators per operator.

To implement this modification, the SSVNetwork contract will be upgraded to update the state variable validatorsPerOperatorLimit from 500 to 1000.

The SSV Labs team will deploy a new contract implementation that includes an initializer function specifically designed for this update.

Once deployed, the MC will execute the contract upgrade process and invoke the initializer function with the parameter 1000 in a single transaction.

[BenAffleck]

Calling all DIP-25 delegates. Please let us know your thoughts.

@fod
@spookyg
@derfredy
@h.m.23-0neinfra
@markoinether
@axblox
@flo
@thomasblock
@yuting
@damon
@lemmagov
@llifezou
@Blockside
@sigmaprime
@kenway
@hashkeygov
@Ethernodes
@chainupgov
@kiln
@Allnodes

[Ethernodes]

Ethernodes fully supports this proposal to increase the validator limit per operator to 1,000, as it brings key benefits to the network and its participants:

1. Enhanced Scalability & Security – Increasing the capacity per operator will help scale the network more efficiently, making it more secure and operationally viable for Node Operators.
2. Optimized Network Structure – By reducing the total number of full operators, the network will operate with greater efficiency, benefiting both operators and users.
3. Right Timing Post Alan Fork – The recent Alan fork has significantly optimized resource consumption per operator, making this the ideal moment to increase the validator cap without adding excessive overhead.

With these improvements, this upgrade aligns with the network’s long-term vision of efficiency and sustainability.

— Ethernodes Team

[flo]

if the conditions/circumstances changed over time like described it sounds very reasonable to increase that limit.
furthermore, as already stated by @Ethernodes the timing seems to be absolutely right.

[AXBLOX]

I support that proposal because, thanks to the recent Alan fork optimizations, the network can now double the validator cap from 500 to 1,000 without requiring extra hardware. This means operators can run more validators on a single setup, reducing the hassle of managing multiple instances and saving on costs.

Plus, with the upcoming SSV 2.0 upgrade bringing in Based Applications Chain, bumping up the validator limit per operator means the network will be better equipped to handle these bApps, making SSV 2.0 more robust and scalable.

[Blockside]

I see the increase in the validator limit as positive, since Alan’s update made the hardware requirements manageable for home users with inexpensive SBCs as well, and this ensures equal opportunity. Although there are security issues (operators become more attractive targets for attacks and power outages/software problems would have a greater impact), I think the proven resilience of a SSV Validator compared to Solo Validator makes this a viable proposal that will encourage the growth of validators into SSV.Network.

[Kenway]

Sounds good, we expected this feature for a long time.

[llifezou]

After the upgrade from Alan’s fork, ssv-node is fully ready. Increasing the validator limit is very important for improving machine resource utilization. Fully support it!

[Yuting]

I’m largely in favor of DIP-29. It’s a remarkable achievement, especially given the success of the Alan fork, which has significantly lowered the resource requirements for operators. The fact that we can now double the validator cap without needing extra hardware is a testament to the hard work of the SSV team.

However, I do have some concerns about the potential for increased centralization. While the proposal aims to streamline operations and improve efficiency, I wonder if increasing the validator limit might inadvertently favor larger operators.

I’m not entirely sure, but perhaps we should consider implementing mechanisms to encourage smaller operators and maintain a healthy distribution of validators across the network. This is just a question I’m putting out there – I’m not certain if it’s necessary, but I think it’s worth exploring to ensure the long-term health and decentralization of the SSV network.

[hashkeygov]

This proposal to double the validator limit per operator to 1000 is excellent news. The community has been requesting this for a long time, and it’s great to see the DAO and development team deliver. The increased limit will significantly reduce operational overhead for operators, leading to cost savings and potentially better performance. The work done with the Alan fork to make this possible is commendable. We fully support this proposal.

[chainupgov]

I support the proposal. The performance of validators running on ssv has improved for a long time, now it is time to increase the limit of the number of validators for ssv Operator.

[kiln]

Totally support this proposal.
Increasing the validator limit is important for optimizing machine resource utilization.

[Gufete_DragonStake]

[SSV Network Governance] [Proposals/DIP (DAO Improvement)] [DIP-29] Increase of Validator Limit per Operator

The SSV binary has improved significantly—it now consumes fewer resources and supports multiple CL/EL setups. This is a great step forward in terms of efficiency and flexibility.

As a team, we are generally in favor of increasing the validator limit per operator. However, one aspect we are not entirely convinced about is the fixed (or mayority) 4-node clusters in SSV. We prefer the approach taken by Lido, where clusters consist of 7 nodes, as it provides additional redundancy and decentralization.

On the downside, increasing the validator limit per operator could impact how the exporter retrieves data. A setup with more operators managing fewer validators each might be better for performance, especially in tools like SSVScan, which rely on efficiently querying operator data.

That being said, DragonStake will vote YES on this proposal, as we believe the benefits outweigh the potential drawbacks.

We look forward to hearing other perspectives on this!

[SigmaPrime]

Sigma Prime supports DIP-29 and commits to implementing the proposed validator limit increase in the Anchor client upon successful approval.

[LemmaGov]

LemmaGov supports DIP-29.

We have no hesitation in supporting this upgrade, based on the demands communicated by the operator community and the performance improvements unlocked by the Alan fork (89% reduction in CPU usage, bandwidth requirements down 70%, and overall operational improvements in disk activity).

An increase from 500 to 1000 is conservative from our point of view.

Excluding product and technical improvements, it is worthwhile to consider how this impacts the operator set composition. It is important that we keep an eye on these changes, which are likely to benefit larger operators as commented by @Gufete_DragonStake.

Overall, this is a parameter change justified by improvements to the technology.

Hugo

[fod]

I support this proposal, as an operator. Operator nodes can handle the increase, and this will improve the overall efficiency and economics of the network.

[damon]

Support this suggestion.
It will optimize the network structure and reduce the workload of operators.

[h.m.23-0NEinfra]

Fully support this proposal. This is a great improvement in node resource utilization enabled by increasing resilience of SSV.network.

[markoInEther]

I think it is about time. From my experience and also monitoring the operators there do not seem to be data indicating issues with this increase.
Low limit & necessity to launch more operators increases the overhead.

[BenAffleck]

Voting is now live. https://snapshot.box/#/s:mainnet.ssvnetwork.eth/proposal/0x0c3795a0f0dd1ac99c62f9ee4e2acc89421756605d7611de97759add211173ff