What are inclusion delays?

The inclusion delay is the time between the moment a transaction is received by the validator TPU and the moment it is sent in a shred as part of the block being built. This delay consists of the time needed to verify the transaction, its signature, to execute the transaction, and to update the accounts accordingly. But it also includes any time during which the validator intentionally holds the transaction in a buffer and does nothing.

What is ordering?

Users might expect that if a transaction is sent after another transaction, it is included in a block after. In practice, validators can reorder transactions. The ordering column in the dashboard shows a score that is higher if the relative position of transactions in a block is well correlated with the time it is received by the leader.

How is this data collected?

We use a setup consisting of multiple transaction senders in different regions and a receiver monitoring emitted shreds. When we detect one of our transactions in a received shred, we measure the elapsed time since the transaction was sent. We then subtract an estimate of the time it took for our transaction to reach the leader, and an estimate of the time it took for the leader’s shreds to reach our receiver.

The resulting inclusion delays are approximate, especially for validators with low stake or those migrating between servers. However, the overall trends remain informative.

What is the meaning of the Client column?

The client column indicates the validator's client software and, in the case of the Frankendancer/Firedancer, the packing strategy

PRF: Performance strategy

BAL: Balanced strategy

BUN: Bundle/Revenue strategy

var.: multiple strategies during data collection period

What is the meaning of the TPU column?

This column shows the icon when he validator uses a non-default TPU for QUIC transactions, suggesting the presence of a relayer, or some kind of mempool.

Why do validators introduce delays?

Validators introduce delays to increase their rewards, for themselves and/or their stakers.

Why does delaying transactions increase rewards?

There are two main reasons:

1. Bundles received from Jito Block Engine include a tip paid to the validator or to its stakers (after Jito's commission). The tip is only collected if the bundle succeeds. In contrast, native transactions contain a priority fee that the validator collects even if the transaction fails. Therefore the validator prioritizes bundles and ensures no native transaction can conflict and make them fail. The validator doesn't care if native transactions fail.

2. During periods of high market activity, when there are not enough compute units (CU) in blocks to include all received transactions, the validator wants to include the transactions paying the highest priority fees. So it waits the longest time possible to have a largest choice when it comes to select the best transactions.

Reason 2 will become less prominent when the size of blocks increases towards 100 millions of CU.

How do validators delay transactions?

The common way when using an Agave client is to use a Jito relayer. By default, relayers used to introduce a delay of 200 ms before forwarding transactions to the validator. The default is now 50 ms, though it can be adjusted. Before Jito public relayers were shut down on August 28, 2025, they still use 200 ms delays.

The Firedancer client can be configured to use one of 3 packing strategies. Most operators use the Revenue (aka Bundle) strategy, which only processes native transactions during the final 50 ms of each 400ms slot.

Should we care?

One could argue than reordering transactions within its block is a validator's prerogative, that the slot is the atomic unit of time for transaction finalization and that sub-slot delays are irrelevant.

However we believe it's an issue that should be addressed. Jito relayers current behavior clearly deviates from the protocol, by not only introducing intra-slot delays, but also by frequently causing native transactions to be delayed until next slot.

Moreover, AlpenGlow will enable fast finalization and shreds dissemination, far below the duration of a slot. Keeping artificial inclusion delays seems orthogonal to this evolution.

High frequency trading, oracles, liquidations, and fast transaction optimistic confirmations are all examples of use cases where sub-slot transaction inclusion is critical.

Today there is no incentive for validators to avoid introducing these delays. PUFFIN, like many other validators, currently uses a delaying Firedancer packing strategy. But we would be more than happy to switch to an alternative if the community decides to address this issue.

Why are some validators not listed?

Some low-stake validators are not listed because we couldn't gather enough transaction data to estimate their inclusion delays accurately. PUFFIN validator is not included either because measures concerning its operations would be technically biased.