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:

PenaltyDescriptionValue

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:

PenaltyDescriptionValue

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.

Last updated