LogoLogo
HomeCommmunityLegal
  • Getting started
    • Welcome
    • Useful links
    • Framing the problem
    • Design goals
  • Methodologies
    • Ethereum Beacon Chain
      • Resources
      • Network explorer definitions
        • Landing page
        • Entity views
          • Top screener
          • Entity overview
          • Consensus layer statistics
          • Execution layer statistics
          • Aggregate rewards statistics
        • Aggregate views
          • Trending
          • Network overview
            • Gini coefficient measurement
          • Relayer landscape
          • Builder landscape
        • Misc
          • Index Coop dsETH
      • RAVER methodology
        • Proposer effectiveness
        • Attester effectiveness
        • Effectiveness rating
        • Slashing moderator
        • Sync committees
        • Post-hoc analysis of the Rated v0 effectiveness rating
      • Penalties and Missed Rewards methodologies
        • Penalties computation
          • Pre-Altair penalties computation
        • Validator missed rewards computation
          • Consensus missed rewards computation
          • Execution missed rewards computation
      • Baseline MEV computation
      • Aggregating validator indices
        • Classes of aggregation
    • Miscellaneous
      • Value enabled by Rated
  • API documentation
    • Introduction
    • Getting past authentication
    • API guide
    • Swagger schema
  • Legal
    • ToU & Privacy Notice
      • Website Terms of Use
      • API Terms of Use
      • Privacy Notice
  • Community
    • 🍬Let's Rate!
Powered by GitBook
On this page

Was this helpful?

  1. Methodologies
  2. Ethereum Beacon Chain
  3. Penalties and Missed Rewards methodologies

Penalties computation

This page discusses Rated's methodology in calculating accrued penalties on validators that failed to perform their duties.

The approach we are taking in calculating penalties at the per index level, and then at the aggregate level thereafter, is a bottom-up, spec-based approach. This means breaking down the penalties into their individual components. based on the attestation duty that a validator fails to fulfil.

According to the pre-Altair spec, these are the following:

Penalty
Description
Value

Incorrect source vote

A source vote that attests to the wrong source slot

base_reward

Incorrect target vote

A target vote that attests to the wrong target slot

base_reward

Incorrect head vote

Attesting to the wrong head of the chain

base_reward

According to the Altair spec, the penalties are:

Penalty
Description
Value

Late source vote

A source vote being included in 6+ slots later than the slot being attested to; f_inclusion_slot - f_slot ≥ 6

14/64 * base_reward

Late target vote

A target vote being included in 32+ slots later than the slot being attested to; f_inclusion_slot - f_slot ≥ 32

26/64 * base_reward

Wrong target vote

A target vote that attests to the wrong target slot

26/64 * base_reward

Missed sync committee signature

A validator missing a sync committee attestation duty

2/64 * active_validators * base_reward / (32*512)

Missed attestation

Completely missing an attestation. This means getting a source vote penalty and a target vote penalty

(14/64 + 26/64) * base_reward

These penalties are them summed together to get the full penalties received by the validator index.

The main advantages of this approach are two-fold. First is that it removes the variability of uptime since the penalties calculation do not rely on the participation rate of the network. Second is that one can attribute the exact source of the penalties.

Please note that in the RatedDB, have effected the above methodology only for the post-Altair part of the sample (Day 330; Oct 27, 2021 and onwards). Thus when using the RatedAPI and looking for penalties in the "All-time" frame, you will get a discrepancy in reconciling rewards with the sum of their parts, as the methodology described on this page gets mixed with the Pre-Altair penalties computation.

The RatedAPI reflects this methodology from Day 653 onwards. We are planning a DB migration as part of the APIv1 release, as we want to ensure that there is no interruption of service for APIbeta integrators.

PreviousPenalties and Missed Rewards methodologiesNextPre-Altair penalties computation

Last updated 2 years ago

Was this helpful?