[TEMP CHECK] Revisiting the Operator Marketplace and Fee Models

[GBeast]

[TEMP CHECK] Revisiting the Operator Marketplace and Fee Models

Introduction

The SSV Network was created with the concept of an open marketplace where validators and operators could come together to do business. Operators would provide hardware and services to operate validators, and the validators would select a cluster of operators that met their needs for diversity, performance, and price.

To help ensure that the marketplace always has a selection of top-quality operators, the Verified Operator Committee (VOC) monitors the operators in the marketplace to identify any trends or concerns that are growing. Lately the VOC has noted that there is a general slowdown in public operator activity, and a growing disparity between large private operators and smaller public ones.

In the interest of restoring and maintaining balance in the operator market, the VOC has begun to formulate some theories and suggestions that may help improve the dynamism of the public operator market.

This document outlines the key issues that we identified, and then provides some potential proposed solutions that could help alleviate some of the trouble. We want this to start a discussion of the options, and gauge community consensus about the problems and solutions to help guide our next course of action.

Problem Statement

The SSV public operator market is in need of improvement.

• From the perspective of stakers / validator owners, there have been very few validators flowing to public operators recently. This is due to:
  • A difficult interface for forming clusters, choosing/replacing operators, managing keys, and monitoring operator status/performance.
  • The risks and costs of using unknown operators.
  • The risk of using public operators with nothing at stake.
• From the perspective of SSV node operators, running an SSV operator is an unstable business:
  • The revenue generated from operation is constantly changing and often unprofitable.
  • There is a lack of demand from new validators, which is driving operator fees down.
  • If operators cannot generate a profit, they will leave the network which reduces its capacity and potentially forces stakers to reassign their validators to new operator clusters.

Root Causes: Staker / Validator Perspective

Managing SSV Keys is a Challenge for Stakers

Launching a DVT validator using public operators is a daunting technical challenge. Stakers must generate, split, and install keys while working with multiple command-line tools, YAML files, and JSON files with few guard rails. It is a process that must be carefully orchestrated by experienced stakers.

If an operator performs poorly or stops performing altogether, staker’s must move quickly to replace the failing operator through yet another set of delicate key management manipulations.

For non-technical stakers, the process is effectively gated. There is no “one-click” path to staking with SSV public operators.

Cluster UX Discourages Institutional/Consumer Stakers

The user experience for creating clusters does not encourage broad adoption across a decentralized set of operators. The process of searching for and selecting public operators for a cluster feels more like sifting through a raw database, not shopping for a turnkey service. Operators are presented in simple lists with few options to sort and filter operators by valuable criteria. Performance data is limited, broken, and potentially misleading as to the impact it will have on final validator performance. Stakers cannot easily compare operators, view fee history, or estimate cluster performance. Many processes require manual steps and interventions.

For many stakers, the path of least resistance might be to run their own validators or use a custodial staking product. In effect, the UI nudges validators toward minimal-friction options, which today are almost exclusively private or protocol-owned operators, undercutting the set of public decentralized operators.

On one end of a staking spectrum are the highly technical stakers, who may have less need of decentralized products or custodial staking solutions. They don’t need public operators. On the other end of the spectrum are the stakers with minimal technical skills or understanding, who need their hands held or want to “set it and forget it”. They don’t need public operators. In the middle are the public operators. Any stakers with enough stake to provide significant support to the public operator community will likely fall at the ends of the spectrum. For the public operators, better tools are necessary to smooth the rough edges of the market.

Operators Have Nothing at Stake

Public operators post zero collateral and can disappear overnight. Because stakers have no direct line of recourse, they must either monitor continuously (expensive) or avoid public operators altogether. In practice, large holders choose accountability (SLA, insurance, legal entities) over decentralisation. Smaller stakers are more likely to use full custodial solutions. In both cases, stakers have better (though not perfect) assurances that operators will be around for a long time.

SSV Staking fees are unstable due to volatility of the SSV token price, making it hard to predict costs

