Feedback Wanted: Adjusting the Fee Increase Limit

General
1

Hello, SSV Family -

I’m interested in your thoughts and feedback on a change I’ve been mulling over.

Currently an SSV operator can reduce their fee by as much as they want, but can only increase their fee by 10% per month. This limit is to help prevent unscrupulous operators from suddenly increasing their fee dramatically and potentially draining their clients’ SSV deposits.

At the low end, however, I think this cap is causing more problems that it solves.

The most obvious example is any operator with a 0 SSV fee. They cannot ever increase their fee at all, because 10% of zero is zero.

But consider an operator charging a low fee of just 0.1 SSV per year. That is about $3 at current rates. If they want to increase their fee to $10 per year (0.33 SSV) it will take them over a year to do so if they go up by 10% each month.

Month Fee
0: 0.1
1: 0.11
2: 0.121
3: 0.133
4: 0.146
5: 0.161
6: 0.177
7: 0.194
8: 0.214
9: 0.235
10: 0.259
11: 0.285
12: 0.313
13: 0.345

This seems like a very long time to roll out a $7 price increase.

I think this very slow increase prevents people from experimenting lowering their rates, because once they go low it will take a very long time to get back to a higher level.

So my suggestion is to add another component to the rate increase limit.

Instead of just having a 10% cap, I think we should have a cap of 10% or 0.1 SSV, whichever is greater.

This way, for any fees set to 1 SSV or more the 10% cap would apply.

But for rates between 0 and 1 SSV, the increase limit would be set at 0.1 SSV per month max.

I think this would allow more flexibility in pricing, and would solve the problem of validators being trapped at 0 SSV.

What do other people think?

Thanks
GBeast

4 Likes
2

Please post your questions, comments and concerns. I want to identify and potential problems so we can evaluate them.

1 Like
3

I think it’s a great idea to fix the issue you mentioned and it also maintains the mechanism to protect stakers’ deposits from unscrupulous operators who might suddenly increase their fees dramatically. I vote ‘Yes’ :smile:

4

This seems like a very wise move to me.

The only unintended consequence I can think of is that there are a number of protocols that may depend on the permanence of a 0 fee, like Lido for example. Allowing a change to a 0 fee could potentially result in theft from these protocols.

5

Hackworth I’m not sure I get the risk of theft here. From what I know, operators/protocols can set their fees, even 0%, allowing them to manage their own incentives.

How could this lead to theft if they got the option to increase their fees to a max of 0.1 SSV per month?

6

Using Lido as an example:

Right now Simple DVT operators spin up operators with a static zero fee to accept Lido validators. Once the protocol confirms that the operator fee is set to zero, they no longer need to worry about the operator increasing this fee in the future and charging the protocol (the protocol compensates operators separately). With this change, an operator could pass the initial check, but then start charging the protocol afterwards. Even if it was detected quickly, it would force the protocol to liquidate the cluster at significant expense and reconfigure everything.

I suspect they would not approve of this change without a way to make a 0 fee permanent.

1 Like
7

Interesting! How about adding an option for operators to set their fees to 0, either permanently or temporarily?

2 Likes
8

Yes, that could be a good addition.

I don’t know if the Lido problem is insurmountable. After all, the Lido operators with the zero fee all had to agree to be operators, and it would be pretty simple to add a term to their agreement that they will never increase their fee, and if they do they will be permanently banned from participating as a Lido operator.

And because they could only raise their fee 0.1 SSV per month, it wouldn’t be hard to have a small backup reservoir of SSV deposited to the Lido validator account, which would start to draw down if an operator tried to raise their fee, at which point Lido could remove the offender and appoint a new operator in their place.

That said, it would probably be more broadly applicable if an operator could be designated “Free Forever” for any staking services that need that in their operators.

2 Likes
9

I got to admit, I was skeptical the first time I read this proposed change.
Mostly because personally, I really don’t like adding non-linearities to mathematical functions (like the fee increase one).
Another reason is because I thought it was based on a false premise: operators fee set to 0 being irreversible.

As it turns out, I was wrong, and this is, indeed, the case. For this reason only, I would lean more towards a positive opinion on this, or at least accepting a change to the function to allow for reversibility of 0 fees.

I also appreciate the issue with low fees needing much more time to adjust, and the fact that this could be changed.

I understand that a breakdown needs to happen at some point and there needs to be a definition for how low is a “low” fee.
The only counterpoint I would make is that maybe, instead of a fixed increment for “low” fees, some sort of superlinearity could be concocted, so that below 1 SSV, the % gap is “proportional to the difference between the fee and 1 SSV”.
(it sounds more complicated than it actually is).

As for Lido’s problem brought up, as it has been mentioned already, the fee changes still don’t takes place overnight, there should be time for alarms to set off, if cluster balances are monitored (which they should be).
Similarly, if this change is implemented, it could be as easy as suggesting to monitor not just the balance, but the fee changes, which can be monitored thanks to the subgraph.

Lastly, for Simple DVT specifically, the cluster balance is provided by the DAO itself, so yes, if any potential fraudulent activity is going to take place, following this change, it would be for a small amount before getting caught (as already mentioned), but it would not harm Lido itself, rather the DAO.

1 Like
11

What would your superlinearity formula look like?

Ideally it would be easy to calculate, because if it’s complicated then it might scare people away from using it.

12

I have linked this topic over to the Operator discussion in the SSV Discord. You can find that discussion here: