Introduction to SSV Staking

This post breaks down the changes and mechanics behind SSV Staking and the big reveal of cSSV, the token that represents a staked SSV position and serves as the interface for ETH-denominated staking rewards. We’ll walk through how the protocol shifts from SSV-denominated fees to ETH, how effective balance accounting upgrades the system for post-Pectra validators, how oracles keep balances accurate on-chain, and what changes to the Incentivized Mainnet program are expected as SSV moves to a more ETH-centric model.

Disclaimer: The following represents a vision for the future of SSV Network and is subject to approval by the SSV DAO.

What is SSV staking in a nutshell?

At a high level, SSV Staking is a mechanism that allows SSV holders to lock their tokens into a staking contract and receive a claim to a share of network fees collected in ETH and paid out in ETH. Instead of fees being paid in SSV and managed off-chain, SSV Staking is built on an ETH-denominated accounting model native to the protocol.

The idea is simple: 

• ETH-denominated cluster fees: This reduces cross-asset price dependency (SSV/ETH), simplifies runway planning, and makes protocol accounting more direct and predictable for users and operators.
  
  

• Effective balance accounting: Post-Pectra, the validator balance and solvency logic need to scale with validators’ actual effective balances, not a fixed ‘per-validator’ calculation. Because effective balance lives on Ethereum’s consensus layer and can’t be read directly by smart contracts, the protocol will need to rely on an Effective Balance Oracle set, with oracle composition supported over time via staking and delegation by SSV stakers.
  
  

• SSV stakers rewarded via ETH network fees: Under the proposal, protocol/network fees denominated in ETH are designed to be reflected through the staking mechanism in proportion to participation, enabling SSV to function as an ETH accrual token model.

SSV staking brings major upgrades to protocol fees & accounting

The implementation of SSV staking will change how network and operator fees are calculated and how incentivized mainnet rewards are distributed.

ETH-denominated fees and cluster accounting

SSV Network operator fees are currently denominated in SSV. But operators and validator owners think in terms of ETH. At the same time, price movements between SSV and ETH forced parameter tweaks, as the SSV token didn’t reflect the growth of the SSV Network (now the second-largest staking infrastructure on Ethereum).

SSV Staking requires a shift: both operators and the protocol collect fees directly in ETH. Each validator cluster is tagged with an accounting denomination type, either SSV or ETH, and the protocol maintains separate indices for each. Over time, the network will favor ETH-denominated clusters because they make managing operator runway simpler. 

Inside the contracts, each cluster is modeled as a structure that now includes its accounting type alongside its other fields. This allows the protocol to keep existing function signatures largely intact while extending the internal logic to handle both SSV and ETH fee flows. The main point is that an ETH cluster settles all of its obligations in ETH and accumulates its fees in ETH-specific indices, which then feed into the staking reward logic.

Incentivized Mainnet (IM) rewards are distributed in SSV, while network fees for these clusters are paid in ETH. As a result, network fees cannot be deducted from Incentivized Mainnet rewards for validators operating as part of ETH-denominated clusters.

The IM script will be updated to differentiate between cluster types:

• ETH-denominated clusters: IM network fee deductions are removed.

• Legacy SSV-based clusters: IM network fees continue to be deducted under the existing model.

Liquidations

The transition to ETH payments introduces a new liquidation framework specifically for ETH-denominated clusters.Because network fees, collateral, and liquidation execution are all denominated in ETH, the overall risk profile is materially lower than under the SSV-based model. This allows liquidation parameters to be significantly more capital-efficient while maintaining safety.

New fee calculation: Moving from “Per Validator” fee to “Effective Balance”

Ethereum’s Pectra upgrade raised the maximum Effective Balance per validator from 32 ETH up to 2,048 ETH. This means a single validator can represent a much larger amount of stake, and that stake still earns rewards. If the protocol continues to charge fees per validator, assuming every validator represents exactly 32 ETH, it will undercharge large consolidated validators and lose revenue.

The SSV Network’s original accounting model was based on validator count, not effective balance. SSV Staking changes that. Instead of assuming every validator is equal, the protocol now tracks a value called clusterEB for each cluster, which represents the cumulative effective balance of all its validators. In parallel, it maintains operatorEB for each operator, reflecting the total effective balance they help manage across all clusters.

These effective balance values become the scaling factors in fee calculations. When a network fee index or operator fee index updates, the protocol multiplies the change by the relevant clusterEB or operatorEB to determine the amount of ETH owed. In other words, fees scale with the actual stake, not just the count of validator keys. This is essential if SSV Staking is going to distribute fees fairly and capture the full value created by large validator setups.

EB Oracles: Bringing validator balances on-chain for fee calculation

Validators’ effective balances live on the consensus layer. The SSV contracts cannot query the beacon chain directly, so they will need to rely on a dedicated set of Effective Balance Oracles to bridge that data on-chain.

EB Oracles operate as off-chain services, ideally as sidecars to existing SSV nodes (TBD). On a regular schedule, they scan all validators associated with SSV clusters, read their effective balances from the beacon chain, and aggregate the results per cluster. When they detect that a cluster’s total effective balance has changed in accordance with the DAO-set thresholds, they propose an update on-chain.

The protocol enforces two key safeguards here. First, an update must exceed a configurable buffer before it is accepted. Tiny fluctuations are ignored to save gas and avoid message overhead. Second, any new effective balance must be consistent with protocol constraints, such as not exceeding (the maximum allowed per validator x the number of validators in the cluster).

Updates are applied through a dedicated function that settles any outstanding fees based on the old effective balance before writing the new one into storage. This ensures fee accrual remains continuous and correct even as validator balances change.

In the early stages, EB Oracles may be run by a smaller, more centralized set of participants to accelerate time to market. Over time, governance can expand and decentralize the oracle set, introduce stake-weighted selection, and define incentives or penalties for oracle behavior.

Stake SSV, hold cSSV, earn ETH

SSV Staking is a way for SSV holders to participate in maintaining and securing a core protocol function (EB Oracles), and to have protocol fee flows reflected through that mechanism in proportion to their participation.

SSV holders can stake their tokens in the SSV Staking contract and receive cSSV, an ERC-20 token that represents their staked position 1:1. Stakers earn a pro-rata share of ETH-denominated fees, based on their share of the total staked SSV. While you hold cSSV, ETH rewards accrue to the wallet holding cSSV and can be claimed at any time without the need to unstake SSV. 

Potential rewards can be simulated here. 

As part of staking, stakers must delegate their voting power. This delegation determines the composition of the Effective Balance Oracle set.

In the initial phase, delegation is automatically split evenly across the DAO-elected oracle set to establish a stable starting point, while building toward permissionless oracle selection in future phases.

Crucially:

• Holding cSSV retains full governance and voting power.

• Staking is flexible, but allows opting into long-term participation in the protocol.

cSSV isn’t just staked SSV - It’s a new relationship between critical Ethereum infrastructure and the SSV community.

The road to SSV Staking

Join the discussion

SSV staking is currently in the discussion phase before the proposal goes to a vote. The SSV DAO is considering all community comments and suggestions. Join the forum discussions to make your voice heard.