[DIP-50] Introduction of Effective Balance Oracles, Effective Balance Accounting, ETH-denominated Payments, and SSV Staking
Proposal Summary
The ssv.network DAO (“DAO”) proposes introducing SSV Staking as part of a broader set of protocol upgrades designed to support ETH-denominated payments and native effective balance accounting within the SSV Network.
The transition to ETH payments simplifies the protocol’s economic model by aligning fee settlement with the asset in which validator rewards are generated. Moving fee payments to ETH removes cross-asset dependencies, reduces operational complexity, and enables more direct and predictable protocol-level accounting.
In parallel, supporting Ethereum’s post-Pectra validator model requires effective balance-aware accounting. Effective Balance Accounting (EBA) ensures that fees, runway calculations, and liquidation logic scale with the actual stake secured by validators, rather than relying on fixed assumptions. Implementing this model natively requires the protocol to reflect validator effective balances on-chain throughout their lifecycle.
To bridge the gap between Ethereum’s consensus layer and on-chain accounting, the protocol introduces Effective Balance Oracles (EBO), which track validator balances and update protocol state. Operating this oracle system in a decentralized and resilient manner requires participation and delegation by parties economically aligned with the protocol.
SSV Staking provides such a delegation mechanism, allowing SSV holders to stake their tokens and delegate their stake toward the selection of EBOs. Initially, there will be four permissioned EBOs; later, a DAO proposal will follow to allow permissionless EBOs. In doing so, protocol fee flows are reflected through the staking mechanism in proportion to protocol usage, strengthening alignment between token holders and the network.
Proposal Particulars
This proposal establishes the following:
- Proposal Summary
- Proposal Particulars
- Proposal Applicability
- a. Payment, Validator and Operator Changes
- b. Effective Balance Accounting and Effective Balance Oracle Introduction
- c. ssv.network DAO Multi-sig Committee Required Actions
- i. SSV Parameters
- ii. ETH Parameters
- iii. Operator’s fee transition to ETH fees
- iv. SSV Staking Parameters
- d. Incentivized Mainnet Changes
- c. SSV Foundation Required Actions
Proposal Applicability
If this proposal were to pass, the following would be its consequences:
Payment, Validator and Operator Changes
-
A transition to ETH payments, which means all new clusters will operate with ETH payments from the outset, meaning:
- a. Operator fees are paid in ETH.
- b. Network fees are paid in ETH.
- c. ETH must be deposited upfront to fund the cluster’s operational runway.
- d. Support for actively operating existing SSV-based clusters under the SSV payment model is removed. While these clusters may continue running as long as they have sufficient runway, they can no longer be maintained through operational changes.
This means that adding new validators, reactivating liquidated clusters or depositing additional SSV to extend a cluster’s runway is no longer supported. As a result, the only path forward for maintaining an existing cluster is migration to ETH payments, which restores full cluster functionality under the new payment and accounting model.
For cluster owners who do not wish to migrate or are unable to do so, the remaining option is to voluntarily liquidate the cluster. Self-liquidation returns the remaining cluster balance to the owner and signals operators to stop operating the cluster’s validators. However, if the intention is to continue operating the validators in the future, migration to ETH payments will be required in order to do so.
-
Cluster migration - To migrate, the cluster owner initiates the migration and deposits sufficient ETH to fund the cluster’s future operation runway under the ETH payment model. As part of the migration, the cluster’s accounting is switched from SSV to ETH, and any remaining SSV balance is returned to the cluster owner. Migration is a one-way process - once a cluster is migrated to ETH payments, it cannot revert back to SSV-based payments.
-
New Operators - New operators onboard directly with ETH-denominated fees. From launch onward, operators registering in the network will not be able to define or configure fees in SSV, and will operate exclusively under the ETH payment model.
-
Existing Operators - Existing operators continue earning SSV-denominated fees only for clusters that have not yet migrated. These SSV fees continue to accrue, but operators are no longer able to modify or adjust their SSV fee configuration. Accrued fees can still be withdrawn. Once their clusters migrate to ETH payments, or when new ETH-denominated clusters are onboarded, operators begin earning fees in ETH based on their pre-assigned ETH fee configuration. The relevant fee can be found further below.
Effective Balance Accounting and Effective Balance Oracle Introduction
-
Introduction of EBA - In the ETH-based model effective balance becomes the billing unit. Fees are defined per 32 ETH of effective balance and scale with a cluster’s total effective balance, rather than with validator count:
Here, total effective balance refers to the cumulative effective balance of all validators belonging to the cluster. All accounting is performed using this aggregated cluster-level value. As a result, ETH-based clusters pay fees proportional to the actual effective balance they secure, independent of how that balance is distributed across validator keys.
EBA replaces the SSV-based model where each validator is implicitly assumed to represent a fixed 32 ETH of effective balance. Fees, runway calculations and liquidation conditions, therefore scale linearly with the number of validators in the cluster, regardless of how much effective balance those validators actually secure. This is currently calculated by
(fees per validator) x validatorCountand under this mode, Fees are defined per validator. Total fees scale with validator count**.** Consolidated validators are not fully accounted for. This model continues to apply to all SSV-based clusters. As a result, Network fee deduction for compensation via the Incentivized Mainnet script continues to operate. Operators managing SSV-based clusters are not compensated based on the amount of stake they manage.Because updates are performed through periodic cluster-level sweeps, validators added to or removed from a cluster are initially accounted for using a default assumption of 32 ETH per validator. The actual effective balance of these validators - such as in the case of consolidated validators - will only be reflected once the next sweep occurs. As a result, cluster owners must account for the potential impact of delayed updates on runway and fee accrual, particularly when adding validators with higher effective balances.
-
Introduction of permissioned EBOs.
-
a. EBOs are responsible for tracking validator effective balances on the beacon chain and enabling the protocol to keep its on-chain accounting aligned with real validator state as balances evolve over time.
-
b. Validator effective balances live on Ethereum’s consensus layer. Smart contracts operate on the execution layer. Contracts cannot directly query consensus-layer states. Therefore, a bridging mechanism is required to reflect the consensus-layer balance state on-chain. EBOs provide that bridge.
-
c. In order to achieve the DAO’s stated goal of decentralizing Ethereum but doing so in the most ETH-aligned way, the suggestion is that the DAO adopt EBOs that will perform Effective Balance Accounting. In this regard, the EBOs on ssv.network play a similar role to that of validators on the Ethereum blockchain, both requiring a staking mechanism and possibly a delegation to a third-party performing the needed duties, thus fulfilling a crucial and integral part of the process. While oracles don’t validate transactions as validators do, they do maintain the integrity and security of the protocol by accurately attesting what a validator’s effective balance is, which is key for the safety of the ssv.network.
-
d. The protocol will initially launch with a set of permissioned EBOs for several practical reasons. From a testing and security standpoint, a fixed set of 4 oracles allows for a deterministic 3-of-4 quorum (75%), eliminates the risk of Sybil attacks, and keeps the attack surface well-defined and manageable. Operationally, permissioned EBOs ensure predictable uptime, clear responsibilities, guaranteed liveness, and a controlled environment to test infrastructure during the bootstrapping phase. This setup also simplifies debugging and incident response, guards against early adversarial behavior, and provides time to calibrate incentives before opening participation to the broader community.
- Kraken - 0xc61f7bd9ee5a3d011caf47aa0e5411f720593920
- InfStones - 0xc07332e05cec1c4896555a6d10361233fdf14422
- Ethernodes - 0x28bEa5B242362974d5DDb8f17a1E0e525446960B
- SSV Labs - 0x3A98EE5f80268Ed91F8A5880d93468b76a9F3bB4
-
e. Effective balance updates are performed in two steps, moving from global observation to cluster-level updates. Effective Balance Oracles continuously track validator effective balances on the beacon chain. At defined intervals, they take a snapshot of all validator balances, aggregate them per cluster, and construct a Merkle tree representing the effective balances of all clusters at that snapshot. To reach consensus on this snapshot, each oracle independently commits the Merkle root representing this snapshot. Once a threshold of oracle commitments is reached, the snapshot is accepted by the protocol as the authoritative and accurate view of effective balances for that point in time. This threshold-based mechanism ensures both the correctness of the data and that no single oracle can dictate balance updates. Once a snapshot is accepted, cluster-level effective balances can be updated on-chain by submitting a proof derived from the committed Merkle tree for a specific cluster. Updating cluster balances is permissionless so that anyone can submit a valid proof and bear the transaction cost. As a failsafe, EBOs are expected to periodically perform these updates themselves to ensure cluster balances remain current even if third parties do not act. When a cluster’s effective balance is updated, the protocol updates all related accounting based on the new value. This affects cluster runway calculations as well as future network and operator fee accruals tied to the amount of effective balance being managed. If an update causes a cluster to fall below liquidation thresholds, the cluster will be liquidated as part of the same process, ensuring that increases in effective balance are always matched by sufficient funding and collateral.
-
ssv.network DAO Multi-sig Committee Required Actions
-
The ssv.network DAO Multi-sig (MC) will update the following audited smart contracts to support the above operations:
- a. SSVNetwork (0xDD9BC35aE942eF0cFa76930954a156B3fF30a4E1)
- b. SSVNetworkViews (0xafE830B6Ee262ba11cce5F32fDCd760FFE6a66e4)
-
The MC will be required to add new smart contract modules to the abovementioned smart contracts, via the update mechanism already used in [DIP-19] Scaling Permissioned Operators Upgrade :
- a. SSVStaking
- b. SSVValidators
-
The MC will be required to update the modules of the abovementioned smart contracts, which are:
- a. SSVClusters
- b. SSVDAO
- c. SSVOperators
- d. SSVOperatorsWhitelist
- e. SSVViews
-
The “SSVNetwork” smart contract (section 7. subsection a) will gain the right to mint and burn cSSV. An ERC-20 token is received when SSV is staked into the abovementioned SSV Staking module by owners of SSV tokens, and it represents their staked position at a 1:1 ratio. Protocol fees accrue continuously as validators operate on the SSV Network and generate ongoing network fees. Stakers earn a pro-rata share of ETH-denominated fees, based on their share of the total staked SSV. Rewards can be claimed at any time without unstaking, and claiming does not affect the staking position.
When cSSV is transferred, rewards accrued up to that point remain claimable by the original holder, while the new holder begins accruing rewards only from the moment they receive the cSSV. cSSV represents a claim on the underlying staked SSV, as well as a share of protocol fees accrued to stakers. Staked SSV, represented by cSSV, retains full governance and voting power. For SSV to be unstaked a two-step process needs to be followed. First, the staker submits a withdrawal request. At this point, the specified amount of cSSV is immediately burned, and the corresponding amount of underlying SSV is set aside for the user. This action starts the cooldown period (proposed to launch at 7 days) and stops reward accrual from that moment. During the cooldown, the user no longer holds cSSV and therefore no longer has governance power or oracle weight for the withdrawn amount. Once the cooldown period ends, the staker can finalize the withdrawal and receive the reserved SSV at a 1:1 ratio relative to the original stake. Stakers may submit multiple withdrawal requests over time. When finalizing an unstake, the staker can claim the cumulative amount of all requests whose lock period has fully elapsed, while any requests still in their lock period remain locked. A maximum of 2,000 active withdrawal requests per address is supported.
-
If any source of the variables required for the formulas listed under section 16. was not adequately defined or is ambiguous, the Master of Coin will have the discretion to decide the source and method of calculation of such a variable. Any such decision must be publicized to the DAO forum in order to be effective. The MoC can only do this once per variable. Notwithstanding the foregoing, the MC will have the authority to amend any such source or method of calculation if any source or method becomes corrupted, unavailable, or becomes a security concern for the protocol. Such a decision by the multisig will follow the steps described by the Detrimental Situation procedure as described in [DIP-2] Multi-Sig Committee.
-
SSV-denominated clusters will use the following formulas for their parameters:
-
a. Minimum Liquidation Collateral (prescribed by [DIP-44] Re-Evaluation of Liquidation Collateral and Network Fee Parameters (“DIP-44”):
The sources and values for the variables of the Minimum Liquidation Collateral calculation are as follows:
- a. Gas Units: 252800
-
b. Liquidation Threshold (prescribed by DIP-44):
-
c. Network Fee - Prescribed by [DIP-49] Network Fee Ratio Maximum
- ETH-denominated clusters will use the following formulas for their parameters:
-
a. Minimum Liquidation Collateral:
The sources and values for the variables of the Minimum Liquidation Collateral calculation are as follows:- b. Gas Units: 226578
-
b. Liquidation Threshold:
-
c. Network fee:
The sources and values for the variables of the network fee are as follows:- i. Ethereum APR: defined as the 30-day trailing moving average of the ETH.STORE numbers from the API.
- ii. NetworkFee: Determined by the DAO as 1% of ETH staking APR, as determined by [DIP-11] Mainnet Proposal.
- iii. BlocksPerYear: 2613400
-
The MC will be tasked with updating the parameters listed under section 12 subsection (a), section 12 subsection (b), section 13 subsection (a), section 13 subsection (b), every quarter starting in April in the First Scheduled Batch of the months as described by [DIP-26] ssv.network DAO Four-Year Budget (2024-2028), using a 6-month trailing moving average, for the variables listed under the aforementioned sections, with data available at etherscan.io.
-
If the implementation of the parameters change prescribed by this proposal doesn’t happen before March 31st 2026, if and when the proposal does pass, the MC will be required to recalculate all values mentioned in this proposal through their respective formulas before implementation.
-
The following will become DAO-controlled parameters:
SSV Parameters
The following parameters will be set for SSV-Denominated clusters:
| Variable | Proposed Value |
|---|---|
| minimumLiquidationCollateralSSV | 0.673652 SSV |
| minimumBlocksBeforeLiquidationSSV | 50,120 |
ETH Parameters
The following parameters will be set for ETH-denominated clusters:
| Variable | Description | Update function | Proposed Value |
|---|---|---|---|
| ethNetworkFee | Protocol network fee charged in ETH. | updateNetworkFee(uint256 fee) | 0.000000003557694957 ETH (~0.00929768 ETH Annual) |
| minimumLiquidationCollateral | Minimum ETH collateral an ETH-denominated cluster must maintain; falling below this level contributes to liquidation eligibility. | updateMinimumLiquidationCollateral(uint256 amount) | 0.000644852 ETH |
| minimumBlocksBeforeLiquidation | Minimum number of blocks an ETH-denominated cluster must maintain a sufficient balance before becoming eligible for liquidation. | updateLiquidationThresholdPeriod(uint64 blocks) | 21,480 |
| minimumOperatorEthFee | Minimum operator fee cap for fees denominated in ETH. | updateMinimumOperatorEthFee(uint256 minFee) | 0.00000000001 ETH (~0.0000262 ETH annual) |
| operatorMaxFee | Maximum operator fee cap, setting a technical upper bound on operator fees denominated in ETH. This parameter exists as a protocol safety constraint to prevent extreme fee configurations and is not intended to express economic policy or target fee levels. | updateMaximumOperatorFee(uint256 maxFee) | 0.000000005336542435 ETH ETH (~0.01395 ETH annual) |
| defaultOperatorETHFee | Default ETH-denominated operator fee applied to existing operators during the transition from SSV-denominated fees to ETH-denominated fees. | Not governance-controlled. The default value is defined in the contract and applied automatically; it exists solely to facilitate operator migration and ensure continuity during the transition period. | 0.000000001778847478 ETH (~0.00465 ETH annual) |
Operator’s fee transition to ETH fees
| Operator charging | New Operator fees |
|---|---|
| 0 SSV | 0 ETH |
| <0 SSV | 0.000000001778847478 ETH (~0.00465 ETH annual) |
SSV Staking Parameters
| Variable | Proposed Value | Description |
|---|---|---|
| cooldownDuration | 604800 | Unstake cooldown duration (in seconds): the period users must wait between requesting an unstake and being able to withdraw their unlocked SSV. |
| quorumBps | 7500 (75.00%) | Quorum threshold (in BPS) required for committing an effective balance snapshot |
Incentivized Mainnet Changes
-
With the introduction of ETH payments, network fees for ETH-denominated clusters are no longer compatible with the Incentivized Mainnet (IM) fee deduction mechanism. Because ETH-cluster fees are already enforced on-chain via the new effective balance accounting model, off-chain deductions via the IM script are obsolete. For ETH-denominated clusters**,** Network fee deductions are removed. For SSV-based clusters**,** Network fees continue to be deducted from IM rewards under the existing model. To support this separation between legacy SSV-based and ETH-denominated clusters, a new Merkle Distributor contract will be deployed. This architectural separation ensures that incentive distribution remains aligned with each cluster’s accounting model. For Legacy clusters**,** claim rewards from the existing distributor. For ETH-denominated clusters**,** claim rewards exclusively through the new distributor contract. For Dual Participants**,** claim rewards separately per accounting type, interacting with both contracts accordingly.
- a. Incentivized Mainnet Program Administrator (IMPA) Responsibilities - The IMPA will now cover both distributor contracts. This includes the generation, validation, and publication of Merkle roots, as well as maintaining the integrity and correctness of reward calculations across both accounting types. The same applies to the SDVT and CSM administrator.
- b. MC Responsibilities - The MC will be tasked with updating the Merkle Root based on the updated IMP script and its results published by the IMPA.
SSV Foundation Required Actions
-
The SSV Foundation will be tasked with compensating the abovementioned EBOs. The funding will be provided by the SSV Foundation from the [DIP-42] SSV Foundation business development budget in the amount of 250 USD denominated in SSV, per month, based on a 7-day trailing moving average, calculated on the first of the month, for the previous month, executed in the First Scheduled batch for the duration of the permissioned phase of EBOs. Additionally, the Foundation will reimburse all Ethereum transaction costs incurred by the EBOs as part of their oracle duties, including balance updates and Merkle root submissions. In order to avoid unforeseen activity and liability, a cap to this reimbursement shall be defined as follows: in any given month, no single EBO will be reimbursed more than 0.5 ETH for the incurred transaction costs.
-
The SSV Foundation (Foundation) and the DAO will not participate in SSV staking for 6 months from the passing of this proposal. After this period, the DAO will reassess in a new DAO proposal whether and to what extent the Foundation or the DAO will participate in SSV Staking.
-
The SSV Foundation will update the SSV Network snapshot space and delegation-related tooling to adapt the voting strategies to support the cSSV token.