Validators/stakers using public (fee-based) operators face inefficiencies in funding their clusters. Unless the validator has a hedging mechanism or a large bank of SSV tokens, they must purchase operational runway in SSV tokens at the time their cluster is funded. While this initial funding can be rational (e.g., based on the price of SSV today, how much does the validator want to spend on operations for a set period of time), a change in the SSV token price leads to constant changes in the cost of operations in ETH terms. If the SSV token price doubles, for example, then the cost of operations to the validator has also doubled, notwithstanding that the same service is being provided and the value of the service has not changed in ETH (or fiat) terms. Similarly, if the SSV token price halves, then the cost of operations to the validator is halved, again notwithstanding that the actual value of the service is unchanged. This leads to a sub-optimal experience for validators, who must constantly take on token price risk in order to fund operations that have a relatively static value.

Incentivized Mainnet does not encourage the use of public operators

The Incentivized Mainnet has been incredibly successful at attracting staked assets to the SSV network, and has resulted in one of the highest TVLs for any Eth staking protocol. As an incentive it worked very well because it compensated validators for the time, effort, and risk of moving their operation to a new validation protocol, while simultaneously offering compensation that would offset any new costs they might incur – notably the SSV Network fee and the Operator Fees (if any) for the four operators that managed the cluster.

As the number of Incentivized validators has grown, we have seen an overwhelming trend where new validators almost exclusively use clusters of private operators that have a fee of zero SSV. These operators are run by the same entities that are migrating their validators into the SSV network. There is nothing inherently wrong with that practice – it allows the entities to be confident in the security and uptime of their self-managed operators, while allowing them to keep all of the incentives other than the SSV network fee.

Unfortunately, this has meant that very little of the Incentivized Mainnet rewards have flowed through to any of the public operators in the SSV Network, so that a significant portion of the ecosystem does not benefit from the Incentivized Mainnet program in any way. It is an unintended consequence of this that we have a large number of qualified and performant public operators that are ready, willing and able to accept validators, but are unable to cover their operational costs. There is a risk that if this situation goes on too long, that we may find the set of available public operators declining and withering.

If we posit that one of the primary goals of the Incentivized Mainnet program is to help grow the SSV Network in a balanced and sustainable manner, then it makes sense to periodically revisit the Incentivized Mainnet program, evaluate the areas in which it is succeeding and those where it is not, and decide if it is appropriate and beneficial to nudge the program’s trajectory towards more desirable results. This is particularly true given the large monthly expense associated with the IM program – we want to maximize the return the DAO receives from its investment.

It should be possible to make some minor adjustments to the design of the IM program that could help achieve a more balanced distribution between private and public operators.

Root Causes: Operator Perspective

Operator revenue is unstable due to volatility of the SSV token price, making it hard to predict revenue

Like validators, operators also face intrinsic economic inefficiencies in SSV operations. While the cost in real/fiat terms of the services SSV operators provide are relatively stable (e.g. hardware costs, data center costs, electricity), the revenue generated from these operations is denominated in SSV token and as a result is unstable and unpredictable. For example, an operator with 100 validators may know that the cost to operate is $300/month, but profitability on a monthly, or even daily, basis cannot be predicted. Setting an operator fee at 1 SSV/year when the SSV token is trading at $40 would result in an expected monthly revenue of approximately $3.33 per validator, resulting in a monthly profit of approximately $333. But a decrease in token value to $10 would bring monthly revenue down to $0.83 per validator, resulting in a $216 loss per month. Absent an ability to predict SSV token price, Operators are left to make unfounded predictions on future token price when setting their service prices.

Operators cannot adjust fees quickly enough to account for SSV price swings

In the current fee model, operators can reduce their fees instantly but face restrictions when increasing them: any fee hike is capped at 10% and requires a 14-day waiting period. While this mechanism protects validators from sudden or malicious fee increases, it leaves operators unable to respond quickly to market volatility, particularly during sharp drops in the SSV token price.

Since SSV’s all-time high of ~$65 in March 2024, its value has fallen to ~$8 (as of July 3, 2025), causing a major disconnect between operator revenue and staking economics. For example, a 0.5 SSV annual fee, once worth $32.50, is now only $4. In a typical 4-operator cluster, that means a validator pays just $16 annually while earning ~$2,600 in rewards (assuming a $2550 ETH price, 32 ETH per validator, and 3.1% APY) - an effective operator fee of ~0.6% (or 0.15% per operator in a 4-operator cluster). Due to the delayed fee adjustment mechanism, operators cannot restore sustainable pricing in a timely manner, leaving public operators undercompensated and financially strained.

