pub fn is_stake_eligible(stake: &StakeAccount, epoch_timestamp: u64) -> boolExpand 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:
-
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 anactivation_requestedtimestamp appears in an epoch’s set, that timestamp must have been set before the epoch began, i.e. beforeepoch_timestamp, meaning activation was already effective throughout that epoch. The stored timestamp itself therefore need not be checked for eligibility. -
deactivation_requestedisNoneor>= 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’slockup_end, as if the deactivation were actually requested only at that point. So if a stake with adeactivation_requestedtimestamp appears in an epoch’s set, that timestamp may be after that epoch’s start, i.e. afterepoch_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 iffdeactivation_requested >= epoch_timestamp(boundary inclusive — a stake whosedeactivation_requested == epoch_timestampis still eligible). -
validator.is_some()— the stake is delegated to a validator.