Overview - Rated

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`

According to the current spec, which is the Dencun 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`
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 API v1 release, as we want to ensure that there is no interruption of service for API beta integrators.