Thanks for the response.
Interested in learning how long from a dev perspective it would take. Days - weeks estimate, type of developer required, etc.
Trying to gauge exactly how difficult it would be technically to implement.
Is there someone on the team equipped to look into this issue?
Gotcha. Labs has quite a capable engineering team, so although it’s probably not trivial, I think it’s a relatively minor feature compared to the huge undertaking that is based apps and everything needed to get there.
But again, I’m not sure you’re going to get a precise answer, simply because it seems that the preliminary research needed to estimate the task hasn’t been done yet. Software development unfortunately tends to be like that… estimating is usually hard in general.
With that said, a few days to a few weeks for that specific feature seem like reasonable bounds for a few devs… I’m obviously guessing though (as a dev in a different field). Someone from Labs feel free to correct me if I’m off with any of this.
Also is there a question behind that question? Sorry for prying… just trying to get to the bottom of what you’re investigating. Feel free to reach out on Discord if that’s easier.
Who from labs do you think would be able to best estimate?
I am trying to get an estimate of exactly how long it would take to implement these changes from a dev perspective and who on the team is best equipped to do the prelimanary research
Sorry, but I don’t understand. It’s a relatively small task, and it will get done… Why do you need such a precise estimate?
Alon (the CEO of SSV Labs) gave you a response:
Depends on how we implement it, I can think of a few ways but this needs further research.
And I gave you a developer’s perspective (albeit with limited knowledge):
I’m not sure you’re going to get a precise answer, simply because it seems that the preliminary research needed to estimate the task hasn’t been done yet. Software development unfortunately tends to be like that… estimating is usually hard in general.
With that said, a few days to a few weeks for that specific feature seem like reasonable bounds for a few devs
Labs is very busy with trying to launch SSV 2.0, and they probably aren’t going to shift their backlog of work and spend hours doing the research necessary to give you a better estimate.
Thanks, yes Alon did.
I am asking for who on the team specifically has the skillset and can do the further research and also want to gauge how long that research will take.
My concern with increasing the fee is that it eats heavily into the revenue earned by professional stakers and staking services.
I charge my clients a modest fee for managing and monitoring validators – less than the 10% fee charged by many services. I can run my client validators on a regular EL/CL combination, or I can add SSV as a layer for better uptime and redundancy.
But a 1% SSV fee represents 10-20% of my gross revenue, and becomes my single biggest monthly cost. At that point I have to evaluate whether the additional uptime is worth the expense.
If the SSV fee were 10%, I would have negative monthly income, so it would simply not be possible for me.
One way to address this issue is to have a 2 tiered fee system: one for smaller operators and one for larger scale operators.
The large scale institutional operators, who desperately need SSV for the downside protection for their clients, can afford the higher rate and should have to pay it
Does anyone have the answer to who specifically on the SSV development team has the skill set to do further research on how long and what type of skill set is required to implement the technical changes that streamlines the SSV payment structure to making the network fee directly payable in ETH and then having that ETH go towards buying SSV on a DEX via a smart contract
How large is your operator?
How would you know who is “small” ? We could potentially use the VOC for that and encourage smaller operators via a reduction in network fee..
SSV, via its explorer, has the data to sort Operators by Validator count. 10 validators is small, would put it in the bottom 33% of all SSV operators.
Anything 10 validators and below pays the 1% fee, anything above 10 pays 10% fee.
You could calculate the economics to determine at what point the costs become prohibitive.
I prefer keeping it simple. 10 validators is small
@alonmuroch what do you think about this logic and where can I find more information about the VOC
I don’t see how operators/ services would pay 10% when they take 10-15% from their users
Lately i’m thinking about how we can monetize more, maybe from the block building/ MEV side… offer multi MEV blocks, rev-share with block builders, etc
As we grow we can do things towards those goals
Coinbase takes 35% fees on user staking rewards. Do other operators charge significantly less?
Even if the operators on SSV take 10 - 15% of user staking rewards, then SSV can at least increase the staking reward fee to 5% rather than 10%.
.75% is so low for the value!
I think Coinbase is an outlier compared to the rest of the industry:
If the network fee becomes 10%, we’ll effectively be taking ~3.5% net negative out of the staking service providers’ margins (6.5% IM – 10% network fee).
That’s specifically for private operators.
If we can onboard a meaningful number of clusters under the TC model, this could generate an additional $2–3M in annual fees for the DAO.
Thanks, what does IM stand for in “6.5% IM”?
Do public operators have a different rate that they charge compared to private operators?
What is the liquidation collateral?
Don’t you think its easier and more efficient to charge the network fee right on top of the staking rate in ETH?
Adding $2 - 3 m in annual fees is meaningful, still think its way too low considering SSV’s TVL is pushing $20 billion.
Too cheap!
Waiting to see the proposal that covers this Trusted Cluster model idea. 
IM stands for Incentivized Mainnet, which is a program we have been running that gives stakers a small % boost to their rewards for being early adopters. This has been a major strategic initiative because it has helped us to build a large validator set which both enables and creates a competitive advantage with SSV 2.0 (compose.network). See the IM proposals for details.
Yes, public and private operators have different operator fees. Private operators negotiate deals with their customers. Public operators have an open market… although the market/pricing aspect is currently broken and will be improved soon. But all stakers pay the same network fee.
Liquidation collateral is the minimum amount of SSV a staker needs to keep their cluster active. This is needed because it costs some for the network to shut down (liquidate) a cluster if they have no SSV to pay their operators.
Yes, changes to the fee structure are needed for a few reasons, and it’s a work in progress. Unfortunately, any change requires a lot of work, so it won’t be immediate. And yes, we are currently extremely cheap, but it’s been a conscious part of the long-term plan.
Thank you for answering. I did not mean SSV is cheap, I am saying that the service SSV provides is too cheap in price.
Everyone needs house insurance, just like every institutional operator needs DVT. SSV is charging $100 for a house insurance policy on a $10 million home. The price SSV charges compared to the value they provide is too low.
Why .75% is still too low
IM makes sense. I am still not understanding @alonmuroch’s point about the margins being negative for private operators with a 10% network fee. Here is my understanding, please correct me if I am wrong:
I stake 100 ETH that earns 2.9% APR without using an operator. Lets say I used Coinbase as an operator, which takes 35% of my staking rewards off the top. After year 1, without coinbase I would have 102.9 ETH. With Coinbase, Id only have approximately 101.09. Coinbase took 1.085.
With SSV and Coinbase after year 1 with the .75% network fee, Id have 101.06. SSV took .03 ETH, which is 2.7% compared to what Coinbase took as revenue. Even at Binance’s 10% rate, SSV is making a fraction of what the operators make. These institutional opeartors are making a killing!
SSV’s share of the revenue pie is way too low compared to the value SSV is providing, which is effectively getting rid of the downside slashing risk. SSV has pricing power because there are no competitive alternatives and institutional operators, which likely make up the majority of TVL on SSV, need slashing risk protection in order to attract clients. Why is SSV getting such a small portion of the revenue pie compared to these institutional operators?
Comments on Trusted Clusters
Pieciemiel legal agreements with the foundation for every operator is not scaleable. TCs will likely take significantly longer to implement than an increase of the network fee and a change in the mechanism for how the network fee is charged.
How long would a network fee increase and change in payment mechanism actually take dev wise?