Solana employs a Proof-of-Stake (PoS) consensus algorithm where a designated leader, chosen for each slot, produces a new block. The leader schedule is randomly determined before the start of each epoch, a fixed period comprising multiple slots. Leaders generate a Proof-of-History (PoH) sequence (a series of cryptographic hashes where each hash is computed from the previous hash and a counter) to order transactions and prove the passage of time. Transactions are bundled into entries within a block, timestamped by the PoH sequence, and the block is finalized when the leader completes its slot, allowing the next leader to build upon it. A slot is optimistically confirmed when validators representing two-thirds of the total stake vote on it or its descendants, signaling broad network agreement.
When forks arise (situations where multiple conflicting chains exist), validators must decide which fork to support through their votes. Each vote commits a validator to a fork, and lockout rules restrict them from voting on conflicting forks for a duration. Solana’s fork choice rule governs when a validator can switch to another fork, ensuring the network converges on a single, canonical chain.
In the Agave client, the Tower struct, defined within the core/src/consensus.rs file, serves as the central data structure for managing a validator’s voting state. It plays a pivotal role in tracking the validator’s voting history, enforcing lockout rules to prevent conflicting votes, and facilitating decisions about which fork to follow in the presence of chain splits. Within the Tower, a vote_state field (implemented as a VoteState object from the solana-vote-program crate) maintains a detailed record of all votes cast by the validator along with their associated lockout periods, ensuring adherence to consensus rules. The struct also keeps track of the most recent vote through its last_vote field, capturing the latest transaction submitted by the validator. Additionally, the Tower includes threshold_depth and threshold_size parameters, which define the criteria for confirming slots; by default, these are set to a depth of 8 slots and a stake threshold of two-thirds, respectively, determining the level of agreement required from the network.
When a validator needs to vote on a slot, it relies on the Tower’s record_bank_vote method to execute the process seamlessly. This method begins by extracting the slot number and its corresponding hash from a Bank object, which represents a snapshot of the ledger at that specific slot. It then constructs a Vote object encapsulating the slot and hash, formalizing the validator’s intent. Finally, it invokes record_bank_vote_and_update_lockouts, which in turn delegates to process_next_vote_slot to update the vote_state, ensuring that the new vote is recorded and lockout rules are applied accordingly.
Once a validator casts a vote on a slot in Solana, it becomes temporarily barred from voting on conflicting slots, a restriction governed by the 2^N lockout rule, which imposes an exponentially increasing duration with each subsequent vote. Initially, after a validator’s first vote ($N=1$), the lockout period spans $2^1 = 2$ slots, but with a second vote ($N=2$), the lockout for the first vote extends to $2^2 = 4$ slots, while the second vote introduces a new lockout of $2^1 = 2$ slots. More generally, after $N$ votes, the earliest vote in the sequence is locked out for $2^N$ slots, ensuring the validator remains committed to its chosen fork.
This mechanism is implemented within the process_next_vote_slot function, which is invoked by record_bank_vote to update the validator’s voting state. At the heart of this exponential lockout is the confirmation_count field, where each new vote increments the confirmation_count of prior votes. The confirmation_count is part of the Lockout struct, and it is used to determine the number of slot for which a vote is locked out as $2^\text{confirmation\_count}$.
To illustrate, consider a validator voting on slots 2 and 3 of a fork. With its first vote on slot 2, the confirmation_count is set to 1, resulting in a lockout of $2^1 = 2$ slots, meaning the validator is barred from voting on a conflicting fork until after slot 4. When it votes on slot 3, the confirmation_count for slot 2 increases to 2, extending its lockout to $2^2 = 4$ slots, or until slot 6, while slot 3 starts with a confirmation_count of 1, locking out until slot 5. Consequently, the validator cannot vote on a conflicting fork, such as slot 4 on a different chain, until after slot 6.
Fig. 1: Graphical representation of a validator V switching fork, with relative $2^N$ rule for lockouts.
Through this mechanism, Solana ensures that validators remain committed to their chosen fork for the duration of the lockout period, preventing double-voting or equivocation that could destabilize the network.
Validators in Solana’s consensus process sometimes miss voting on slots due to network delays or operational issues. As noted in SIMD-0033 (Timely Vote Credits), missing votes or submitting them late reduce rewards, prompting some validators to engage in backfilling, which is the retroactive voting on missed slots in a later transaction. For instance, a validator skipping slots 4 to 6 might vote on it at slot 7, claiming credits to maintain staking rewards and network contribution. However, Solana enforces strict ordering: the check_and_filter_proposed_vote_state function ensures slots in a vote transaction exceed the last voted slot in the VoteState, rejecting earlier slots with a VoteError::SlotsNotOrdered. This consensus-level check, executed on-chain, means that backfilling must advance the voting sequence, such as including slots 4 to 6 at slot 7, only if the last voted slot was 1 or earlier (see Fig. 1).
It is worth mentioning that, despite this practice appears healthy, improper backfilling can disrupt the network. When a validator backfills by voting on missed slots, each new vote extends the lockout period of earlier votes through Solana’s $2^N$ rule, deepening its commitment to the chosen fork. If these slots belong to a stale fork, the prolonged lockouts may prevent the validator from switching to the main chain, potentially delaying consensus if many validators are similarly affected, thus hindering the network’s ability to confirm new blocks.
To address this, Ashwin Sekar from Anza proposed SIMD-0218: Intermediate Vote Credits (IVC), which integrates backfilling into the protocol by crediting intermediate slots at the landing slot’s time. This controlled approach is meant to eliminate risky backfilling mods, ensuring liveness and fairness while allowing credit recovery.
Detecting backfilling in Solana poses a challenge because, as previously discussed, voting on past slots is not prohibited and can occur under normal circumstances, such as network delays or validator restarts. However, fluctuations in network-wide TVC effectiveness offer a lens to identify potential backfilling. A query obtained using Flipside reveals that TVC Effectiveness fluctuates over time, with a notable network-wide dip during epoch 786.
While a more significant dip occurred between Epochs 760 and 770, we focused on the more recent period due to the availability of granular internal TVC data, acknowledging that further investigation into historical valleys is warranted to fully understand network voting dynamics.
For this analysis, we focused on the date range between 2025-05-11 and 2025-05-15.
Fig. 2: Network TVC Effectiveness obtained using Flispide, cfr.here
Since Dune is the only data provider granting easy access to on-chain voting data, we developed a dashboard with the goal of detecting potential instances of the backfilling practice. Precisely, we developed two methods; however, both remain probabilistic, as backfilling cannot be definitively confirmed without direct access to the validator's intent.
The first method, dubbed the "Simple Mod", examines voting behaviour focusing on the relationship between the number of vote transactions signed by a validator in a single slot and the slot distance between the landing slot of those transactions and the slot of the recent block hash they reference. For example, if a validator submits 10 vote transactions in slot 110 with a recent block hash from slot 108, the distance is only 2 slots, significantly less than the number of transactions. This pattern suggests backfilling because the validator is likely catching up on missed slots in a burst: the short distance indicates the transactions were created in quick succession at slot 108, possibly to retroactively vote on slots 99 to 108, a common backfilling strategy to claim credits for earlier missed votes in a single submission, rather than voting incrementally as the chain progresses.
Fig. 3: N° of possible backfill detected using the “Simple Mod” model, cfr.here
Figure 3 shows the hourly aggregation of possible backfill detections using the “Simple Mod” method. We mainly have two peaks in the data: the first occurs at 00:00 on May 11, 2025, likely triggered by a widespread network issue or a collective validator restart, as the validators identified during this spike do not reappear in subsequent instances, suggesting a one-off event rather than sustained backfilling. The second peak, around 11:00 AM on May 13, captures a more persistent trend, involving the most frequently detected accounts across the dataset. By examining the frequency of these detections, we identified three validators consistently engaging in potential backfilling, indicating an active practice of retroactively voting on missed slots to maximize credits, alongside one validator exhibiting milder behavior, with fewer instances that suggest a less aggressive approach to catching up on voting gaps.
The second method, dubbed the "Elaborate Mod", takes a broader perspective, analyzing voting patterns to identify validators that consistently submit an unusually high number of vote transactions in single slots across multiple instances. We aggregated vote transactions hourly, flagging validators that submit more than 4 distinct vote transactions in a slot. We chose this threshold because, while a leader might include multiple vote transactions from a validator due to network latency or validator restarts, exceeding 4 votes in a single slot is unlikely under normal conditions where validators typically vote once per slot to advance the chain. We further refined the detection by requiring this behaviour to occur in over 10 distinct hourly intervals, reflecting that such frequent high-volume voting is less likely to stem from typical network operations. This pattern could indicate backfilling because validators engaging in this practice often batch votes for multiple missed slots into a single slot’s transactions, aiming to retroactively fill voting gaps.
Fig. 4: N° of possible backfill detected using the “Elaborate Mod” model, cfr.here
Figure 4 presents the hourly aggregation of possible backfill detections using the "Elaborate Mod" method, revealing a distinct pattern that complements the Simple Mod analysis. Unlike the dual peaks observed previously, this method identifies a single prominent peak around 11:00 AM on May 13, 2025, which aligns precisely with the second peak detected by the “Simple Mod”. The absence of the earlier peak from May 11 at 00:00 underscores the Elaborate Mod’s design, which reduces sensitivity to false positives caused by transient events, such as validator restarts or network-wide issues, focusing instead on sustained high-volume voting patterns indicative of deliberate backfilling. Notably, the Elaborate Mod detects a larger cohort of 120 validators engaging in potential backfilling, reflecting its broader scope in capturing consistent voting anomalies over time. Among these, the most prominent backfiller mirrors the primary validator identified by the “Simple Mod”.
Fig. 5: Vote credits earned out of the theoretical maximum, higher is better. Better vote effectiveness translates directly to higher APY for delegators. To make very subtle differences between validators more pronounced, we show the effectiveness over a 24h time window. This means that short events such as 5 minutes of downtime, can show up as a 24-hour long dip. Note the log scale!
Having identified potential backfillers, we now turn to assessing whether this practice might destabilize Solana’s consensus mechanism. As previously noted, improper backfilling can extend the lockout periods of stake committed to a stale fork, potentially slowing consensus by delaying validators’ ability to switch to the main chain. Figure 5 leverages internal data to provide a granular view of TVC effectiveness, tracking the performance of various validators. The purple validator, flagged as a backfiller by the “Elaborate Mod”, consistently outperforms others in TVC effectiveness under normal conditions, likely due to its aggressive credit recovery through backfilling. However, during vote-related disruptions (such as those coinciding with the May 13 peak) its effectiveness drops more sharply than that of vanilla validators, suggesting prolonged adherence to a wrong fork. This heightened sensitivity indicates that backfilling, while beneficial for credit accumulation, may amplify the risk of consensus delays if many validators on a stale fork face extended lockouts, raising questions about the broader safety of Solana’s consensus mechanism despite the validator’s overall performance advantage.
In this analysis, we focused on modifying the consensus to backfill missed vote opportunities. Improper backfilling can exacerbate vote lagging, strain network resources, and extend lockouts on stale forks, potentially delaying consensus.
We developed two methods to potentially detect validators involved in this practice, the “Simple Mod” and “Elaborate Mod”. Our data analysis from May 11 to May 15, 2025, highlighted periods of potential backfilling. The Simple Mod identified bursts of vote transactions exceeding the slot distance to their recent block hash. At the same time, the Elaborate Mod flagged validators consistently submitting high vote counts across multiple instances, detecting 120 validators with one primary backfiller overlapping between methods. Analysis of TVC effectiveness showed that while backfillers often outperform in credits, they face sharper drops during vote-related disruptions. This suggests prolonged adherence to wrong forks that could hinder consensus if widespread. The introduction of SIMD-0218 (Intermediate Vote Credits) offers a promising solution by formalizing backfilling within the protocol, mitigating risks like vote lagging while ensuring fair credit recovery. Nonetheless, the interplay between backfilling and consensus stability raises ongoing questions about Solana’s long-term resilience, warranting further investigation into network-wide voting patterns and their impact on liveness and fairness.