Fees are in a race to the bottom as operators try to attract validators

Due to the limited usage of public operators in the SSV Network - driven by the demand-side issues outlined earlier - operator fees have entered a downward spiral. Launch operators originally charged around 1.5 SSV per validator when the token traded near $50, but fees quickly dropped below 1 SSV, then 0.5 SSV, and now even lower. This decline has been compounded by the falling SSV token price, further eroding operator revenue. With few validators choosing public clusters, operators compete aggressively on price to attract stake, unintentionally contributing to the erosion of the very market they rely on.

Without intervention, the public operator market risks collapsing. In its current form, the free market dynamic incentivizes unsustainably low pricing, pushing operators to the brink. If fee erosion continues unchecked, many public operators will be forced to shut down, leaving the network dominated by large staking providers and protocols, who typically run their validators in private clusters. This would be a significant step away from the DAO’s mission to “Democratize access to secure, efficient, and reusable DVT infrastructure.”

Potential Solutions to Consider

The VOC members have brainstormed and drafted a number of recommendations for possible program changes that may help remedy some of the issues. We hope that this list will serve as the basis for a discussion about solutions – as such it is not designed to be a comprehensive or exhaustive list.

Make Changes to the Fee Structure

• Fees as a percentage of staking rewards for public operators

  • Option 1: 4% fee split among all operators in the cluster
  • Option 2: Each operator sets their own % fee
  • Pros: Reliable income for operators. Establishes an expectation of a “reasonable” rate. Remains among the lowest fee structures in the space.
  • Cons: May reduce the number of validators entering the network due to increased fees. Significant development work. A standard fixed fee would be a significant step away from a free market of operators.

• Minimum/floor operator fee for public operators

  • Floor could be in SSV, ETH, USDC, or could be a % of staking rewards
  • Pros: Guarantees minimum level of income for operators. Eliminates race to zero.
  • Cons: Reduces market competition. Increases costs to validators. Requires contract modifications. Introduces race to the floor.

• Fees that float like the SSV network fee

  • Fees could be a percentage of staking revenue ETH, or a fixed annual price.
  • Fix price to another currency (USDC, ETH) and periodically adjust the SSV fee to match the original peg.
  • Pros: Stabilizes revenue even if the SSV price swings. Stabilizes cost to validators as SSV price swings.
  • Cons: Makes runway management more difficult for stakers.

• Set fees in USD or ETH

  • Option 1: Customer pays in ETH or USDC. Payment is seamlessly swapped for SSV at market prices, then used to pay the fees.
  • Option 2: Eliminate SSV token as the primary mode of payment, and allow payment in other tokens (ETH, USDC)
  • Pros: Greatly simplifies the payment process.
  • Cons: Hard to implement in practice. Anyone who is holding SSV remains subject to price volatility risk. If SSV token is not used for paying network fees, then it raises legal compliance issues since it no longer has utility.

• No limit on operator fee changes

  • This would be required if any zero-fee operators wanted to go public, since they currently cannot raise their fee at all.
  • Pros: Operators can change prices quickly to compensate for SSV token price changes. Allows zero-fee operators to increase their price, which they currently cannot do. Creates a more efficient market for operator prices.
  • Cons: Allows operators to overcharge their customers. Allows operators to accidentally or intentionally liquidate validators using their operator. Makes it critical to have an effective way to alert stakers to the price changes. Could force stakers to spend more time re-forming clusters and re-sharing keys if price increases are too large. Will work better if there are easier tools for cluster formation.

Develop Improved Tools for Key and Cluster Management

• Improve the UX for Key Management

  • Develop educational materials promoting common sense practices toward cluster formation. As only one example, set reasonable standards regarding levels of operator performance required to maintain high validator performance with the goal of discouraging the use of only the highest performing operators.
  • Build new tools for cluster selection:
    • More filters on operator selection tool, such as:
      • Fees
      • Clients (with warnings about similar clients across operators)
      • Operator performance, including over longer time horizons
      • Average validator performance for operators
      • Region (with warnings about geographically distant operators)
      • Longevity of operator
      • Number of active validators
    • Mock cluster formation. Create a cluster and see stats regarding potential cluster/operator performance. Compare to other proposed or even active clusters.
  • Build a tool that can accept at least 32 ETH, and manage the entire process of DKG key generation, beacon chain deposit, and cluster formation.
  • Smart contracts to automatically rotate operators for clusters.
    • Operators could be selected based on a heuristic to optimize for public operators with acceptable performance and possibly commitment bonding.
  • Pros: Allows people of all skill levels to use SSV. Allows more informed selection of operators, resulting in higher-quality clusters. Lowers the initial bar to getting involved with SSV, increasing the likelihood of adoption by new users.
  • Cons: Requires appropriate safeguards to prevent unskilled users from making critical errors. Requires development investment by the DAO.

• Improve the UX for Cluster Formation

  • SSV-led continuous improvement of key management processes with a goal of eliminating complex interactions, CLI tools, etc.
  • SSV-provided automated tools for cluster monitoring, operator rotation, etc. with a goal of reducing the management load of stakers. Could involve a full suite of tools or contracts that automatically keep cluster operating with vetted, active operators.
    • Might eliminate some tricky key management tasks.
    • Reduces workload for stakers to monitor and manage their clusters.
    • Reduces risk of validator/cluster failures.
  • An SSV Labs SDK exists that can handle many parts of this requirement, and can be leveraged to build a tool like this.
  • Pros: Makes it easier to create a new cluster if an operator goes offline or is underperforming. Helps make the market for operator services more liquid, by preventing a user from being locked-in to an existing operator cluster. Could help eliminate the need for the user to generate clusters offline.
  • Cons: Could drive down the fees for operator services, if users only seek the lowest-cost option at all times. Requires the DAO to invest in new tooling. Costs gas fees each time a new cluster is registered on-chain.

Enhance Confidence in Public Operator Service Levels and Performance

• Create an Operator Bond Program

  • Create an optional bonding system to provide some guarantees to stakers that their operator will not disappear. Optional allows existing operators to continue as-is, but can show stakers that particular operators are serious and committed to their validators.
    • Would need methods to slash bond when a bonded operator fails to perform to a set of criteria.
    • Would require determining a bond amount sufficient to provide assurances that operators will not disappear, without limiting the ability of operators to grow their validator base. Ideally the bond would not be based on the numbers of validators, but would be significant enough to show serious operator commitment.
  • Pros: Prevents operators from shutting down without notice. Reassures stakers that their operators will be around for the future.
  • Cons: Depending on the size of the bond, could make it harder for small operators to enter the network.

• Build notification tools to automatically alert Stakers if their Operator underperforms or goes offline, so they can form a new cluster if necessary.

  • MonitorSSV has tools that can help support this, but a final solution must be more tightly integrated with other potential staking tools presented here. Requiring stakers to set up and manage multiple disparate tools becomes another UX problem.
  • Pros: Better tools help keep stakers informed of the performance and status of their cluster.
  • Cons: None

• Build two-way communication tools for operators/stakers.

  • This could be used by operators to inform them of operational changes that stakers may need to prepare for, or for stakers to see public operators not simply as faceless daemons but as actual service providers who care.

• Add a Pledge to the VO program, stating that Verified Operators agree to give 60-Days advance notice prior to shutting down a Verified Operator.

  • Pros: Stakers see a public statement from operators indicating their commitment.
  • Cons: Stakers still have nothing at stake and can shut down at any time.

Make Changes to the Incentive Programs

• Allocate a pool of SSV to be used for an Incentivized Public Operator program.

  • This could be designed to pay a small monthly fee to each public operator that meets certain benchmarks for performance and number of validators.
  • Example: each public operator with 97% monthly performance and at least 1 validator could be allocated 1 SSV per month.
  • Pros: This option has the advantage of simplicity, in that it does not require changes to the current Incentivized Mainnet program.
  • Cons: It represents a new cost to the DAO, and the total cost would need to be considered carefully. If the incentive is too small, it may not provide a meaningful benefit to operators.

