[DIP-11] Mainnet Proposal

[BenAffleck]

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:

1. Proposal applicability;

2. Smart contract designation;

3. 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:

Unveiling the ssv.network Mainnet | ssv.network

Smart contract designation

The ssv DAO Multi-Sig will gain control of the following ssv.network smart contracts:

1. 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.

2. 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)

[BenAffleck]

Important information

The numbers above are based on this in-depth research post by @arielzimroni.

DAO Controlled Network Parameters Configuration

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,…

[badkid]

@BenAffleck

DAO Multi-Sig

who are the key holders?

[BenAffleck]

Good question! There’s another proposal for the m-sig reform. Those people will have control over the keys. Make sure to check each of the members carefully and see if you agree with the level of decentralization.

[DIP-2] Multi-Sig Committee

Intro One of the SSV DAOs formation cornerstones is the Multi-Sig Committee. The Multi-Sig Committee acts as the safekeeper of the DAO’s treasury and provides a layer of security when executing votes made by the community. It further controls smart contracts associated with the ssv.network project, and any other parameter within the control of the Committee’s wallet. This proposal aims to solidify the Multi-Sig Committee responsibilities, compensation, members and work procedures, and it shall …

[BenAffleck]

The proposal was voted ‘Yes’ by the community and reached the required quorum.

https://snapshot.org/#/mainnet.ssvnetwork.eth/proposal/0x90af2241fb2b3b3242dfb98efb9185b5bafac00d1cb300542a107d0df4ef6e12