Rethinking SSV: The Why and What of Its Tokenomics Shift

Key Takeaways

• DVT is key infrastructure for removing single points of failure in validator operations. SSV Network has implemented it as a permissionless protocol accessible to anyone, and it has grown into an infrastructure layer used by about 17% of all ETH staked on Ethereum. Within the DVT market, it has effectively become the standard.

• The essence of the SSV tokenomics essence is a redefinition of the token's role. The previous utility, as a fee payment gate, is removed through the shift to ETH. In its place, cSSV is given two functions: the right to receive a share of network fees in ETH and the right to participate in oracle selection.

• The practical effect of the transition will depend on execution. The main points to watch are whether the Effective Balance Oracle can move to a decentralized model, whether cSSV can secure DeFi liquidity, and whether the bApps ecosystem can show visible progress.

1. DVT and SSV Network

1.1 Ethereum's single point of failure problem

One of the main vulnerabilities in Ethereum's Proof of Stake (PoS) structure is the problem of a single point of failure. Under the conventional validator operating model, a single validator signing key, the BLS private key, runs on only one physical node. This structure concentrates a range of risks in a single key, including hardware failure, network disconnection, client bugs, key management mistakes, and geographic centralization.

The largest of these risks is slashing. If a validator signs two different blocks in the same slot or submits conflicting attestations, slashing occurs. In that case, at least 1/32 of the deposit is burned immediately. If many validators are slashed at the same time, a correlation penalty applies, and the validator may lose up to the full deposit.

The problem is that slashing can occur even without malicious intent. If two nodes in a redundancy setup for failover are unintentionally active at the same time, or if a client bug causes signatures on different blocks in the same slot, the protocol cannot distinguish that from malicious behavior. For institutions operating hundreds or thousands of validators, this is a serious operational risk.

Various approaches have been introduced to mitigate these risks, including doppelganger detection, remote signers, and exchange-delegated staking, but none have moved beyond the fundamental premise that one complete key is held by one party.

Distributed Validator Technology (DVT) changes that premise. It is designed so that no one holds the full key alone, and multiple independent nodes generate valid signatures through cryptographic consensus. This eliminates the structure in which a single node's failure immediately leads to downtime or penalties, and reduces dependence on any single operator.

1.2 How DVT works

At the core of DVT is splitting a validator signing key into multiple encrypted key shares and distributing them across independent node operators.

To understand this, it helps to look first at the key structure of an Ethereum validator. A validator holds a withdrawal key and a validator key. The withdrawal key is used only to move assets and can therefore be kept in a cold wallet. As a result, the only key exposed online during actual validation is the validator key, and that is the key DVT is designed to protect.

DVT divides this validator key into multiple pieces and distributes them across multiple operators. It uses Shamir's Secret Sharing. Under this method, a valid signature can be produced only when at least a preset threshold number of shares are combined, and fewer shares reveal no information about the original key.

For example, in a cluster of four operators, validator duties can still be performed as long as three are operating normally. This is a 3-of-4 threshold structure. The complete key exists nowhere in full. With a Distributed Key Generation (DKG) protocol, each node generates only its own key share independently, so there is no moment when the full key comes together in one place.

When a signature is needed, each node creates a partial signature using its key share. Those partial signatures are then combined into one valid signature through the homomorphic property of BLS signatures. From the beacon chain's perspective, this is indistinguishable from the signature of a normal validator. At the chain level, there is no way to tell whether that validator is using DVT.

This structure is close to active-active redundancy. Rather than switching to a standby server after a failure, all nodes participate in consensus under normal conditions. Even if some nodes fail, the remaining nodes can continue signing immediately. There is no failover delay, and the risk of slashing from duplicate operation is lower.

DVT alone, however, is not enough. It solves the cryptographic problem of key distribution, but practical issues remain at the operational level. These include how to find trustworthy operators to hold the key shares, which network should be used for consensus and partial signature exchange among operators, how operating fees should be settled, and how the entire process should be managed transparently on-chain.

A protocol layer is needed to turn DVT from a technical method into infrastructure that works in real staking environments. SSV Network was created to fill that gap.

1.3 SSV Network, the infrastructure layer for DVT

SSV Network (@ssv_network) is a prominent decentralized infrastructure implementation that makes DVT usable in practice for anyone. The network has two main layers.

The first is the contract layer deployed on Ethereum mainnet. The smart contracts in this layer handle operator registration, validator registration, encrypted key share storage, and fee settlement in a permissionless way. A staker only needs to designate four or more operators in the contract and upload the key shares, and the operators begin operating automatically when they detect the contract events. Because operators do not need separate coordination in advance, this contract layer is the main feature that lets SSV scale DVT from a technical method into a functioning market.

The second is the off-chain P2P execution layer. Each operator maintains a validator client and key shares on independent infrastructure, and exchanges partial signatures over a libp2p-based network. Using the QBFT consensus protocol, the operators reach agreement on a given block. When at least three out of four agree on the same block, their partial signatures are aggregated to reconstruct a single BLS signature that is mathematically equivalent to a signature produced with the original key. Because operators can participate from different regions and run different consensus and execution clients, this structure improves both geographic distribution and client diversity.

As a result, SSV Network manages on-chain, in the contract layer, who delegates operations to whom and at what price, while the P2P layer distributes the actual validator signing process. Through this dual structure, SSV has turned DVT, a cryptographic primitive, into a staking infrastructure that anyone can access.

At present, SSV Network safeguards more than 6.5 million ETH in staked assets and, as of March 2026, accounts for about 17% of all ETH staked on Ethereum. It maintains validator efficiency at around 98% to 99%, and currently has 151,000 validators and about 2,000 node operators participating.

Institutional adoption has increased noticeably. In August 2025, the global exchange Kraken migrated its Ethereum validator operations to SSV-based DVT, and more than 80 partners, including Lido, Ether.fi, StakeWise, and P2P.org, are running staking services on SSV infrastructure.

Behind this rapid adoption lies not only the technical advantages of DVT but also a significant economic incentive. Through its Incentivized Mainnet (IM) program, SSV Network distributes SSV tokens to validators registered on the network, offering up to 6% in additional APR. For liquid staking protocols competing fiercely on yield, the ability to layer subsidy-driven returns on top of DVT's reliable uptime has been a compelling driver of adoption.

2. The SSV tokenomics transition and its implications

SSV Network has grown into a core part of Ethereum's staking infrastructure, but its tokenomics did not keep pace with that growth. The main problem was the fee structure. Validators earn rewards in ETH, but fees paid to operators had to be paid in SSV tokens. As a result, the SSV token functioned less as a way to capture the value of protocol growth and more as a payment gate that users had to pass through to use the service.

Source : SSV Governance Forum

A document revisiting the marketplace and fee model, posted to the SSV governance forum in July 2025, summarized the problems caused by this SSV token-based fee system in three points.

• First, revenue and costs are denominated in different assets. Revenue is earned in ETH while costs are paid in SSV, so operators had to absorb the decline in profitability directly when the SSV price fell.

• Second, fee competition became too aggressive. Competition among public nodes pushed prices down, while the fee increase rules, a 14-day waiting period and a maximum 10% cap, made it hard to respond quickly to changes in market conditions.

• Third, the incentive structure became distorted. Large institutions that set fees at zero absorbed a large share of network subsidies, while public operators that had actually supported the ecosystem were left at a relative disadvantage.

The asset mismatch problem, in particular, was not unique to SSV. The crypto industry has long returned to the question of whether an Ethereum-based protocol really needs a separate token. Even when a protocol creates real value, a structure that forces users to buy a separate token just to use the service has been criticized for adding unnecessary cost and complexity.

Alon Muroch (@AmMuroch), founder of SSV Labs, has also publicly acknowledged this disconnect. His point was that despite the rapid growth of SSV Network, the SSV token's value has failed to reflect that growth, remaining structurally detached from ETH staking rewards. The technology was growing, but the token was structurally separated from the value it was supposed to capture. SSV was facing the same pattern internally.

Source : SSV Governance Forum

In response to these accumulated problems, a full tokenomics overhaul was posted to the SSV governance forum in January 2026. The proposal is currently in the stage of collecting community feedback ahead of a Snapshot vote by the DAO. The Hoodi testnet officially launched on February 23, 2026 and ran through March 6. The proposal has three main elements: billing based on effective balance and the introduction of an oracle system, a shift to an ETH-centered fee model, and the introduction of cSSV.

2.1 Billing based on effective balance and the oracle system

Before Ethereum's Pectra upgrade, the fixed assumption of "32 ETH per validator" still held. Now a single validator can stake up to 2,048 ETH. This change made the old validator count-based billing system inefficient. For example, it is not fair for a validator operating with 1,024 ETH and a validator operating with 32 ETH to pay the same fee.

Under the new model, the billing unit changes from the number of validators to the total effective balance of a cluster. A validator operating with 64 ETH pays twice the fee of a 32 ETH validator, and operators are compensated in proportion to the amount of ETH they actually manage. That means network fees, operator fees, runway calculations, and liquidation decisions all work on the basis of effective balance.

The problem is that information on a validator's effective balance exists only on Ethereum's consensus layer, the beacon chain. Smart contracts on the execution layer cannot read this data directly. To bridge that gap, an Effective Balance Oracle system is introduced.

The composition of the oracle set is determined by delegation from cSSV holders. When an SSV holder deposits SSV into the staking contract, they receive cSSV and at the same time must delegate their staking weight to a specific oracle operator. Operators that receive the most delegation form a Permissionless Oracle Committee. An oracle that loses performance or trust can be replaced naturally as delegation is reallocated.

Each operator in the oracle committee continuously tracks validator effective balances on the beacon chain and, at fixed intervals, builds a Merkle tree based on cluster-level aggregated values and submits the root on-chain. A quorum of at least 75% must sign the same Merkle root for the snapshot to be approved as official data. As a result, even if a single oracle submits an incorrect value, it is not reflected unless quorum is reached.

Once a snapshot is approved, anyone can submit a Merkle proof to update a given cluster's on-chain effective balance. When an update occurs, the protocol recalculates fees and runway based on the new effective balance. If the deposit falls below the liquidation threshold, the cluster is deactivated in the same transaction.

2.2 A fee structure centered on ETH

Source: SSV Network Docs

The second part of the overhaul is to change the payment unit for network fees and operator fees from SSV to ETH. Because validators earn rewards and pay fees in the same asset, operators can secure stable income in ETH regardless of token price volatility, and stakers can manage operating costs without separate conversion or hedging. For institutional investors, the barrier created by additional token exposure also falls.

After the transition, all newly created clusters will operate in ETH from the start. Existing SSV-based clusters will no longer be able to add SSV deposits, add or remove validators, or reactivate liquidated clusters. To continue operating, they will have to migrate to the ETH payment structure.

Default operator fees will also be reset. To ease the fee race to the bottom and the incentive distortion described above, operators whose SSV fee was previously non-zero will automatically be assigned a base ETH fee equivalent to about 0.5% of Ethereum staking rewards for a 32 ETH validator. Given that the current network average fee is about 0.1% of rewards, this can be seen as an attempt to restore an operator compensation structure weakened by the race to the bottom.

Furthermore, the subsidy absorption structure exploited by large institutions, which was the most problematic aspect of the previous model, is also substantially mitigated. Under the previous model, institutions could set operator fees at zero and rely on the rule that automatically deducted network fees from IM subsidies. This allowed them to maximize subsidy income without bearing those costs themselves.

Under the new structure, subsidies are paid in SSV, while network fees must be paid in ETH. As a result, the automatic deduction mechanism no longer works. Because all clusters must now acquire ETH separately to pay network fees, this pathway is no longer automatic, and the incentive to exploit it is significantly reduced.

2.3 The introduction of cSSV

Shifting fees to ETH, however, also means removing the existing utility of the SSV token as a fee payment asset. In fact, the governance forum also raised the question, "If fees are switched to ETH, what utility remains for the SSV token aside from revenue and governance?" SSV staking and cSSV were designed to fill this gap.

When an SSV token holder deposits tokens into the staking contract, they receive cSSV, an ERC-20 token called Composable SSV, at a 1:1 ratio. cSSV is not just a deposit receipt token. It has three functions:

• First, it represents the right to receive a share of network fees. A portion of the network fees, paid in ETH by clusters, flows into the staking contract, and cSSV holders receive ETH in proportion to their share of total staked SSV. This income is not automatically redistributed. Users must claim the accumulated ETH from the contract themselves.

• Second, it gives holders voting power in the selection of the Effective Balance Oracle described above.

• Third, it carries governance voting rights. cSSV retains the same governance rights as SSV, so staking does not reduce the holder's ability to participate in protocol governance.

For more detail, see the earlier comment "SSV Staking — A step toward Ethereum's extended infrastructure."

The testnet released on February 23, 2026, also introduced ways to use cSSV liquidity in DeFi protocols. For example, cSSV can be used as collateral in lending protocols or supplied to liquidity pools. This allows holders to improve capital efficiency without unstaking their SSV. It also suggests that cSSV may have independent liquidity in addition to its role as a deposited asset. This points to an effort to replace the lost fee-payment utility with a new use case rooted in DeFi composability.

3. Conclusion

SSV's tokenomics transition is taking place alongside changes across the Ethereum ecosystem. In January 2026, Vitalik Buterin (@VitalikButerin) outlined a Native DVT concept that would integrate DVT directly into Ethereum's consensus layer at the protocol level.

Source : ethresear.ch

Vitalik proposed a model in which a validator can register up to 16 keys and operate them in a distributed way. This suggests that DVT may move from middleware into Ethereum's core infrastructure. For SSV, this means that the importance of DVT has been demonstrated, but it also means that protocol-level integration could become a source of competitive pressure over time.

Moreover, given that the IM subsidies currently driving SSV's large-scale adoption cannot continue indefinitely, the window available to SSV is not unlimited. In that light, the tokenomics overhaul reads not as a simple revenue model adjustment, but as a challenge to break free from subsidy dependence and build a self-sustaining value cycle.

For more detail, see the earlier comment "DVT-lite: The Institutional Staking Infrastructure Standard."

Ultimately, as DVT moves toward becoming essential infrastructure in Ethereum, the success of SSV Network's strategic pivot will depend on execution. The key things to watch are the move from the cSSV testnet to mainnet, and whether the Based Applications Chain and the bApps ecosystem, which this article did not cover in detail, can take shape.