Ask or search…
K
Links

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, we have applied 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 APIbetaintegrators.