• Adjust the parameters of the current Incentivized Mainnet program to encourage the use of public operators.

  • One way to structure this would be to say that a portion of the monthly incentive is paid out only if the validator is running on a public operator.
  • This could be a new incentive on top of the current program, or it could be a reallocation of some of the current incentive rewards.
  • Example: Using the current 7.5% incentive, all validators might receive 5%, and validators using public operators would receive an additional 2.5% for a total of 7.5%.
  • Pros: A change of this type could help achieve three worthwhile goals:
    • It might help steer some validators to use existing public operators, helping those operators benefit indirectly from the IM program and become more financially stable.
    • It might result in the conversion of some currently private operators to become public operators, where they would set a market-rate fee instead of a zero fee. This would help the invisible hand of the market more accurately set a market-clearing price for Operator services. It would also increase the number of public operators available to the network, and thereby increase operator diversity.
    • It could represent a cost savings to the DAO, in that any validators that were not managed by public operators would forfeit a portion of the fees currently allocated under the IM program as it stands. This would help extend the life of the IM program at no additional cost to the DAO.
  • Cons: Any time you alter an existing program you run the risk of annoying the existing participants.
    • Large SSV partners, who currently have a sizable number of validators and private operators on the network, would have to modify their setup or else lose some incentive income that they were expecting to receive.
    • Allocating new funds to the IM program would be less disruptive to the current participants, but would be a new cost for the DAO.

In Closing

As stated at the beginning, this document outlines the key issues that the VOC identified, and then provides some potential proposed solutions that could help alleviate some of the trouble. We want this to start a discussion of the options, and gauge community consensus about the problems and solutions to help guide our next course of action.

We welcome your input, thoughts, feedback, and ideas. Help us decide what topics you think are important, so we can return to the drawing board as a better-informed committee, and be better prepared to work on some more specific plans for the DAO to consider. Thank you!

[monitorssv]

Hey, thanks for mentioning MonitorSSV. Here, I want to share my thoughts:

Fees that float like the SSV network fee
Will this also allow operators to set prices freely, and then float based on the operator’s current pricing?
For example, after the network fee changes, allowing anyone (such as the operator or staker) to initiate a transaction to update the operator fee to match the magnitude of the network fee change, the benefit of this solution is that the operator will not maliciously increase the fee significantly.

For runway management, the publicity and education of cluster liquidation should be strengthened, and more agile alarm services should be provided. MonitorSSV can support more agile alarms.

No limit on operator fee changes
The advantage is that it allows current 0-fee operators to become public operators.
This may happen that the operator maliciously increases the fee significantly, and the workload of the staker increases significantly. The staker needs to monitor the cluster runway more promptly to prevent liquidation from happening.

For the staker who needs to rebuild the cluster because the operator increases the price, this will be more troublesome. He needs to regenerate the shards, exit the existing validator, and wait for the validator to go offline before registering the validator.

Improve the UX for Cluster Formation
For non-DKG clusters, the stakers need to use multiple command line tools to complete the process (generating validator keys and then generating key shards), and the entire process requires professional knowledge and skills.
For DKG clusters, whether the DKG service is online will affect the first step of whether the entire process can proceed smoothly. For public operators where the DKG service is not online, the stakers may have no channels to contact the operator, which will cause the stakers to be trapped in the current cluster.
If the key management process led by SSV can eliminate complex interactions and CLI tools, the experience will really improve a lot.

MonitorSSV can make these contributions, hoping to provide more convenience for stakers and operators, making MonitorSSV a better one-stop monitoring platform:

New cluster selection tool:
MonitorSSV can add the following functions to support:

• Current Fees and Declared Fees
• Public operator filter
• Longevity of operator
• Number of active validators
• Region
• Client
• DKG endpoint and DKG service online detection
• DKG service online time ratio (online time ratio within 24 hours)
  (For operator performance and average validator performance, it is not supported due to the high technical implementation cost, sorry)
  (For simulated cluster formation, because there is no operator performance and average validator performance data, this function is also not supported)

Communication tool:
If necessary, MonitorSSV can provide a public message board function to allow operators and stakers to communicate (signature authentication, message alarm push, non-encrypted, no sharing of confidential information)

If there are any valuable tools that MonitorSSV can provide, please let us discuss

Thanks

[AXBLOX]

TL;DR:
Public operators on SSV struggle because the UX is tough and private operators make it easy. Maybe fix this with a “public pool” smart contract: ETH holders stake into it, a fair queue (stake + randomness like Solana plus DVT-based diversity factors like client mix, performance, region, etc.) auto-rotates public operators, removing technical headaches and using the trust that SSV could offer, like Lido or Binance do. Rewards split automatically, small operators get fair chances. Needs serious tech work but could really level the playing field.

