# \[TEMP CHECK\] Fixes to Recent Issues with Public Operator Economics **URL:** \ **Category:** Proposals\ **Created:** [September 25, 2025, 8:27am UTC](https://forum.ssv.network/t/temp-check-fixes-to-recent-issues-with-public-operator-economics/2023 "2025-09-25T08:27:25Z")\ **Posts on this page:** 1\ **Showing post:** 10
**Author:** ![AXBLOX](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.ssv.network/axblox/32/834_2.png) [@AXBLOX](https://forum.ssv.network/u/AXBLOX)\ **Post date:** [September 30, 2025, 12:46am UTC](https://forum.ssv.network/t/temp-check-fixes-to-recent-issues-with-public-operator-economics/2023/10 "2025-09-30T00:46:52Z")
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: > [@\[TEMP CHECK\] Revisiting the Operator Marketplace and Fee Models](https://forum.ssv.network/t/temp-check-revisiting-the-operator-marketplace-and-fee-models/1963/25): > > About that: Maybe my message has not been read in the private vo-committee channel on Discord, but I spent quite some time analyzing the SSV official documentation and here’s what I found (I personally did not use DKG until now, always KeySplitting method): With SSV’s DKG, the validator key is created so nobody ever sees the full private key. It only exists as encrypted shares across the operators. When you need to swap operators, you run a reshare: The private key stays the same, so the v… Comment #2: > [@\[TEMP CHECK\] Revisiting the Operator Marketplace and Fee Models](https://forum.ssv.network/t/temp-check-revisiting-the-operator-marketplace-and-fee-models/1963/27): > > I think a clarification is needed here: Resharing changes the shares, not the secret. In SSV’s DKG, resharing regenerates new shares of the same validator key. If ≥ t former operators kept their old shares, they can still reconstruct the key. “Old shares are thrown away” is an operational assumption, not a cryptographic guarantee. To fully revoke past operators you’d need a key rotation (new validator). Comment #3: > [@\[TEMP CHECK\] Revisiting the Operator Marketplace and Fee Models](https://forum.ssv.network/t/temp-check-revisiting-the-operator-marketplace-and-fee-models/1963/28): > > Thank you @BumpyTale for the clarification! Yes, resharing only re-splits the same validator key, so if old operators kept their shares they could still help reconstruct it. The protocol assumes they discard them, but that’s an operational risk, full revocation requires a new validator key. Collusion risks Please do not change more than 2 operators in a cluster. Each set of generated shares will always be valid when their signing threshold is met (e.g. 3/4). To reduce the risks, it is advise… 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. --- _[View the full topic](https://forum.ssv.network/t/temp-check-fixes-to-recent-issues-with-public-operator-economics/2023)._