Skip to main content

Cluster Balance

The cluster balance needs to be kept in check to ensure the continued operation of its validator(s). This page explains how to calculate cluster balance at a specific blockchain block.

It is important to be aware that the cluster balance must always be higher than the required collateral for the cluster, so only the portion of the cluster balance exceeding the Liquidation Collateral can be used to calculate the Operational Runway.

Operational Runway

Since operator and network fees are dynamic, the required Liquidation Collateral could vary between different clusters. To calculate how much funding is needed as collateral for a cluster, please refer to the Liquidations page.

Cluster Balance Formula

As explained in the documentation page related to Payments, cluster balance is affected by three main factors:

  • Network fee
  • Operator fees
  • Effective balance

To track changes over time, the concept of Indexes has been introduced. Indexes for network fees and operator fees are necessary to calculate the cluster balance, along with the "snapshot" of the cluster status, taken the last time it was updated (the cluster snapshot is also used in smart contract transactions).

Cluster balance

To calculate the updated cluster balance, given the cluster balance from most recent snapshot, you can use this formula:

balancen=balancesnapshot(Δnetwork fee+Δoperators fee)eb/32balance_n = balance_{snapshot} - (\Delta_{network\ fee} + \Delta_{operators\ fee}) * eb / 32

Legend:

  • balancenbalance_n - cluster balance at block number n in ETH
  • balancesnapshotbalance_{snapshot} - value of the cluster balance on its latest snapshot
  • Δnetwork fee\Delta_{network\ fee} - Change in network fees paid since the last snapshot
  • Δoperators fee\Delta_{operators\ fee} - Change in operator fees paid since the last snapshot
  • ebeb - total effective balance of validators managed by the cluster

Network fees delta

Below is the formula used to calculate the network fees owed since the last cluster snapshot:

Δnetwork fee=nfip+(bnfbp)nfnfic\Delta_{network\ fee} = nfi_p + (b - nfb_p) * nf - nfi_c

Legend:

  • Δnetwork fee\Delta_{network\ fee} - Change in network fees paid since the last snapshot
  • nfipnfi_p - Protocol Network Fee Index, the latest protocol-wide network fee index
  • bb - Block number of the latest blockchain block
  • nfbpnfb_p - The block number at which the Protocol Network Fee Index was taken
  • nfnf - The current network fee
  • nficnfi_c - Cluster Network Fee Index, the latest network fee index for the given cluster

Operators fees delta

Similarly, below is the formula used to calculate the operators fees owed since the last cluster snapshot:

Δoperators fee=(ofin+(bofbn)ofn)ofic\Delta_{operators\ fee} = \sum(ofi_n + (b - ofb_n) * of_n) - ofi_c

Legend (n represents the nth operator in this cluster):

  • Δoperators fee\Delta_{operators\ fee} - Change in network fees paid since the last snapshot
  • ofinofi_n - Operator Fee Index, the latest protocol-wide network fee index
  • bb - Block number of the latest blockchain block
  • ofbnofb_n - The block number at which the Operator Fee Index was taken
  • ofnof_n - The current operator fee for the nth operator
  • oficofi_c - Cluster Index, the latest index for the given cluster

Have a look at how to collect the necessary data to calculate the balance on the Subgraph Examples page.

A programmatic example of calculating the cluster balance has been added to the SSV SDK.

Burn Rate

The rate at which a cluster spends ETH per block. It is the sum of all operators' fees with the current network fee, divided by effective balance of a cluster.

Burn  Ratecluster=((ofin)+nf)eb/32Burn\;Rate_{cluster} = (\sum(ofi_n) + {nf}) * eb / 32

Legend:

  • ofnof_n - The current operator fee for the nth operator
  • nfnf - The current network fee
  • ebeb - total effective balance of validators managed by the cluster

Operational Runway

Any additional funds added to the cluster balance on top of the required collateral will prolong the operation of its validators and are usually referred to as Operational Runway. Users can manage their clusters balance by depositing or withdrawing funds at will, knowing that all extra funds added to the cluster balance will increase its operational runway.

To calculate the effects of deposits and withdrawals on your cluster’s operational runway:

Operational  Runway=Residual  Balance/Burn  RateclusterOperational\;Runway = Residual\;Balance / Burn\;Rate_{cluster}

Legend:

  • Residual  BalanceResidual\;Balance - Amount of ETH in the cluster balance, exceeding the Liquidation Collateral
  • Burn  RateclusterBurn\;Rate_{cluster} - The rate at which a cluster spends ETH per block

Deposits

Deposits can be made to a cluster's balance to ensure the cluster avoids liquidation and to extend its operational runway.

Withdrawals

Withdrawals allow users to remove any excess balance they have for capital efficiency. Users may not withdraw a cluster's liquidation collateral. The collateral can only be withdrawn only when off-boarding the cluster (by removing all validators in the cluster). This means that in order to maintain a validator’s operation, a user can only withdraw in the range of their runway.