Wow, amazing brainstorming VOC team, thank you for that!

I think this is a great opportunity and we can agree there are multiple hurdles and complexities that make public operators on SSV not very successful.

Maybe here we should think outside the box, considering the scale of the problem.

If we ask ourselves, what is really working well with SSV? How come we see thousands of new ETH flowing into the protocol every day? What is driving success here is DVT being used by private operators (mostly the giants in the sphere).

If private operators have such success, maybe public operators should take inspiration from them and think about offering something as attractive as what private operators offer to ETH holders and financial institutions / whales.

When I was at the top of my game as an ETH miner during the Proof of Work era, I was relatively small as an individual but I joined a pool to help me compete in the field with my few gigahash of computing power and earn steady, good income from my ETH mining operations. That led me to think about something.

Here I will simply share an idea I had, it’s not backed by research and I know once again the technical aspect might block it or make it impractical.

Let’s look at the Solana blockchain. Solana picks who runs blocks by mixing how much SOL you stake with a bit of randomness. The more you stake, the more chances you get. They use recent block hashes and a special random function (VRF) to shuffle things so nobody knows the order ahead of time or can cheat. It’s a fair way to spread leader slots around and keep things fast.

Let’s imagine that SSV Network runs in parallel an optional opt-in pool for public operators. ETH holders could stake their ETH in that public pool and a smart contract would select SSV operators in a queue based on their number of SSV tokens staked, some randomness factors like with Solana plus few factors related to DVT features to maximize diversity (clients, operator performance, region, number of active validators, etc.).

The ETH holder wouldn’t have to form their own cluster, it would become easy UX, no need to analyze metrics and study different operators. The SSV brand would bring the trust users are looking for like with Lido or Binance.

I have been through the process of launching a DVT validator using public operators and it’s true, it’s a daunting technical challenge, which I personally enjoyed (but most people don’t) and during which I asked my AI assistant countless questions because I had tons of doubts and hesitations.

I think this is the main reason why private operators are so successful, they handle all the technical challenges and make it easy for small ETH holders or whales to stake with them.

Of course, it would involve a lot of technical work for SSV, but if that pool/smart contract removes all the technical burdens and offers a solution as attractive as what Lido offers, then the public operator marketplace could really thrive.

I think the actual market dynamics can’t be shifted in favour of public operators if we simply try to improve or add a few features to the current structure. We need a more radical change.

Such a pool could receive funding from SSV, something like the IMP or similar. If a public operator’s performance drops below a certain threshold for a few hours or days, it would automatically be replaced by another operator waiting in the queue. The public operators would rotate constantly like with Solana validators.

It could be like a public pool for public operators, with the fees and market rules mostly automated by a smart contract. Like how a Bitcoin mining pool works, when the pool solves a block problem, the rewards get split up automatically based on how much hashrate everyone put in. Of course, for SSV the mechanism would be different but the logic would be the same.

The factor weights should be set carefully so the biggest public operators with the most SSV staked don’t always take every cluster spot. The leader scheduler (like in Solana) that rotates validators should be well-designed so even small public operators have a fair shot to join the pool and build up their reputation, giving them more chances over time to propose and attest blocks alongside other public operators for SSV validators.

I’m sure I’m missing a ton of important stuff, but I just wanted to throw out this idea to keep the brainstorm rolling. What do you think?

[celticwarrior]

Right now, the SSV fee is split in two and paid as a network fee to the DAO and as an operating fee to the node operators.

I have several suggestions:

1. Set the network fee to zero and reward the DAO directly with SSV for growth in validator numbers. In effect this is what happens already as SSV tokens are purchased by validators and then paid to the DAO. It’s simply a flow through with no economic relevance.
2. Allow the node operators to set their prices in USDC (or perhaps some number of basis points of ETH rewards). NO costs are in fiat in any case. And it is much easier for a validator owner to know that their cost is $1/key/month.
3. Introduce an LST called ssvETH that is backed by validators secured by the SSV Network only. Charge a 5% commission instead of the eggregious 10% charged by Lido.
4. 1% of the LST fee goes to the DAO which flows through to SSV holders via a fee distribution mechanism. The other 4% goes to the NOs.
5. Introduce an optional smoothing pool.

