website

twitter

Liquid staking

SSV Network

# SSV Network Revenue Methodology

## 1. Overview

Revenue measures the network fees retained by the SSV Network protocol, which are collected from stakers utilizing the decentralized validator infrastructure. These fees are accumulated by the DAO to support the protocol's growth and ecosystem, representing the protocol's take rate separate from the operator fees distributed to node operators. Prior to the network upgrade, revenue is calculated based on the daily count of active validators and the established network fee per block. Following the network upgrade, revenue is derived directly from the network fees synced to the protocol's staking pool.

## 2. Data sources

- **Blockchain events**: `ValidatorAdded`, `ValidatorRemoved`, `ClusterLiquidated`, `ClusterReactivated`, `ClusterMigratedToETH`, `NetworkFeeUpdated`, and `FeesSynced` events from `SSVNetwork` contracts, covering Ethereum
- **External data**: End-of-day price feeds for SSV and WETH assets

## 3. Step-by-step calculation

### Component A: Active validator tracking (Pre-upgrade)
- **Purpose**: Track the daily number of active validators accruing fees before the network upgrade.
- **Logic**: Daily changes in active validators are calculated by parsing events from `SSVNetwork` contracts. The active validator count is incremented by 1 upon `ValidatorAdded` events and decremented by 1 upon `ValidatorRemoved` events, provided the associated cluster is active. Cluster state changes are also factored in: the active validator count is decremented by the cluster's validator count upon `ClusterLiquidated` events, and incremented by the cluster's validator count upon `ClusterReactivated` and `ClusterMigratedToETH` events. At the upgrade block, all active validators are decremented to zero to halt pre-upgrade accrual.
- **Key fields**: `owner`, `operator_ids`, `validator_count`, `cluster_active`, `block_timestamp`

### Component B: Network fee parameter tracking (Pre-upgrade)
- **Purpose**: Determine the network fee rate per validator per block.
- **Logic**: Network fee changes are tracked by parsing `NetworkFeeUpdated` events from `SSVNetwork` contracts. The fee is denominated in the SSV asset before the upgrade block and in the WETH asset after the upgrade block. The latest fee in force at the end of each day is selected.
- **Key fields**: `fee`, `fee_token_address`, `block_timestamp`

### Component C: Post-upgrade synced fees tracking

- **Purpose**: Capture network fees synced to the staking pool after the network upgrade.
- **Logic**: Synced network fees are extracted by parsing `FeesSynced` events from `SSVNetwork` contracts. These amounts are denominated in the WETH asset and aggregated daily.
- **Key fields**: `amount`, `token_address`, `block_timestamp`

### Component D: Daily revenue calculation and USD conversion

- **Purpose**: Calculate daily revenue in USD by combining pre-upgrade and post-upgrade fee logic.
- **Logic**: For days prior to the network upgrade date, daily revenue is calculated by multiplying the active validator count by the daily network fee (the fee per block multiplied by 7,200 blocks per day). For days on or after the upgrade date, daily revenue is determined by the daily sum of synced network fees. All fee amounts are normalized by decimal precision and multiplied by the respective end-of-day asset prices to obtain the final revenue in USD.
- **Key fields**: `revenue`, `token_address`, `timestamp`

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

SSV NetworkSSV

Revenue

Revenue

Competitive landscape