🦏
ETH Home Staking Collection
DVT Home Staking Curriculum
DVT Home Staking Curriculum
  • The DVT Home Staking Curriculum
  • Curriculum breakdown & timeline
  • Understanding ETH validators
    • Introduction to ETH Validators
    • Roles & Responsibilities of a node operator
    • Rewards and penalties
    • Importance of client diversity
    • Distributed Validator Technologies (DVTs)
    • Economics of using DVTs (WIP)
      • Diva Staking (WIP)
      • Obol (WIP)
      • SSV (WIP)
    • Bonded Validators
    • Economics of bonded validators (WIP)
  • Hardware & systems setup
    • Setup Overview
    • Hardware & system requirements
    • Procuring your hardware
    • Assemble your hardware
    • Practicing for free on Cloud VMs
      • Google Cloud
      • Alibaba Cloud
  • Linux OS, Networking, & Security
    • Install and prepare the OS
    • Networking & network security
    • Device level security setup
    • Verifying checksums
  • Installing & configuring your EL+CL clients
    • Set up and configure execution layer client
      • Nethermind
      • Besu
      • Geth
      • Erigon
      • Reth
    • Set up and configure consensus layer client
      • Teku BN
      • Nimbus BN
      • Lodestar BN
      • Lighthouse BN
      • Prysm BN
  • Keystore generation & MEV-Boost
    • Validator key generation
    • Set up and configure MEV-boost
  • Native Solo Staking Setup
    • Validator client setup
      • Teku VC
      • Nimbus VC
      • Lodestar VC
      • Lighthouse VC
      • Prysm VC
    • Depositing 32 ETH into your validator
    • Exiting your validator
  • Monitoring, Maintenance, and Updates
    • Set up monitoring suite
      • Installing & configuring Prometheus
      • Installing & configuring Node Exporter
      • Installing & configuring Grafana
      • Beaconcha.in App API
      • Client Uptime Check
    • Maintenance & Updates
      • Nethermind
      • Besu
      • Teku
      • Nimbus
      • Lodestar
      • Updating the monitoring suite
      • Preparing for Pectra
  • DVT Setup
    • Diva Staking
      • Diva Staking client setup
        • Default - All-in-one setup
        • Advanced - with standalone Lodestar VC
      • Registering your Diva node
      • Updating your Diva client
      • Monitoring your Diva Node
    • Obol
      • Techne Bronze Speedrun (Launchpad)
      • Obol + Bonded Validators (Techne Silver)
        • Obol + Lido CSM
    • SSV
      • SSV + Lido CSM (WIP)
      • SSV Operator
      • SSV Staker
  • Bonded Validators Setup
    • Lido CSM
      • Generating CSM keystores
      • Set Fee Recipient Address
        • Method 1: Configure on validator keys
        • Method 2: Configure on separate validator client
        • Verifying Fee Recipient Registered on MEV Relays
      • Upload/Remove/View validator keys
      • Rewards & bonds
      • Exiting CSM validators
        • "Lazy" exits (TESTNET ONLY)
        • Proper Exits
      • Role/Address management
      • Monitoring
      • Automations
        • CSM with ETHPillar
        • CSM with ETH Docker
        • CSM with Dappnode
    • Puffer
      • Non-Enclave: 2 ETH
    • Ether.fi
      • Receive distributed validator keyshares
    • Stader (WIP)
    • Rocketpool (WIP)
  • Liquid Staking Vaults
    • Stakewise V3
  • Mainnet
    • Mainnet Deployment
    • Heroglpyhs (WIP)
  • Best practices
    • Slashing prevention
    • Maximising uptime and performance
    • Optimising security
    • Managing your withdrawal wallet
  • Tips
    • Advanced networking
    • Downloading files from your node
  • Useful resources
    • General resources
    • Holesky Faucets
  • Automation/tools
    • ETHPillar
    • ETH Docker
    • Automated power on/off
      • Wake-on-LAN (WoL)
      • Network UPS Tools (NUT)
    • Validator Healthcheck Alerts
  • Solo Stakers Guild
    • Lido CSM+SSV+Obol (Testnet)
Powered by GitBook
On this page
  • Rewards
  • Penalties
  • Uncorrelated downtime
  • Correlated downtime
  • Double signing
  1. Understanding ETH validators

