[TEMP CHECK] Fixes to Recent Issues with Public Operator Economics

Proposals
1

> The following Temp Check was brought forward by some of the core contributors, and the SSV Foundation was asked to post it on the forum and facilitate the discussion and voting around it.

[TEMP CHECK] Fixes to Recent Issues with Public Operator Economics

Recently, SSV’s operator economics have not been a high priority, and the current state is one where likely no public operators are running profitably. This has been growing into a serious problem where we risk a large number of operators shutting down. Beyond the consequences to our operator set, there could be a significant impact on staking customers using public operators in the case of a mass exit of those operators.

The DAO has brought forward a comprehensive and likely complete set of problem statements and potential approaches with [TEMP CHECK] Revisiting the Operator Marketplace and Fee Models, but it ended up being too convoluted and hard to decide on by the DAO.

However, among the many issues presented there, what stands out is the inability to feasibly adjust operator fees to SSV token volatility and the effects of validator consolidations after EIP-7251 (i.e., Pectra Update).

The many other improvements to the operator market that have been suggested should be acknowledged, but for the sake of forward progress, this temp check will focus on the foundational issues that already seem to have a strong consensus. The following tasks (ordered by priority) are required to minimally address this issue:

  1. [ASAP] Change the fee structure to be a function of effective ETH balance instead of validator count. Currently, a validator with 2048 ETH pays the same fees as one with 32 ETH. Since most validators have been consolidated, operator income has decreased considerably.

  2. [ASAP] Design a new policy that allows operators to feasibly change their fees. Currently, operators are limited by a 10% fee change once every two weeks, which is too prohibitive.
    Note that this must be sensitive to customer shock and liquidation risk.

    • Ideally, this should also include a change (e.g., denominating fees as a % of ETH rewards) to mitigate SSV token price volatility and match the common pricing industry standard.

  3. [Soon] A prominent suggestion to sign up for our monitoring services (e.g., monitorssv.xyz) on cluster creation and maybe on the app and explorer for greater awareness. This will help to mitigate impacts of operator fee changes and shutdowns. This could also include the addition of minor alerting features if deemed appropriate (e.g., a method for an operator to deliver a signed message to those registered for alerts).

  4. [Soon] A mechanism to help distribute stakers across operators to discourage centralization and spread income over more operators. Many options exist, ranging from a simple heuristic-based semi-random suggestion of verified operators when creating clusters (i.e., populate the form with recommendations) to more complex solutions like sophisticated recommendation algorithms or, eventually, automated cluster management tools. The scope of this proposal should be limited to the easiest and quickest solutions, leaving the investigation of more complex options for later.

Unfortunately, upon initial investigation, most of these tasks seem non-trivial and will require significant development work and changes to the protocol by SSV Labs, influencing the allocation of budget and resources and subsequently, the overall roadmap. This temp check proposes forming a small working group.

The responsibilities of the working group will include:

  • Designing preliminary solutions.
  • Collaborating with SSV Labs to make decisions on final solutions to implement.
  • Writing a DAO proposal (or multiple proposals) to contract SSV Labs to complete this work.
  • Facilitating the work’s completion with SSV Labs.
  • Reporting the outcome back to the community.

VOTING OPTIONS

These are the intended voting options when this Temp Check goes to the non-binding Snapshot Vote. Voting will happen on Snapshot only, in accordance with the Temp Check guidelines in [DIP-32] Revision of DAO Governance, Committees, and Budget

  • For: Forming a working group to address the foundational issues presented in this Temp Check, and acknowledge, but leave aside, the other issues/approaches presented in the other Temp Check.
  • Against: Do not address these issues in the way and order presented in this temp check, and continue the discussion on the previous temporary check, and explore different solutions/approaches.
3 Likes
2

I think this is a good distillation of our most pressing issues with the public operator market. This is by no means a complete solution of all problems, but these issues are high-priority with seemingly strong consensus. It makes sense to push these forward as a first step.

2 Likes
3

We could increase the range within which an operator can change fees, but that would introduce the risk of malicious operators overcharging users (until they are liquidated).”

3 Likes
4

Much needed interventions here - SSV node operator financial health needs to be urgently addressed. Ethereum’s approach is “validators exist to serve the ecosystem, not the other way around”. So that makes DVT an even more distant step-child with minimal incentives. Pectra consolidations without simultaneous operator fee structure updates have made things worse. Let’s solve the first two points ASAP - even setting up committees sounds too slow. Fix the 80% pain points NOW, the working group can sort out the 20% refinements later. Also add point no. 5 - B2B engagement and business development for getting institutional staking to utilize existing unutilized node operator capacity. Lido’s SDVT pilots are a painfully slow and cautious start - lets get Kraken and others to be a bit more committed to using existing operator infra.

3 Likes
5

Thanks a lot, @h.m.23-0NEinfra!

We’re on the same page here, and yes, if approved, the first two points deserve a fast track. As pointed out in the temp check, implementing the features isn’t that simple and requires some time and effort, unfortunately.

Regarding your point 5, the SSV Foundation, with the assistance of SSV Labs, has attempted to persuade partners on several occasions to host on public operators. However, we’ve learned that those partners often have regulatory concerns, and it is not as straightforward as it seems.

Speaking to some people, there is a belief that the public operator market can outperform private operators on all metrics and will therefore be the natural choice in the long term. It’s a bold statement, but as the space evolves, we might be getting there.