Lots of possibilities to conisider…

[edit] And one more idea: You could allow the operators of private clusters to open up a public partition that charges a fee to public users. In these cases, private cluster operators already have a strong incentive to ensure that their nodes a performant. This could be very confidence building for other users.

[Ethernodes]

Thanks for sharing all that work and starting this debate.

Looking into the numbers, it’s clear that SSV operators use comes, mostly, from private clusters. That makes sense as validator volume comes from institutions / protocols that want to control both the process and the operators performing the job.

However, it is crucial to maintain a certainf percentage of validators using public operators that keep ethereum decentralized. In this sense, the three main point we belive would make more sense are as follows:

1. Public Operator Network Fee Discount

Reduce the network fee for public operators (e.g., 50% of the standard rate). That would make public operators more competitive than private ones. Thus, more options for users will be available as private staking providers may choose to run public-facing clusters using top-performing public operators.

2. Minimum Operator Fee (Floor) in USDC, Paid in SSV

We do agree with @celticwarrior on setting a minimum fee per operator denominated in USDC but paid in SSV (via oracle-based conversion). That would prevent unsustainable fee compression and protect both operators and validators from SSV price volatility.

3. Optional “Top Operator” Auto-Assignment

We do not believe that SSV itself should create a staking pool in which users stake the ETH for it to be run with DVT. This is already done & offered by some protocols, such as the Mellow Vault. In our opinion, SSV should keep focusing on Based Apps and creating modules for LST protocols such as SDVT or the SSVLido Module. Then, analyze with the protocol how the clusters may be formed (i.e, SSVLido Module might have an automated method to form the clusters).
But we agree that when a staker wants to launch its validator on SSV and has to choose the operators, having a kind of a “pre-selected” set of operators based on performance would be perfect. Space and Time has a similar feature and it works really well. That simplifies UX for non-technical users and increases discoverability of high-quality public operators.

3. Public operators info accesible

A simple dashboard that displays operators ranks by number of validators, performance, operator fee, network fee & verified, just for public operators. Getting this simple piece of information is complicated right now and it would be helpful for users!

Keep building!

[GBeast]

I like the idea of a public operator fee discount – that is an idea that we had not considered! Thanks for the suggestion!

[GBeast]

Interesting idea – using a large public pool as a way to incentivize public operators.

We had shied away from making suggestions that relied on creating too much infrastructure. You may note that we talk about how the staker UI is not robust, but we don’t really get into a discussion about what we would build to make it stronger. This is largely because SSV has steered away from building out a lot of small-staker infrastructure in the past, and we didn’t want to spend a lot of time drafting a User Experience that was unlikely to get built without much more support.

We also have not gone down the road of saying what would happen if we built a liquid staking pool. Once again, it’s because there is a lot that has to happen to get us from where we are now to there.

That said, I think you make a good point that if SSV were at the helm of a large staking pool, it would give the DAO some leeway to steer those funds towards public goals like supporting public operators.

So that is some good food for thought. Thanks for the suggestion!

[AXBLOX]

Great talk on the DAO All-Hands about reducing the network fee for public operators. After giving it more thought and echoing what Ivan pointed out, I’m not sure big players like Lido would go for it.

Even with the lower network fee, switching to public mode means they could lose control of cluster composition, for example, a validator might pick 1 Lido operator and 3 others from P2P. That’s not ideal for Lido, since they would no longer earn rewards from the full cluster and would also give up control over operator coordination.

So while the fee reduction could help, I doubt it alone will push private operators to open up.

I think some small tweaks could help public operators on the SSV marketplace, but honestly, I don’t think we’ll see major improvements in the end.

For us at AXBLOX, our only public operator actually loses money every month, we don’t even cover basic server costs. Meanwhile, our private operators with EtherFi and Lido are doing fine.

I get that what I suggested in my previous comment might be out of scope for SSV Network and I don’t want to sound negative but I don’t see public operators getting any better.

I actually think we will see more of them shutting down and going private since that’s where the money is. That’s why I believe the only way to actually save public operators is to make some big, bold changes like the ones I mentioned earlier.

[fod]

I think most of these problems can be reduced to a single core root problem: not enough stakers want to use public operators over private ones, primarily because the “total package” offered by public operators is not good enough.

