For the first time, what happens inside Solana blocks is no longer a mystery. Based on publicly observable data on Solana, IBRL.wtf shines a light on validator block construction, exposing timing patterns and packing strategies, and giving the community unprecedented visibility into block packing behavior that's never been publicly measured before.

Defining optimal IBRL performance

“Increase Bandwidth, Reduce Latency” has become a powerful slogan for Solana, aligning ecosystem participants towards a single goal: making Solana the fastest, highest-throughput execution environment.

We define optimal IBRL behavior from a validator perspective as: build fast, stream continuously, and propagate state early. Therefore, the requirements for an optimal IBRL score are:

• Build on target: build blocks on target times and minimize intra-slot jitter
• Stream execution: distribute transaction processing across the slot instead of end-loading it
• Vote early: process and forward votes early to reduce confirmation latency

The Problem: Block Packing Timing Games

When we started researching validator block construction in September, we expected to find isolated cases of suboptimal packing. What we discovered was that a large portion of Solana validators are concentrating transactions at the end of their slots, a practice we define as "late packing.” We also noticed the same timing games with voting transactions, which delays confirmation times for traders and users on the network.

Solana is built as a streaming system. Validators are expected to pack transactions throughout the slot, broadcasting block data as shreds over Turbine so the network can reconstruct and replay immediately. When packing is end-loaded, that pipeline stops behaving like a stream; even if the slot finishes on time, state updates propagate late.

Why Late Packing is Harmful

• Delays state propagation: The network learns about state changes in a burst at the end rather than continuously, leaving applications and traders working with stale information for most of the slot.
• Increases execution variance: Predictable execution requires predictable block construction. Late packing introduces timing jitter that makes time-sensitive flows like liquidations and auctions less reliable.
• Undermines Turbine: Solana's state propagation protocol is optimized for continuous streaming. Late packing means useful shreds arrive in a concentrated burst, degrading core network efficiency.

Until now, this behavior has been unseen. While the data exists in Geyser, no public tool has made it measurable or actionable. IBRL.wtf exposes these patterns with tick-by-tick visibility into transaction packing, making validator block construction behavior transparent for the first time.

Slot Timing Games

While late packing has operated largely unnoticed, slot timing issues are more well-known in the validator community. The default slot time on Solana is 360ms, and some validators have modified their Proof of History parameters to extend their slot times beyond the default, giving themselves more time to collect and pack transactions.

Slot lagging is harmful because it:

• Slows state transitions: Blocks land later, so the network updates state later. This adds latency for everyone downstream.
• Increases end-to-end latency: Pushing past the target slot time compounds delays across the network, affecting subsequent validators and user experience.
• Decreases determinism: Consistent slot-time deviation increases jitter and variance, making execution less predictable for applications that depend on timing.
• Reduces application reliability: Timing-sensitive flows like quotes, trades, liquidations, and auctions become less predictable when slot times are inconsistent.

The IBRL explorer

The first version of the IBRL explorer focuses on showing in depth block packing metrics, measuring IBRL-optimal behavior and providing objective scoring criteria based on an internal methodology. The current IBRL composite score is based around two key metrics:

1. Slot Time: How long a validator takes to produce a block
2. Transaction Packing: How a validator packs transactions across the block

For a deep dive into the methodology, please consult the Appendix in this post.

Future iterations of the IBRL explorer will contain additional information and take other metrics into account for generating the IBRL score.

Real-World Impact and Emerging Patterns

Since launching IBRL.wtf internally, the tool has proven invaluable for tuning and discovering performance bottlenecks in the Solana network. Through continuous monitoring, we've identified several interesting behaviors and continue to expand the data we collect and analyze.

While some validators intentionally late pack votes, we've observed unexpected patterns that reveal broader network issues. Within the last month, a new trend has emerged across multiple data centers in Tokyo, Singapore, and other Asia regions: unintentional late packing of votes. While we haven't identified the root cause yet, we believe it's related to submarine cable system failures affecting regional connectivity. This trend shows up in affected validators' vote packing scores, and unfortunately, it's completely outside of their control. We're highlighting this to acknowledge that not all low scores indicate intentional behavior, some reflect infrastructure challenges that individual validators cannot remedy.

We've also discovered a cascading effect from late packing non-votes: validators that late pack transactions consistently increase the vote latency of the cluster compared to those that pack throughout the slot. When a validator late packs transactions, they send shreds (the fragments of block data) in a concentrated burst at the end of their slot. Other validators receive these shreds late and must replay all the transactions before they can vote on the block. Because replay happens late, it often spills over into the next slot's time window. This means validators end up voting later than they should, not because of their own processing delays, but because they're waiting on late-arriving data from the block producer.

Final Thoughts

IBRL.wtf exists to make validator behavior measurable, transparent, and auditable. It aims to give validators, stakers, and applications a shared source of truth for what actually happens at the block production layer at a level of detail never seen before.

The current IBRL score is v1. We’re actively iterating on the methodology and the data we incorporate, and no single score should be treated as a definitive judgment of validator intent or quality. Some scores may reflect infrastructure constraints or network conditions outside a validator’s control. Expect continued improvements as we incorporate more data and refine the scoring model based on real-world observations and community feedback.

If you’re a validator, app developer, or Solana community member and have feedback (or data you’d like to see reflected on the site), please reach out through the Jito Developers Discord or via email to ibrl@jito.wtf.

Appendix: IBRL Scoring Methodology

The IBRL Score is composed of three independent components that measure different aspects of block production behavior. 

• Slot Time Score
• Vote Packing Score
• Non-Vote Packing Score

Each component is weighted to reflect its relative impact on overall IBRL performance, while keeping contributions reasonably balanced.

The formula for IBRL score is the following:

IBRL SCORE =(0.40 *Non-Vote Packing Score) + (0.35 * Slot Time Score) + (0.25 * Vote Packing Score)

Slot Time Score

This score measures fast block production times. A threshold is set depending on if the slot is a handoff slot from another validator, or if the slot is any of the remaining slots in a leader's rotation.

• Handoff slots: A build time of 550ms or less results in a perfect score
• Continuation slots: The validator has 380ms allowance for a perfect score

If the threshold is not met, the score exponentially decays to 0 as the block build time inflates.

Vote Packing Score

This score measures timely processing of vote transactions.

• A block achieves a perfect score when at least 90% of vote transactions are processed within the first 32 proof-of-history ticks
• If this threshold is not met, the score decays as vote processing is pushed later in the block

Non-Vote Packing Score

This score measures equal transaction processing throughout the block, rather than late packing or burst transaction processing. 

This score is made up of 2 sub-factors which contribute equally:

1. Early-compute threshold: We expect at least 50% of the block's total compute units to have been used in the first 32 proof-of-history ticks. As this percentage drops, the factor drops exponentially.
2. Gini coefficient of compute distribution: Measures distribution of compute across the slot’s 64 Proof of History ticks. A perfect gini coefficient of 0 would be achieved if each tick consumed the same amount of compute. As compute clusters and localizes, the gini coefficient goes up and the factor goes down; resulting in a worse non-vote packing score.