Again, your opinion aligns with those of most people I spoke with, indicating strong support. Let’s make that happen.

3 Likes
6

Fee structure reform is essential - Moving to an effective ETH balance model rather than validator count directly addresses the revenue impact of validator consolidation post-Pectra

Flexible fee adjustment mechanism - The current 10% bi-weekly limit is clearly insufficient for operators to respond to market conditions

Practical, phased implementation - Starting with monitoring integration and basic operator distribution mechanisms provides immediate value while more complex solutions can develop over time

4 Likes
7

I’m Yuting, an operator, and formerly a solo staker. Based on my limited but hands-on experience, I’d like to share a few thoughts.

From an operator’s perspective, I spend real money on hardware and ongoing maintenance. These costs are denominated in fiat and are relatively stable. The main reason operators feel the need to adjust fees frequently is the volatility of the SSV token price. In that light, timely fee adjustments are reasonable. I also think the current adjustment cap (10%) is a bit too small. Because an operator fee change must go through both a declaration period and an execution period—each currently 7 days—two weeks of SSV price movement can easily exceed 10%.

I believe the existing declaration/execution design is very good; it provides notice to validators and helps avoid liquidations caused by sudden changes. However, there are two issues:

  1. There isn’t an effective, guaranteed channel to ensure validators actually receive and notice fee-change alerts. Without reliable delivery, a longer declaration period has limited impact.

  2. Even if a validator notices a fee change in time and disagrees with it, there isn’t a simple, “smooth” path to quickly switch to another operator. This makes validators highly dependent on and sensitive to their current operator’s fee decisions (because switching is hard), which in turn increases liquidation risk.

In summary, I recommend:

  1. Modestly increasing the allowable operator fee adjustment range to better support a healthy public-operator market.
  2. Establishing a direct, reliable operator-to-validator notification mechanism.
  3. Improving the operator-switching UX—ideally a one-click, turnkey-style replacement—so validators are not overly dependent on any single operator’s changes.
  4. Considering stablecoin-denominated operator fees: validators would still deposit SSV, but the SSV consumption would be dynamically calculated based on the SSV price.
4 Likes
8

Totally agree with @fod here, as usual.

1 Like
9

Hi @alonmuroch

The way I see it, if fee changes are too restricted, stakers are safe because they won’t get hit with surprise hikes and have time to react and avoid liquidation but it hurts operators because they can’t adjust when costs go up or SSV drops. They end up stuck with low fees and struggle to stay sustainable.

I believe finding a middle ground would be in the best interest of both parties.

Probably someone has already thought about this but what if, during cluster formation, we display a transparent history of each operator’s fee changes so stakers can make informed choices and reduce information asymmetry?

It shouldn’t be too difficult to implement.

10

Hi @Yuting,

You mentioned very good points here. I would like to share my opinion.

Point #1 (increasing operator fee adjustment) I think there’s consensus but then we have to agree on a specific increment.

Point #2, you’re right, when an operator changes its fee, the update is recorded on-chain and validators must actively check it through the SSV contract or tools like SSV Explorer or SSV Scan cause there are no direct notifications. This also ties into our concern about how stakers can be notified when an operator in their cluster goes unresponsive.

I think it actually opens up another dilemma. On SSV, it makes sense for cluster owners to stay pseudo-anonymous instead of having a direct public contact because Ethereum’s whole ethos is about decentralization and censorship resistance. If you tie validators to real identities or public social contacts, they could face legal, political or social pressure that distorts their validator decisions, on top of being exposed to attacks or judged by who they are instead of how well their node runs.

What really matters is transparent on-chain data, fees, performance, cluster updates, not someone’s personal or social info. That way stakers get the info they need while we keep Ethereum’s “code is law” spirit intact.

This is my opinion, I think this should be discussed more deeply. I believe the monitoring/alert suggestion is probably the best way to educate operators and soften the negative impacts of not having direct communication channels between operators and stakers.

Point #3 is also tricky because we have design limitations from the SSV protocol. I would like to refer you to the exchange I had here with @BumpyTale:

Comment #1:

Comment #2:

Comment #3:

Point #4 is interesting, but I’m afraid it would require significant development work.

Not saying I’ve got the full answer, just my vision of this complex ecosystem.

11

I think this approach might solve the volatility issue

2 Likes
12

Many operators’ 32ETH validators are unable to reorganize into 2048ETH validators. It is hoped that a temporary solution can be implemented before the final solution is released, such as a fee return airdrop to reduce the economic pressure on operators.

1 Like
13

@chainupgov maybe I’m missing your point, but since the Pectra upgrade, it’s possible to consolidate 32 ETH validators into larger 2048 ETH validators as long as you’ve migrated to 0x02 withdrawal credentials.

SSV docs support this consolidation workflow for clusters.
Our SSV public operator have few consolidated validators.

14

Voting is now live :vertical_traffic_light:

https://snapshot.box/#/s:mainnet.ssvnetwork.eth/proposal/0x0a9f8bf123060d2050a62c32d80227139145102dfdd3c651ab5253cfb2ae0752

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

2 Likes
15

Thank you for posting this, and I agree 100%. I think migrating to this ETH-centric fee model with a SSV staking mechanism is a great path forward. It solves several of our existing issues at once and provides a great flow of value to token holders.

4 Likes