[DIP-44] Re-Evaluation of Liquidation Collateral and Network Fee Parameters

It has been two years since the original framework for DAO-controlled network parameters was proposed and adopted. While most variables have since been updated, liquidation collateral parameters and the network fee formula itself have remained unchanged.

During this time, market dynamics such as Ethereum gas prices and the ETH/SSV rates have exhibited significant volatility. As these variables are core inputs to liquidation profitability, it is prudent and necessary to reassess the current parameter values and the frequency at which they are reviewed.

The goal with this proposal is threefold:

  1. Reapply the original framework using updated data from the last year.

  2. Recommend updated values for:

    1. minimumLiquidationCollateral

    2. minimumBlocksBeforeLiquidation (also referred to as liquidation threshold)

    3. 30-day moving average for ETH and SSV prices and ETH APR

  3. Propose an operational process for regular parameter maintenance.

Methodology: Revisiting the Original Framework

The same proven methodology was followed as outlined in the original proposal, updating the data window to reflect the 12 months leading up to July 2025.

Gas Price Analysis

  • Source: Daily Ethereum gas prices (July 2024–2025)

  • Average: 8.98 Gwei

  • Standard Deviation: 8.47 Gwei

  • The maximum number of consecutive days where gas prices exceeded the pessimistic threshold (avg + std) was 6 days.

ETH/SSV Price Analysis

  • Source: Historical ETH and SSV price data, July 2024–2025

  • Average ETH/SSV ratio: 200.07 SSV

  • Standard Deviation: 78.35 SSV

  • Maximum deviation from average: ~175% increase

Proposed Parameter Adjustments

The original parameter formula incorporated overly conservative and arbitrary contingencies due to the nascent stage of the network and the lack of historical data. After two years, this re-evaluation aims to introduce more robust and historically informed formulas, ensuring a sustainable and data-driven approach to future parameter adjustments. Buffers and static values to protect the network in its early stages are replaced with dynamic values based on historical data.

Minimum Liquidation Collateral

  • New proposed value: 1.536 SSV

