This document aims to propose the initial settings for the network parameters under the governance of the ssv.network DAO.
The proposed settings are suggested to be implemented at the commencement of the Launch phase of the network’s mainnet rollout, when the ssv.network DAO assumes control over the protocol through a successful DAO vote.
This document draws inspiration from previous work presented by the DAO’s Developer Evangelist, @markoInEther , as described in this article.
For reference, all datasets and calculations used throughout this document can be found here.
Special thanks to @fod and @BenAffleck for their feedback and contributions.
Please note that the calculations for these parameters rely on dynamic variables, and that there will be a time gap between when this proposal is published and when it is implemented. Therefore, it is essential to reassess their calculations before execution, based on the presented calculations and data.
In addition, it is advised to continuously track the variables that impact the network fee and liquidation collateral (mainly SSV/ETH ratio and Ethereum Staking APR) on a monthly basis and adjust the parameters in case a 15% deviation from current settings has occurred.
Network Fees
To use ssv.network, stakers are required to pay a network fee - a fixed cost denominated in SSV charged per validator. Network fees flow directly into the DAO treasury and can be used to fund further development of the SSV ecosystem and activities of the DAO.
Network fees are essential to ensure the self-sustainability of the DAO, supporting ongoing operations and fostering the expansion of the network.
While establishing a consistent revenue stream through network fees is vital for long-term success, it’s a prevalent strategy for startups to prioritize growth over profitability during their initial phases. Offering a product for free during this period helps facilitate the achievement of this goal. Introducing a new network can follow a similar approach.
With this notion in mind, the first question to be asked is whether the network fees should even be activated or not:
Arguments for deactivating network fees
-
User Acquisition: In the early stages, gaining user adoption is crucial to the network’s growth. By not charging a network fee for the services, barriers to entry are removed and more users are encouraged to onboard. Zero fees increases the likelihood of attracting users who might be hesitant to use a new protocol that lacks a track record and is yet to be battle tested, allowing the network to build a larger user base which can later be leveraged to convert to paying users that generate more revenue.
-
Competitive Advantage: In a crowded market such as Ethereum Staking, offering a free service can be a significant competitive advantage. It incentivizes the potential user base to choose the network over competitors, especially if they are unsure about the value the protocol provides over other alternatives.
-
Data and User Feedback: By attracting a larger user base, the protocol could collect more feedback and insights about users preferences, needs and pain points. This data can be leveraged later on to continuously optimize the protocol with their requirements in mind, and go to market with a better product.
Arguments for activating network fees
-
Revenue Generation: Introducing a network fee from the beginning will create a direct stream of revenue for the DAO. Although the focus is on growth initially, having some revenue early on can help offset operational and development costs, providing the DAO more financial stability.
-
Focus: Charging a network fee enables prioritization of users who are genuinely interested in the product and are willing to pay for it, rather than having to support a large number of free users who may not be as engaged. This focus can lead to developing a product with higher market fit and user retention.
-
Fees Normalization: Launching with a network fee would make the users accustomed to paying some fees (by factoring a potential business expense) and ensure that from day one they design their products in mind to include procedures in place to facilitate its payment.
-
Fee Discovery: Having some sort of network fee will ignite the feedback and discussions around what the fee should be. Establishing an initial fee as reference will aid fine-tune and optimize the network fee accordingly.
-
Spam Protection: Operators have the option to set their fees to 0 (and designate themselves as permissioned operators), thereby creating private “sub-networks” of their own. Despite being private, these networks still impose additional costs on the entire network (bandwidth, computation, etc…). Imposing a network fee helps prevent network spamming and freeloading.
The decision whether to activate network fees involves a trade-off between short-term growth and long-term sustainability. While zero network fees can encourage rapid early-stage adoption, activating network fees ensure user familiarity, fee optimization, and spam protection, ultimately contributing to building a healthy and successful network in the long run.
Considering these arguments, implementing an initial network fee outweighs the option of not activating network fees. But in favor of mitigating its potential drawbacks, adopting a strategy of launching with a relatively small fee would be a valid compromise.
Decision Drivers
- Network fees should be activated.
- Network fees should position the network with a competitive advantage.
- Network fees should be low enough to incentivize onboarding of early users.
Evaluation
Evaluating what should be the initial network fee begins with looking at the competitive Ethereum Staking landscape:
Fee structure of leading players in the Ethereum Staking ecosystem
The benchmark established by the leading and most relevant players (non-CEX) is set at 10% of the validation rewards their protocol generates.
These players (excluding the ones who operate their own validators) split this fee between their DAO (equivalent of the SSV network fee) and the node operators who provide the infrastructure to operate their validators.
This benchmark makes two things evident:
- With the assumption that the expenses of integrating DVT would come out of the pocket of the DAO rather than on the expense of their operators, it is safe to assume that the maximum fee that could be set for the network would be at the 5% threshold.
Being an infrastructure provider it would be incorrect to compare SSV’s network fees to fees charged by staking applications (e.g. Lido). Therefore, room should be allowed for these players to remain profitable and competitive, while building on SSV Network.
- The standardization to derive network fees from the validation rewards, means that the network fees should constantly track and correlate with both:
-
Ethereum Staking APR
- As the staking APR increases, the network fee should be increased.
- As the staking APR decreases, the network fee should be decreased.
-
SSV/ETH price fluctuations
- When SSV goes up relative to ETH, the network fee should be decreased.
- When SSV goes down relative to ETH, the network fee should be increased.
Decision Outcome
It is proposed to move forward with a network fee that represents 0.5% of the Ethereum Staking APR, and gradually increase it over a two-year span to reach 1%:
- Transition to 0.75% - 365 days after the initial configuration is live.
- Transition to 1% - 730 days after the initial configuration is live.
(Calculated by the following formula: 32 ETH * APR * FEE * ETH/SSV / BlocksPerYear)
Based on $1900 ETH, $18 SSV, 4.7% APR and 2613400 blocks per year
Liquidation Collateral
To use the ssv.network, stakers are required to deposit a sufficient balance of SSV tokens into their cluster balance for each validator they run on the network. This balance is known as liquidation collateral.
The required collateral amount is the highest between a fixed amount set as the Minimum Collateral, and a dynamic amount which is sufficient for a predefined period of time called the Liquidation Threshold Period that is derived from the operator fees in each cluster. Having varying operator fees between different cluster formations makes this amount dynamically calculated per each cluster.
The liquidation collateral is essential to ensure that operators are always compensated for their efforts, and contributes to the health of the network by protecting it from becoming insolvent.
To achieve this the network is dependent on actors called liquidators. Liquidators can be run by anyone and work in the background to keep the system functioning by flagging clusters that have insufficient balances to carry their expenses.
For the costs and risks associated with liquidating insolvent clusters, liquidators are awarded with staker’s liquidation collateral.
Since transactions on the Ethereum network are not free, and stakers can’t incur additional costs if their cluster runs out of balance, it’s crucial to ensure that liquidations on the network are always profitable.
A profitable liquidation occurs when the liquidation reward (collateral) is greater than the liquidation cost.
Variables that influence liquidations profitability:
-
SSV/ETH price fluctuations - as the liquidation collateral is denominated in SSV, and the liquidation cost is calculated by gas costs in ETH, the profitability is correlated to their price fluctuations.
- When SSV goes up in relation to ETH, liquidations are more profitable.
- When SSV goes down in relation to ETH, liquidations are less profitable.
-
Gas costs - the costs of executing the liquidate function on the Ethereum network.
Aside from guaranteeing profitability for liquidators, it’s important to consider that high profitability comes at the expense of reducing stakers’ capital efficiency. When a high collateral is required, it leads to a larger portion of stakers’ capital being idle and exposed to risk.
Finding the optimal liquidation collateral requires striking a balance between liquidators’ profitability and stakers’ capital efficiency.
Decision Drivers
- Liquidation collateral should exceed the liquidation cost.
- Considerations for liquidation collateral amount should factor stakers’ capital efficiency.
- Liquidation collateral should incorporate a buffer to accommodate price volatility, liquidation incentivization and protocol risks.
Evaluation
Evaluating what should be the required liquidation collateral begins with determining how much it costs to liquidate a cluster on the network.
Transaction costs on the Ethereum network are calculated by the amount of gas used to do some operation (gas units), multiplied by the cost per unit gas (gas cost).
It can be deterministically calculated how much gas units it would take to execute a liquidation function in the network:
Liquidation function execution in gas units per cluster size
Since liquidation collateral requirements are independent of cluster sizes, the highest cost among the supported cluster sizes - the 13-operator cluster - should be considered, as the reference gas unit cost for liquidation.
As mentioned previously, gas units are only one part of the equation when calculating transaction costs. The second variable is the gas cost, which represents the amount users are willing to pay for each gas unit, denominated in GWEI.
Unlike gas units, the gas cost is dynamic. The cost set by the transaction executor is usually derived from the congestion of the network. The more demand for blockspace, the higher one would have to set the gas cost to get prioritized over other transactions, at that point in time:
Ethereum gas prices over the last year (reference - ycharts.com)
As shown above, gas prices on Ethereum are very volatile, but the data shows that:
-
The average cost stands at ~30 GWEI (30.15).
-
During times of high demand for block space on the network, this condition tends to be temporary and doesn’t persist for extended periods.
-
Even during congestion, it was still possible to execute a transaction at the average cost within a 9-day timeframe from the peaks.
Considering the information provided, using the 30 GWEI as a reliable benchmark would position liquidation costs at 0.007584 ETH (~$14.5). A crucial benchmark for liquidation collateral to exceed.
Besides the external factors that influence liquidation costs, there are internal factors that directly impact staker’s operational runway for their clusters which must be considered while evaluating the liquidation collateral:
- DAO Controlled Parameters - Increasing the network fee, minimum collateral, and prolonging the liquidation threshold period immediately shortens the operational runway of clusters towards liquidation.
- Operator Fees - fee changes by operators directly impact the operational runway of the clusters they are part of.
Given the complexity of the various components involved and considering that liquidations represent the worst-case scenario for stakers, it is advisable to incorporate a sizable buffer when setting the liquidation collateral.
Considering the absence of risk in decreasing the liquidation collateral down the road, and adopting a priority for network safety over capital efficiency in the initial phase of the protocol, the proposal suggests incorporating a buffer based on to the following factors:
Applying a 100% buffer would result in the minimum liquidation collateral being set at 0.015168 ETH (~$29).
While the minimum liquidation collateral ensures the profitability of liquidations when the protocol risk is low (applied within clusters of low fees), the liquidation collateral based on the liquidation threshold period aims to safeguard network solvency in times of heightened risk (applied within clusters of higher fees).
Derived through dynamic calculations specific to each cluster’s fees, this liquidation collateral essentially establishes a safeguarding window for the network during periods where no liquidations occur at all.
Considering that the liquidation threshold period-based collateral can be nearly equivalent to the minimum liquidation collateral (applied for values exceeding it), its configuration should also incorporate the findings pertaining to the minimum liquidation collateral:
- The discovered average window of 9 days for profitable liquidations establishes the minimum duration for the threshold period.
- The buffer requirement should be expressed in terms of duration (the 100% buffer would correspond to an additional 9 days in this context).
Since collateral derived from the liquidation threshold period will be applied to higher risk settings, it is recommended to enhance this buffer even further.
Decision Outcome
It is proposed to move forward with the minimum liquidation collateral as 1.6 SSV (~$29 - calculated by the following formula: 252800 GasUnits * 30 GWEI * 2 (100%) BUFFER * ETH/SSV)) and 30 days for the liquidation threshold period.
Based on $1900 ETH, $18 SSV and 2613400 blocks per year
Operator Fees
The ssv.network utilizes its native SSV token to facilitate payments between stakers and SSV node operators to maintain their validators. This is done through a free-market approach that enables operators to set their desired fees.
Although operator fees are set and controlled by the operators themselves, the ssv.network DAO governs the guardrails that limit the amount by which operators can raise their fees during each fee change cycle, in addition to the cycle duration itself.
The fee change cycle duration is determined by the declaration and execution fee periods, and the increase limitation dictates by how much fees could be increased within each cycle. This means that these variables go hand-in-hand with each other and their conjunction basically sets how much operators could increase their fee over periods of time.
Changes to operator fees have a direct impact on the operational runway of their managed clusters - if all cluster operators increase their fees by 50%, it would consequently decrease the operational runway of their managed clusters by the same rate. This means that if fees could be changed too frequently, or too sharply, an event of cascading liquidations is likely to occur.
On the other hand, if the rate of fee change is too low or the fee change takes too long, it could cause the system to be rigid and not adaptable to changing market conditions. Setting these variables must be done judiciously to align with ongoing market conditions.
To evaluate how these variables should be configured, let’s first take a look at potential drivers for initiating fee changes by operators:
-
SSV price fluctuations: As operator fees are denominated in SSV, they are inevitably correlated to price fluctuations.
-
ETH price fluctuations and staking APR: The current benchmark for operator fees, set by prominent leading staking applications, is a percentage of the staking APR (e.g. Lido rewards their operators with 5% of the generated validation rewards). Having the benchmark denominated in ETH and derived from the staking rewards means that the referenced fee baseline of operators fees will be influenced by its price fluctuations and the staking APR.
-
Competitiveness to pricing of other operators
As competitiveness between operators is not something to account for, and Ethereum’s staking APR is not volatile, focus should be given to fostering a configuration that would be adaptable to changing market conditions where SSV and ETH price fluctuate:
- When SSV goes up relative to ETH, operators would be inclined to decrease their operator fees.
- When SSV goes down relative to ETH, operators would be inclined to increase their operator fees.
Because there is no protocol limitation on reducing operator fees, the only case needed to be addressed is the scenario in which SSV declines in relation to ETH.
Decision Drivers
- Enable operators to change fees in correlation to price fluctuations in a reasonable time.
- Fee guardrails should account for the potential maximum annual increase of fees, so operators won’t take advantage of idle stakers.
- Fee change cycle should span sufficient time for stakers to be notified and adjust their cluster balance (runway) or operators accordingly.
- Provide operators with enough time to execute their fees.
Evaluation
Crypto is a very volatile market. To align with SSV and ETH price fluctuations, the evaluation begins with determining what percentage it would take to recover price declines:
Required percentage uplift to recover from a price decrease
With the assumption that a -99% decline would be a catastrophic event which is unlikely to be recoverable, the steep -90% benchmark was chosen as reference to the upper edge of what the design should support.
The next question to be asked is how quickly should the design enable operators to “recover” by adjusting their fees in correlation.
During normal market conditions and cycles, steep declines occur over long periods of time (rather than within a single day), the more realistic choice should be to be able to support it within a year.
To consider which configurations should be selected, an evaluation between a variety of different fee change cycle durations and fee limitations has been conducted:
- Fee cycle durations (in days): 7, 14, 21 and 28
- Fees increase limitations per cycle: 5%, 10%, 15% and 20%.
The evaluation tested:
- How different cycle durations and fee limitation combinations effect the maximum annual fee increase potential:
Maximum annual fee increase potential per different cycle duration and fee limitation sets
- How dynamic are different fee increase limitations in day-to-day conditions of shorter periods, where prices usually fluctuate in lower ranges of up to 20% (a figure observed for standard price action periods):
Number of days required to recover from up to 20% price declines per considered cycle durations and fee limitations
As the data shows:
- Higher fee increase limitations and shorter cycle durations result in higher potential annual fees increase.
- Marginal combinations (e.g. 28-day cycle duration and 5% fee limitation) are not dynamic enough to correlate to market conditions and could cause overhead to both stakers and operators in their monitoring and operations.
- All the highlighted combinations present potential candidate sets.
Decision Outcome
It is proposed to move forward with the combination of a 14-day cycle duration and a 10% maximum fee limitation per cycle.
For the fee execution period - assuming operators would execute their fees as soon as the declaration period ends, the execution period doesn’t really prolong the fee change duration (dictated by the declaration period). Therefore the value set for this variable was set in mind to provide a window for operators to execute their fees in a way that is sufficient for their operation, but also in a period that is expected by the stakers that they manage.
Based on 2613400 blocks per year