Skip to main content

is_stake_eligible

Function is_stake_eligible 

Source
pub fn is_stake_eligible(stake: &StakeAccount, epoch_timestamp: u64) -> bool
Expand description

Eligibility predicate for a stake at a given epoch start timestamp.

Given a stake account and epoch_timestamp (the freeze timestamp marking the start of some epoch), returns true iff the stake is effectively active at that boundary and delegated to a validator. The stake itself need not live in that epoch’s delta — it can have been resolved from any predecessor frozen snapshot (or baseline) via the layered stake-cache lookup; only the boundary marked by epoch_timestamp matters.

The three clauses encode different invariants:

  1. activation_requested.is_some() — activation has taken effect. activation_requested, when set, is always written with the current timestamp at the moment the activation request is processed. So if a stake with an activation_requested timestamp appears in an epoch’s set, that timestamp must have been set before the epoch began, i.e. before epoch_timestamp, meaning activation was already effective throughout that epoch. The stored timestamp itself therefore need not be checked for eligibility.

  2. deactivation_requested is None or >= epoch_timestamp — deactivation has not yet taken effect. deactivation_requested, in contrast, can be written with a future timestamp — specifically, it is set to the stake’s lockup_end, as if the deactivation were actually requested only at that point. So if a stake with a deactivation_requested timestamp appears in an epoch’s set, that timestamp may be after that epoch’s start, i.e. after epoch_timestamp, meaning the deactivation had effectively not even been requested when the epoch started. The stored timestamp must therefore be checked: the stake is still eligible iff deactivation_requested >= epoch_timestamp (boundary inclusive — a stake whose deactivation_requested == epoch_timestamp is still eligible).

  3. validator.is_some() — the stake is delegated to a validator.