We should be cultivating a reality where public operators are the undeniably superior choice.

The criteria for this is:
-Cost
-Trust
-Performance
-UX

Cost:
Public operators already appear to be far cheaper than private ones, even if our operator market was “healthy” and fees were higher than they are now. Compared to what typical private operators cost (and the industry standard for operator fees in general), our public operators are extremely cheap. As an operator myself, I expect my fee (and the market of fees set by other reputable operators) to settle around 2% of ETH rewards (0.5% of rewards per validator share), compared to the industry standard of about 5%.

Trust:
Stakers have little reason to trust public operators. Operators can disappear at any time without penalty. Only 30 days of history is available, which is not enough to show good long-term performance and a committment to the role. There is no method of communication between operators and stakers, so stakers can’t be notified of changes or nodes shutting down.

Performance:
/ Many public operators have excellent performance that is as good, if not better, than the average “professional” operator. However since our performance metrics and history are lacking, there is not sufficient information to demonstrate this conclusively to stakers.

UX:
Our tools for finding good operators are lacking. These are being improved gradually, but currently, it is difficult and time consuming for a staker to research and select operators. Also because the UX for creating clusters and swapping operators is not great, the cost of choosing the wrong operator is unnecessary high.

Therefore, the possible solutions to these issues seem to be:
-Improved operator performance metrics and longer available history. (Trust, Performance, UX)
-Two-way communication solutions between operators and stakers. (Trust, UX)
-An optional bond that can be posted by operators to improve trust. (Trust)
-Keeping the free-market structure so that public operators will continue to offer low fees that beat private operators and other competitors. (Cost)
-Letting operators define their fees as a % of ETH rewards or in USDC so that they can continue to offer low fees without a prohibitive amount of revenue volatility and uncertainty. (Cost, UX)

[Hackworth]

Hey everyone,

This has been a great conversation so far on the operator marketplace. The ideas around stablecoin fees, better UX, and building trust are worth considering.

Building on that, I was thinking more about the original post and a few points that are probably worth circling back to. One big one was the whole section on the Incentivized Mainnet (IM) program. That section suggested that rewards seem to be flowing to private, zero-fee clusters. It proposed that the program could be tweaked to encourage more use of public operators. For example, what if participating in the IM program required using at least one public operator, or the rewards were better for clusters that included more of them? Could an approach like that help the public side of the network? More generally, do you think there’s an issue with the IM program?

The initial post also floated the idea of a minimum operator fee to stop the “race to the bottom” we’ve all seen. It’s a tricky one. On one hand, it could make running a public node a more stable and predictable business. On the other, you don’t want to kill healthy competition. I’m curious what people think the right balance is there.

Curious to hear what you all think.

[AXBLOX]

Great post! I completely agree with everything you’ve proposed and mentioned!

[Ivan]

Heya Hackworth!

I just wanted to address the IMP, having to choose one public operator, to be eligible/get more rewards.

It’s a fairly easy requirement to get around, because the current private operators can just have all or some of their private operators be public and get around the requirement. On the flip side, them being public like this, will likely take what little validators are available from the actual public operators not only because they can all of a sudden choose previously private operators but because these private, turn, public operators are 95% of the network, meaning that the explorer would be riddled with these kinds of operators, making it even harder for people to find and choose actual public operators.

[AXBLOX]

Lately, our public operator got 4 more validators and we are very happy about that but it made us realize something. One of our new validators came in with 482.87 ETH staked (allowed since EIP-7251) but our SSV fee for that validator is the same as for the others with the usual 32 ETH staked. Operator fees are set per validator not based on the validator’s effective balance.

To offset this, we decided to gradually raise our operator fee from 0.3 SSV/year. But because of the protocol’s 10% step limit every 2 weeks, it will be a slow climb. Here’s the rough timeline:

• Now: 0.3 → 0.33

• 2 weeks: 0.363

• 4 weeks: 0.3993

• 6 weeks: 0.4392

• …

• 36 weeks: 1.8354

• 38 weeks: 2.0189 SSV/year

I get why the operator fee increase is designed this way to avoid sudden hikes and give validators time to react and avoid liquidation but in our case, it’s not effective. I would say this is another factor that works against public operators. Private ones have more flexibility since they monetize externally and can adapt pricing instantly.