JIP-23: Crack Down on Lagging Leaders

JIP - Official
1

JIP-23: Crack Down on Lagging Leaders

Abstract

JIP-23 proposes a Jito stake pool intervention that will punish validators who intentionally delay (lag) their blocks to gain an economic advantage. Similar to JIP-22 it will create a standing temporary structure that will operate a mechanism for excluding “lagging leaders” from the Jito stake pool. JIP-23 establishes Jito DAOs position on validator activity that materially reduces network performance and deviates from Solana’s network objectives to improve bandwidth and reduce latency i.e. IBRL.

Motivation

It has recently come to light that some validators are lagging their leader slot intentionally, making out of protocol changes to play ‘timing games’. This includes delaying blocks in their leader slot to create a broader window of opportunity for filtering high value transactions from the network. This activity materially lowers network health and user experience, whilst introducing market inefficiency by slowing finality and increasing price latency.

DAO participants are advised to review the data themselves using this community generated tool by art3mis.cloud

1600×1090 269 KB

Figure 1: A snapshot of avg blocktimes of slowest leaders, reaching nearly 1s latency.

Although not as overtly harmful to users as Malicious MEV, Jito DAO (and wider key Solana stakeholders, See Figure 2) takes the stance that JitoSOL stake should be directed towards validators that improve the Solana network by engaging in positive-sum practice.

1080×190 20 KB

Figure 2: Toly’s suggested action for dealing with the ‘Lagging Leader’ behaviour

Note: A number of forthcoming Solana core changes, including the Alpenglow upgrade will render JIP-23 redundant in the next several months. Consequently, this JIP and its associated structures will retire organically as the network evolves.

There may be Solana core changes to enforce this prior to Alpenglow to make this redundant on an accelerated basis but nothing is expected within the next several months.

Key Terms

  • Lagging Leader: A validator who consistently delays producing blocks in their assigned leader slots beyond expected timing windows.
  • Average Blocktime: The mean time (in milliseconds) between block production and confirmation for a given validator’s leader slots.
  • Cluster Median: The median of average blocktimes computed across all active validators over the same observation window.
  • Threshold Method: The statistical rule used to flag validators (e.g., static cutoff, relative multiple, or percentile-based).
  • Epoch: A standard Solana period (approximately 2–3 days) used as the cadence for monitoring and sanctions.
  • Sanction Period: The duration 25 epochs during which a flagged validator is removed from the JitoSOL stake pool.
  • IBRL Operations Committee (IBRLOC): A five‑member multisig‑driven body elected by tokenholders to execute each epoch’s blacklist update.
  • Multisig Authority: The on‑chain StakeNet permission set that allows IBRLOC to update the blacklist parameter each epoch.

Specification

  • IBRL Operations Committee (IBRLOC): A 5-member IBRL Operations Committee, elected for 12-month terms, will mirror the BOC’s (JIP-22) mechanics running a shared script each epoch, signing off via a multisig, and publishing identical reports without embedding permanent code changes in the StakeNet program.
  • Action Trigger: Average blocktimes and leader slot timestamps are natively recorded on Solana’s ledger so we can reconstruct each validator’s true block latency with millisecond precision and cryptographic integrity.
  • Sanction Duration: Validators flagged under these criteria will be removed from the JitoSOL stake pool for 25 epochs, reflecting the lower severity compared to MEV offenses.
  • No Appeals Process: Given the clarity and objectivity of on-chain latency data, sanctions will be final—ensuring swift enforcement and preserving network performance without lengthy disputes.

Benefits / Risks

Benefits Risks
Swift, Objective Enforcement: Near-real-time sanctions close performance gaps. Operational Complexity: Running scripts, multisig, and reports adds overhead.
Data-Driven & Adaptable: Multiple threshold options accommodate network changes. Threshold Calibration: Poorly chosen thresholds could under- or over-sanction.
Tokenholder Oversight: Committee membership, thresholds, and oracles remain adjustable via JIP. No Appeals: Final sanctions may be contested if corner-case data errors occur.

Outcomes

  • Immediate: IBRLOC is constituted; threshold method selected; first epochal blacklist executed with 25-epoch sanctions.

  • Ongoing: Continuous detection and mechanical enforcement of lagging-leader behavior, with transparent, periodic reporting.

  • Long-Term: A resilient, community-governed mechanism that safeguards network latency and user experience.

Cost Summary

  • No direct treasury expenditure.

  • Administrative effort for script maintenance, data hosting, and report generation, covered under existing Foundation resources.

2 Likes