Rewards and penalties

PreviousRoles & Responsibilities of a node operatorNextImportance of client diversity

Last updated 12 months ago

Rewards

In exchange for processing transactions on the Ethereum network and providing economic security, validators receive rewards in the form of issuance, transaction fees (tips), and MEV bribes. Issuance is received from performing attestations and tips + MEV bribes are received from proposing blocks.

The breakdown of these fees on average are as follows:

  1. Consensus Layer (issuance): 2.85%

    • Block attestation

    • Sync committee duties

  2. Execution Layer (Block rewards): 0.58%

    • MEV and transaction tips

Average total: ~3.42% APR

Block attestation rewards

This component of validator rewards are relatively stable and changes slowly according to the number of active validators on the network - e.g. more validators = lower attestation rewards, less validators = higher attestation rewards.

Sync committee rewards

Every 24 hours, 512 validators are chosen randomly out of the validator network to perform sync committees duties for the next 24 hours. During this period, the computational load on the 512 validators are increased along with the rewards they receive. However, penalties incurred also increase at the same rate if the chosen validators are offline during this period.

The purpose of the sync committee is to allow Light Clients to keep track of the chain of beacon block headers.

Block rewards

Every epoch (6.4 minutes), 32 validators will be chosen as the block proposers for each block in that epoch. Block proposers will receive all transaction tips (paid by users) and MEV fees (paid by block builders) for their respective blocks.

Important Note: Because the APR from block rewards are random and can be very large when they occur (i.e. a heavy right skew), the median total APR, which is what most validators will be getting is closer to 3.5%.

These rewards are received every ~6.4 minutes (every epoch) and the accumulated balance is automatically withdrawn to your designated wallet every 6 days.

Penalties

Uncorrelated downtime

On the other hand, you will be penalised if your validator goes offline or is otherwise inactive. Under normal circumstances, your validator should not go offline together with other validators - i.e. "uncorrelated downtime" - and if so, your inactivity penalties per epoch will be roughly the same as your rewards rate per epoch. Unless of course, you miss your turn to propose a block while you were inactive.

This means that you typically don't have to panic when you start seeing missed attestations and should rather take your time to make sure you don't make a mistake when you troubleshoot your validator node.

Correlated downtime

However, if your validator node goes down together with a large portion of the network, you will be penalised more heavily.

The inactivity leak is a state of emergency to compel the inactive 1/3 to resume their duties or otherwise removing them (and their ETH) from the network until the network has >2/3 of active validators once again.

There are two main mechanisms that will occur during an inactivity leak:

  1. Normal attestation rewards will stop for all validators. Block proposers will still receive their normal rewards from all 3 sources

  2. Quadratic leak - where inactive validators will suffer increasing penalties that grows quadratically over time until the network has >2/3 of active validators once again

Double signing

Double signing is a slash-able offense and occurs when your validator:

  1. Signs two different beacon blocks for the same slot while serving as proposer - i.e. endorsing two different versions of the chain's history

  2. Signs an attestation that “surrounds” another one while serving as an attester - i.e. trying to change the history of the chain

  3. Signs two different attestations with the same target while serving as an attester - i.e. signing the same block twice using the same key

Although these slashing mechanisms were set in place to discourage dishonest or malicious behaviour by the validator network. They can be cause by negligence and misconfiguration as well. In fact, all of the slashing incidents to-date have been due to common technical mistakes and you can learn how to prevent them below.

When your validator is slashed, the following sequence of events will take place.

  1. Your validator will be forcibly scheduled to exit the network within the next 36 days

  2. Receive a minimal penalty of 1/32 of your effective balance initially when a whistleblowing validator reports your validator

  3. Incur additional penalties for missing your validator duties over the next 36 days until your validator exits the network

  4. Additionally, a special penalty will be imposed on your validator for correlated slashing. This penalty increases with the number of other validators that were slashed over the same period as yours and can even come up to your entire effective balance.

In an extreme scenario, where more than 1/3 of the network goes offline, causing the chain to be in danger of splitting, the will be triggered.

"inactivity leak"
Slashing prevention
Last 30 days data from Rated.Network. 2nd June 2024.