Proposal summary
The mainnet proposal aims to be the steppingstone for the ssv.network.
Upon approval of this proposal and the Launch phase of the Mainnet Rollout Plan, operators and validators will have freedom to choose their parameters and set their fees, subject to initial settings.
By approving this proposal the DAO assumes full control and responsibility over the smart contracts of the ssv.network just before the Launch of the network.
Proposal particulars
This proposal aims to establish the following:
-
Proposal applicability;
-
Smart contract designation;
-
Mainnet transition parameters;
Proposal applicability
The phases of the ssv.network Mainnet Rollout Plan are as follows:
-
Pre-Launch;
-
Limited Launch;
-
Launch;
-
Permissionless Launch;
At the time this proposal is being submitted, the current phase of the ssv.network is the “Limited Launch”. The proposal’s applicability timeframe will be designated to be applicable from the day of the “Launch” phase. More information regarding the roadmap can be found on the ssv.network blogpost here:
Smart contract designation
The ssv DAO Multi-Sig will gain control of the following ssv.network smart contracts:
-
ssvNetwork (
0xDD9BC35aE942eF0cFa76930954a156B3fF30a4E1) – The ssvNetwork smart contract represents a gateway contract to the ssv.network. It allows users to call functions of the smart contract and it allows users to interact with the ssv.network through a wallet address. The smart contract also contains the data on the state of the ssv.network. This contract points to the most updated ssv.network smart contracts, which is how it can be upgraded further. The smart contract also contains the whitelisting of staking applications and operators that are permitted to use the ssv.network during the “Launch” phase. -
ssvNetworkViews (
0xafE830B6Ee262ba11cce5F32fDCd760FFE6a66e4) – Represents a utility smart contract that is able to provide to users the ability to query a number of different attributes and states of the ss.network. This contract is only allowed to read data, with no write functionality or permission.
Smart contracts contain a number of parameters which determine how they function. The “Owner” parameter determines who has access to change the smart contract parameters. Therefore, this parameter needs to be changed to the address of the ssv DAO Multi-Sig, for it to be in control of the smart contracts mentioned above.
DAO controlled network parameters
This section of the proposal outlines specific parameters that will be set for the smart contracts described above, and controlled by the DAO:
Network Fees
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 Network Fees Formula: 32 ETH * APR * FEE * ETH/SSV / BlocksPerYear)
| Variable | Value |
|---|---|
networkFee |
0.0000003037337483 SSV per block (~0.8 SSV ~$14 per validator per year) |
The Network Fees deviation will be measured on the 15th of each calendar month (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.
Liquidation collateral
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.
| Variable | Value |
|---|---|
minimumBlocksBeforeLiquidation |
214800 (30 days) |
minimumLiquidationCollateral |
1.6 SSV (~$29) |
Operator Fees
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.
| Variable | Value |
|---|---|
operatorMaxFeeIncrease |
1000 (10%) |
declareOperatorFeePeriod |
1209600 (14 days) |
executeOperatorFeePeriod |
604800 (7 days) |
Important information
The proposal was voted ‘Yes’ by the community and reached the required quorum.