To ensure that liquidations remain profitable even in high gas + poor exchange rate conditions, the calculation is based on:

  • Estimated gas usage per liquidation (ā‰ˆ252,800 units)

  • A pessimistic gas price ((Gas Cost avg + Gas Cost std. deviation)

  • SSV/ETH conversion buffer to account for price volatility

Calculated using the following formula:

image

Liquidation Threshold

  • New proposed value: 14 days

Derived by:

  • Starting from the maximum number of consecutive days where the gas price stayed above the gas price average (observe

  • Adjusted by a 175% ETH/SSV deviation multiplier representing the maximum deviation from the average

  • Rounded to 2 weeks for clarity and simplicity

Calculated using the following formula:

image

Re-evaluation Improvement: Ongoing Maintenance

To avoid another prolonged gap in updates, we propose:

  • Quarterly reviews of both parameters

  • Use rolling data from the last 365 days in each review (to smooth out short-term anomalies)

  • Only recommend changes if deviation exceeds ±15% from the currently set values

Calculations sheet

Summary of Proposed Changes

Parameter Current Value Proposed Value Deviance
minimumLiquidationCollateral 1.61 1.53 <15%
minimumBlocksBeforeLiquidation 30 days 14 days >15%

Mechanics and Effectiveness

Liquidation Collateral

This change aims to be effective immediately after the passing of this vote, and the presented parameters shall be updated with the first second scheduled batch (hereinafter referred to as ā€œSecond Scheduled Batchā€) following the passing of this proposal as outlined in DAO Contributor: Proposal for Engagement as the DAO’s Master of Coin.

Future deviations shall be measured with a 30 day moving average from the 1st closing day of each following quarter as soon as it becomes available (hereinafter referred to as ā€œDeviation Checkā€), and the Multi-Sig shall update the Formula with the updated values and calculate the results. If the result of the calculation were to change from the previous Deviation Check to the following Deviation Check by more than 15%, and therefore results in a need to update the parameters, such a transaction will be proposed on the Second Schedule Batch.

The community shall be informed as soon as possible on the SSV Governance Forum after a Deviation Check if it leads to updated values.

Network fee

[DIP-33] as an amendment to [DIP-11] state under 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.

If this proposal were to pass the abovementioned paragraph will be replaced by the paragraph below:

The Network Fee deviation will be calculated based on a 30-day moving average calculated on the 1st closing day of the following month as soon as it becomes available for all its parameters (ETH/SSV and ETH APR) (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.

If the proposal were to pass, the Multi-Sig Committee would start calculating the Network Fee starting in August 2025, using the 30-day moving average.

6 Likes

minimumLiquidationCollateral and minimumBlocksBeforeLiquidation are the same as networkFee. They are the calculation parameters of the liquidation runway. It is recommended to refer to the networkFee update process to prevent sudden liquidation of the cluster due to parameter changes!

Lowering minimumLiquidationCollateral and minimumBlocksBeforeLiquidation is beneficial to the cluster and won’t cause sudden cluster liquidations when parameters are updated. However, this can happen when parameters are increased.

The liquidation rankings on the Monitor SSV page won’t cover these two parameter updates. This DIP compels me to consider improving this feature.

However, is a quarterly update frequency too high? Since we want to eliminate short-term anomalies and use 365 days of data, is annual updates also reasonable? ( I’m particularly concerned about the update frequency, if it’s reduced, perhaps the need for improving this feature will decrease! :smiley: )

3 Likes

The frequency of the update has been debated, and yes, you are right, the purpose is to eliminate short-term anomalies, by considering a 365-days window of observation.
The problem is that if the window is 365 days and the frequency is also 365 days, the likelihood of the magnitude of the update itself being very high increase drastically.

A lot can happen in a year, we can shift from bull market to bear market, or vice versa, and even if the window of observation is 365 days, by making the update frequency very large, we’d be essentially ā€œerasing the pastā€, we’d be missing out on what happened before the last update.

As a result, a less-frequent, but larger update could have the unwanted effect of causing many more clusters to be liquidatable, or at a sudden risk of liquidation.

By having (slightly) more frequent updates, we expect that each update is less significant, and throughout the year we may have more updates, but less impactful on the clusters.

Then the question was: how frequent? And we adopted the choice of sticking with the frequency of updates to network fees.

I hope this clarifies.

3 Likes

The liquidation collateral can seem minuscule when migrating a handful of validators to SSV. However, it can be a significant obstacle for parties with bigger number of validator to migrate.

Hopefully, this change would ease the onboarding process for solo stakers and partners, and as a result bring more inflows to SSV Network.

1 Like

Hi guys,

We just wanted to highlight that [DIP-44] has been updated to also include the 30 day average data form the last month to be used to calculating of the Liquidation collateral and the Network fee.

This has been suggested to smooth out the spikes that can arise from using data from the 1st of the month, while the network fee seeks to be adjusted as well so that it’s a ubiquitous process for the DAO. :folded_hands:

2 Likes

Good call! The 30 day average keeps updates steadier and less volatile.

1 Like

Monthly updates would indeed be smoother. MonitorSSV will support this proposal at Monitor SSV

2 Likes

We would like to raise a governance concern regarding the continuous adjustments of the SSV network fee parameters. Since the beginning of this year, the DAO has already approved multiple increases, and each adjustment has been above 15%.

While fee adjustments are necessary to ensure operator sustainability and network security, frequent and relatively large increments create a negative impact on validator onboarding. Higher entry costs significantly reduce the economic attractiveness for new validators to join the SSV network, which could in turn hinder decentralization, growth, and the competitiveness of the ecosystem.

From a governance perspective, I believe it is time to re-evaluate the current fee model and explore mechanisms that are more predictable, transparent, and aligned with long-term validator growth. Instead of relying on discrete and sizable fee jumps, we could consider adopting a dynamic fee adjustment model, similar to Ethereum EIP-1559, where fees are adjusted algorithmically based on real demand and supply conditions.

Such a mechanism would provide:

  • Stability and predictability for operators and stakers, reducing uncertainty in cost planning.

  • Fairer alignment of incentives between network participants, encouraging validator adoption.

  • Sustainable growth of validator numbers, strengthening the resilience and decentralization of the SSV network.

It is recommended that a structured discussion be initiated regarding the DAO network fee model to strike a balance between network sustainability and incentivizing validator growth.

3 Likes

Voting is now live :vertical_traffic_light:

https://snapshot.box/#/s:mainnet.ssvnetwork.eth/proposal/0x5ab8383681f4efec61c1e89388477e18de3f1b9a34ce1fef001e55043a8f3273

@fod
@spookyg
@derfredy
@h.m.23-0neinfra
@markoinether
@axblox
@flo
@thomasblock
@yuting
@damon
@lemmagov
@llifezou
@monitorssv
@sigmaprime
@kenway
@hashkeygov
@Ethernodes
@p2pgov
@chainupgov
@kiln
@Allnodes

1 Like

Thank you very much, @hashkeygov!

This is very valuable feedback, and it was part of many discussions over the last couple of weeks. There’s a lot to say about this, as it not only affects the ā€œalgorithmā€ but is also a question of communication and general understanding of the network fee mechanics and economic parameters.

Having said that, once this proposal has passed, the Foundation x Labs x DAO working group will start working on suggestions to improve this. Depending on the outcome, another proposal is expected, which we will announce in time.

Thanks a lot!
—Ben

2 Likes

thank you for pointing this out, @hashkeygov - i’m supporting that idea.

2 Likes

Your suggestion echoes a comment I wrote back in June 2024.