[DIP-33] proposes changes to the calculation of the Network Fee update as outlined in DIP-11 to address issues caused by market volatility and fluctuating fees. It introduces a minimum 14-day notice for fee updates and a process for adjusting fees based on the 15% deviation threshold measured monthly.
Motivation
The current Network Fee structure, as outlined in DIP-11, requires stakers and clusters to pay fees that, depending on various factors, might be recalculated monthly, and if recalculated, updated by the DAO multi-sig committee. This process has proven less than ideal, given the volatility of market conditions and the potential for significant deviations in Network Fees. These fluctuations have resulted in liquidation events due to the limited time between fee forecasts and updates, the lack of certainty surrounding forecasted changes, and the imprecise nature of the estimations. The proposed solution aims to mitigate these issues by providing a minimum of 14 days’ notice for all Network Fee updates, allowing stakers and clusters ample time to react and adjust their runway accordingly.
Changes to the Network Fees Calculation
The following passage will replace the final paragraph of the Network Fees Section under the subsection DAO controlled network parameters in [DIP-11], and become effective immediately after the passing of this proposal:
[…]
The Network Fee deviation shall be measured with closing data from the 1st of each calendar month as soon as it becomes available (hereinafter referred to as “Deviation Check”). If the Network Fees’ proposed value were to change from the previous Deviation Check to the following Deviation Check by more than 15%, the Multi-Sig shall update the Network Fees Formula with the updated values of the APR and ETH/SSV variables. If the Deviation Check results in a need to update the Network Fee, such a transaction will be proposed on the second schedule batch as outlined in DAO Contributor: Proposal for Engagement as the DAO’s Master of Coin.
We support [DIP-33] as it introduces an important improvement to the Network Fee update process. The proposed minimum 14-day notice period for fee changes is an adjustment that gives stakers the necessary time to react to sensitive shifts in a key parameters such as the Network Fee is.
This update directly addresses the risk of forced liquidations caused by abrupt fee changes, which has been a concern under the current DIP-11 framework. By tying updates to a clear 15% deviation threshold and basing them on monthly closing data, the proposal brings more predictability and operational stability to the ecosystem.
Overall, this is a well-calibrated change that enhances transparency and allows participants to better manage their runway planning.
Necessity of Buffer Period
The introduction of a 14-day notice period is a critical improvement to address current liquidation risks. It provides staking participants—particularly small-to-medium node operators—with a reasonable time window to adjust their capital strategies, thereby reducing forced liquidation risks caused by sudden fee changes. This aligns with the fairness principles of DAO governance.
Optimization of Volatility Filtering Mechanism
The dual mechanisms of a 15% deviation threshold + monthly checks strike a balance between avoiding operational complexity from frequent adjustments and preventing systemic risks during extreme market volatility. Compared to the vague language in the original DIP-11, the quantifiable threshold significantly enhances the enforceability of the rules.
Add some difference analysis I conducted after reviewing, as well as a link to DIP-11： [DIP-11] Mainnet Proposal
Moreover, and more importantly, I strongly support this proposal as it makes the SSV scheme more mature and robust.
What Does DIP-33 Change Compared to DIP-11?
Recap: What DIP-11 Introduced
DIP-11 laid the groundwork for the mainnet launch of SSV.Network, giving the DAO control over key network parameters, including:
Network Fee Mechanics (DIP-11)
Fee Formula :NetworkFee = 32 ETH × APR × FEE × ETH/SSV ÷ BlocksPerYear
Fee Schedule :
0.5% of ETH staking APR initially
0.75% after 1 year
1% after 2 years
Update Mechanism :
Network Fees were subject to a “Deviation Check” on the 15th of each month.
If the calculated value changed by more than 15%, the DAO Multi-Sig must update the fee.
No guarantee of advance notice or a defined execution path.
What DIP-33 Changes
DIP-33 refines the fee update mechanism to address volatility, uncertainty, and liquidation risks.
Key Improvements
Feature
DIP-11
DIP-33 (Amended)
Deviation Check Timing
15th of every month
Changed to the 1st of every month
Advance Notice
Not specified
Requires a minimum 14-day notice before any Network Fee change
Deviation Threshold
>15% triggers update
No change (still 15%)
The Goal of DIP-33
To enhance predictability and stability for Operators and Stakers by:
Avoiding sudden fee changes
Preventing unanticipated liquidation events
Allowing everyone time to adjust funding and operations
TL;DR:
DIP-33 refines the Network Fee mechanism introduced in DIP-11 by introducing a monthly check on the 1st, requiring at least 14 days’ advance notice for any fee change, and clarifying the governance process for executing such updates. The result is a more stable and predictable system for all network participants.
The proposal suggests changing the notice period for fee adjustments to 14 days and only updating when the change exceeds 15%. I believe this approach is reasonable and I support it.
seeing the need to have some kind of time buffer, i’d have a question: maybe i’m overlooking something here but why not continuously (or daily) measure network fee deviation (and display it somewhere publicly)?
First of all, I think this is indeed a good thought. However, personally, I believe that if frequent SSV fee changes are made every day, it will also bring a lot of instability and may lead to validators encountering liquidation issues more frequently without enough time to respond. Therefore, I think the fixed cycle fee change with 15 days’ advance notice makes sense as it reduces volatility and gives validators time to react.
Thanks to BenAffleck for putting forward DIP-33. As a DAO member, I’m generally supportive of these updates and offer the following summary and discussion points:
1. Proposal Overview
14-Day Notice: All Network Fee changes require at least 14 days’ notice before implementation, giving stakers and operators ample time to adjust.
Monthly Deviation Check: On the 1st of each calendar month, closing data is used to calculate the deviation of the proposed fee versus the last checkpoint.
15% Threshold: If the fee change exceeds ±15%, the Multi-Sig will update the APR and ETH/SSV parameters in the fee formula.
Execution Timing: Triggered updates are scheduled for the DAO’s “second batch” proposal cycle, ensuring predictable timing.
2. Strengths & Benefits
Risk Mitigation: A 14-day notice window reduces the risk of sudden liquidations due to unexpected fee increases.
Balanced Responsiveness: The ±15% threshold captures significant market moves without over-reacting to minor fluctuations.
Process Clarity: Tying updates to fixed monthly checkpoints and existing DAO scheduling improves transparency and traceability.
3. Discussion Points & Suggestions
Data Source Integrity
Which price feed(s)—e.g., Chainlink or CoinGecko—will serve as the official “closing data”?
Should we consider multi-source validation to guard against oracle anomalies?
Notice vs. Proposal Timing
How will the 14-day notice align with the Multi-Sig’s second-batch proposal deadlines?
Do we need an additional buffer to ensure proposals can be drafted, reviewed, and executed within that window?
Threshold Calibration
Is 15% the optimal threshold for our volatility profile?
Should we allow emergency adjustments (with faster DAO approval) in extreme market events?
Emergency Contingency
In the event of “black swan” events—e.g., on-chain exploits or exchange crashes—can we bypass the standard schedule to protect the network?
Ongoing Transparency & Metrics
Propose publishing a monthly log of fee checkpoints and adjustments in the forum or dashboard.
Consider tracking metrics such as “post-adjustment liquidation rate” or “stake runway buffer” to evaluate effectiveness.
Conclusion
DIP-33’s combination of advance notice, fixed monthly reviews, and a clear deviation threshold will enhance predictability and reduce surprise liquidations. Clarifying our data sources, fine-tuning the schedule alignment, and building in emergency protocols will further strengthen this mechanism. Looking forward to everyone’s feedback!
If by “measure” you mean to update the network fee inside the protocol daily, then this is indeed an interesting idea, but it comes with its own risks and challenges and would require substantial changes to the smart contracts.
We’ve also discussed ways to make all of this on-chain, including on-chain governance for updating the fees, which would result in the real-time observability you might want. It’s something we’d like to look into.
This proposal is more of a quick fix on the DAO layer, rather than a long-term improvement. We believe this solves the most pressing issues with the Network Fee, allows everyone enough time to respond, and most importantly, doesn’t lead to any larger liquidation events as short-noticed fee updates might slip through.
hey @BenAffleck ,
yeah, of course - having it on-chain and being adjusted by some logic would be best case. result could be something like a “health factor” we know from defi/lending protocols.
what i actually meant (for now), @Yuting , is just measuring and displaying it somewhere publicly, so people could already anticipate changes, if they are eager to.
anyway, a 14 days time buffer is an improvement for sure.
The deviation checks and the parameters are presented on the DAO Treasury Sheet.
Liquidations and simulated Liquidations according to future network fees are a new feature of monitorSSV.xyz. If this proposal passes, the simulation can be updated after the 1st of each month, offering a “real-time” liquidation view. I also recommend their Telegram bot that notifies subscribers of certain changes.
What Does DIP-33 Change Compared to DIP-11?
Recap: What DIP-11 Introduced
What DIP-33 Changes
Key Improvements
The Goal of DIP-33
TL;DR:
Voting is now live: