Yakovenko Proposes QoS Filter to Exclude Slot-Delaying Validators From Solana

A Temporal cluster validator with 1.2M SOL staked resumed slot lagging in epoch 1031, on-chain analyst Andrei documented on September 12, after running normal blocks for roughly eleven consecutive epochs. The same identity had been linked to the Temporal operation through a 45.41 SOL transfer made twelve epochs earlier from the validator's own address.

The finding came hours before Solana SOL$99.87-1.8% co-founder Anatoly Yakovenko posted that validators delaying slot production should be filtered out of governance vote counts, and the two threads reached roughly the same audience within the same day.

Temporal Cluster Behavior in Epoch 1031

Andrei built on earlier research from September 3 showing the Temporal operation extended beyond its most visible case. Four additional Temporal-managed validators, holding a combined 3.34M SOL in stake, had been running on the same infrastructure; their identities were drained and rotated less than two weeks before that post. An address connected to the Temporal operation received roughly $3 million from those wallets on August 21.

The Temporal cluster deliberately delays block production during a validator's scheduled leader slot, a practice that extracts MEV value at the expense of users and the broader network. The resumed lagging in epoch 1031 followed a multi-epoch pause in the behavior, suggesting it can be suspended and restarted selectively.

The Temporal cluster's stake was present and voting in Solana SOL$99.87-1.8%'s first binding on-chain governance process, which closed August 28 with SGP-0002 passing at 67.001%, the highest stake participation recorded. Validators that undermine network performance participated in the same process used to decide Solana's inflation schedule.

Yakovenko Proposal: QoS Standard Before the Governance Snapshot

Yakovenko posted on September 12 that slot-delaying validators should be excluded from governance vote counts entirely:

The mechanism he described runs before a vote snapshot is taken, not after. His proposal: set a QoS performance threshold, take the governance snapshot after filtering out validators below it, then count votes using that pre-filtered stake set. "Set a QOS standard, then do the snapshot, and post snapshot remove everyone below the QOS standard when the vote counts," he wrote. "The vote numbers on chain are meaningless, they don't enforce anything anyways."

Yakovenko acknowledged the practical difficulty directly. When asked about automated on-chain detection, he replied: "There is no way to do this without a subjective or gamble oracle." His response to that constraint was to place the judgment off-chain, in the governance administration process rather than in the protocol. Governance legitimacy is already a subjective determination: a minority can defect from any outcome without a vote at all, so applying a performance standard to set quorum introduces no new trust assumption. The supermajority would vote on which QoS criteria to adopt, then that standard would define whose stake weight counts in future votes.

Per-region allowances are possible under the model. Yakovenko noted that validators in regions with higher network latency could receive adjusted thresholds if the network judges that appropriate.

Yellowstone Shield: A Transaction-Layer Response Available Now

Triton One co-founder Brian Long pointed to a different approach that does not require any governance rule change. Yellowstone Shield is an open-source Solana program developed by Triton One that lets transaction senders maintain on-chain blocklists of validator identities.

"You can also NOT send transactions to those leaders using Yellowstone Shield blocklists. It's permissionless, open-source, and free," Long wrote.

The tool manages allowlists and blocklists through Program Derived Addresses, with updates propagated via websocket or gRPC. Senders pass a forwardingPolicies parameter in sendTransaction to route traffic away from identified leaders. Published under an AGPL-3.0 license, the program is deployed on both mainnet and devnet.

Yellowstone Shield operates at the transaction-routing layer. It does not touch governance vote weights. It lets RPCs and transaction senders refuse to forward to a slot-lagging leader during that leader's scheduled window, cutting into the fee revenue those leaders would otherwise capture. Yakovenko's proposal targets a separate layer: which validators governance treats as part of the legitimate quorum at all.

The two responses address different failure modes. Yellowstone Shield is a market-coordination tool available today. A governance snapshot filter would require the Solana governance process to define and adopt a QoS standard, a process that itself depends on the same governance system the Temporal cluster has been participating in.