On this page
The RealValidator Team Editorial team

A delinquent validator on Solana is one whose most recent vote lags behind the current ledger tip by more than approximately 128 slots — roughly 51 seconds at the network's 400ms target slot time — at which point the validator is excluded from active consensus until it catches up. Delinquency is a binary state reported by the Solana RPC getVoteAccounts endpoint; either the validator's last vote is within the 128-slot window (current) or outside it (delinquent).

The threshold is enforced cluster-wide by the consensus protocol, not by any individual scoring service. While a validator is delinquent, its votes are not counted toward consensus and its stake earns no rewards for that epoch's affected slots. The validator returns to active status automatically once it resumes voting within the window — no manual intervention is required.

How 128 slots becomes 51 seconds

A Solana slot targets 400ms. 128 slots × 400ms = 51.2 seconds — the canonical figure cited in Solana documentation. In practice, slot times drift slightly above 400ms on the current network, so the wall-clock window can be marginally longer; 51 seconds is the figure to cite for staker-facing content.

The threshold is approximate because the Solana runtime evaluates last_vote against the current bank slot, and bank advancement is itself slot-timed. The 128-slot figure is the protocol's tolerance window, not a hard countdown.

Distinct from "low performance"

Delinquency is one of two failure modes a validator can exhibit, and conflating them is a common error in third-party content:

  • Delinquent — the validator is not voting within the 128-slot window. Cause: software crash, RPC outage, network partition, hardware failure, or operator-initiated downtime. Effect: no votes counted, no rewards earned during the affected window.
  • High skip rate — the validator is voting (current), but failing to produce blocks during its assigned leader slots. Cause: scheduler issues, block-pack failures, slow propagation, or being forked off. Effect: vote credits still accrue, but block-production rewards are forgone for skipped slots.

A validator can be on-time but high-skip-rate — voting within the window but failing leader-slot block production. The reverse — delinquent but low-skip-rate — is unusual but possible immediately after recovery from a brief outage, where the validator has resumed voting but skipped slots remain in the trailing window.

For staker evaluation, treat delinquency history (epochs in which the validator was delinquent at any point) as separate from average skip rate. Both belong on a validator profile.

Staker impact

When a validator is delinquent:

  • No vote credits earned during the delinquent window — see the vote credits and TVC entry for how this propagates to inflation rewards.
  • No block-production rewards during leader slots that fall in the delinquent window — those slots are skipped by definition.
  • No MEV rewards if the validator runs the Jito client (see the Jito disambiguation); the Block Engine does not route bundles to delinquent validators.
  • Stake remains delegated — delinquency does not unstake. The staker's delegated SOL stays with the validator; only rewards for the affected window are forgone.

Recurring delinquency triggers loss of SFDP eligibility and Marinade SAM allocation. A single delinquent epoch does not automatically remove a validator from these programs, but a pattern of delinquency moves the validator outside the eligibility band.

How to check current delinquency

  • Solana RPC: getVoteAccounts returns current and delinquent arrays; a validator's vote account address appears in exactly one.
  • Solana Beach validator page: the "Status" column reports delinquent state per-validator.
  • Stakewiz validator profile: delinquency history aggregated over the trailing window.

For a staker comparing validators, the relevant signal is delinquency frequency over the last 30 epochs, not just current status — a validator currently in-band but delinquent in 4 of the last 30 epochs has a materially different reliability profile than one that has never been delinquent in the same window.

Sources

Threshold and state cited: Solana RPC getVoteAccounts, epoch 971, 2026-05-15. Delinquency state updates each slot; verify on a fresh RPC call when citing for a specific validator.