IBRL Score Methodology
The IBRL Score is composed of three independent components that measure different aspects of block production behavior.
| Component | Weight |
|---|---|
| Slot Time Score | 35% |
| Vote Packing Score | 25% |
| Non-Vote Packing Score | 40% |
Each component is weighted to reflect its relative impact on overall IBRL performance, while keeping contributions reasonably balanced.
Note: In some UI elements, vote and non-vote packing scores are averaged together and displayed as a combined "Packing Score" for simplicity.
The Formula
IBRL Score = (0.40 × Non-Vote Packing) + (0.35 × Slot Time) + (0.25 × Vote Packing)
Slot Time Score (35%)
Slot time score aims to encourage 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 (25%)
Vote packing score aims to encourage 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 (40%)
The Non-vote packing score aims to encourage 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 Utilization
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. Distribution Uniformity (Gini Coefficient)
The gini coefficient of compute distribution across the 64 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.
Methodology and Scoring Notes
The IBRL score is derived from observable leader behavior, but it does not yet incorporate every factor that can influence slot timing and transaction distribution. It should be interpreted as a directional signal about block production and packing patterns, not a definitive assessment of validator intent or overall quality. Results may also be affected by infrastructure, network, and other conditions that are not fully captured in the current methodology.
We'll continue refining the model and expanding the set of signals over time to improve accuracy and reduce noise. 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 Developer Discord or via email to ibrl@jito.wtf.