Solana validators' "slow motion": Could block delays become a new revenue strategy?
TechFlow Selected TechFlow Selected
Solana validators' "slow motion": Could block delays become a new revenue strategy?
Network speeds slowed down in June, but not due to technical reasons.
Navigating Web3 tides with focused insightsAuthor: Jack Kubinec
Translation: TechFlow
As Solana's code issues have been gradually resolved over the past few years, block times—the time it takes for the network to generate a new transaction block—have significantly decreased, even falling below its nominal 400 milliseconds.
However, over the past month, an interesting trend has emerged: median block times—a key performance metric reflecting how quickly a blockchain network processes transactions and generates blocks—have surged, slowing down Solana’s rate of adding new transactions to the blockchain. The reason lies in a new validator strategy, suggesting that slower block production may be more profitable. According to Blockworks, Anza, Jito, and Marinade are considering addressing this issue.
Each Solana block has one validator acting as the leader—responsible for collecting transactions, creating the block, and broadcasting it to the network. Leaders earn transaction fees by creating blocks. More order flow means more fee opportunities, so validators might choose to process transactions over 500 milliseconds instead of 300 to increase revenue.
At a fundamental level, some Solana validators appear to be waiting as long as possible to pack more transactions into a block, thereby maximizing profits. This behavior leads to longer cycle durations on Solana.
For a network striving to be as fast as Nasdaq, this is clearly not ideal. Additionally, fewer cycles mean reduced compounding opportunities for staking rewards, a point raised by Max Kaplan, CTO at Sol Strategies.
Solana provides a mechanism called "grace ticks," which allows leaders a grace period to successfully submit their blocks. This mechanism aims to prevent remote validators from being unfairly penalized but also opens the door for validators to intentionally delay block submissions.
Moreover, Solana’s alternative client Frankendancer recently released a revenue-maximizing scheduler.
According to Kaplan, validators running this client appear to be packaging blocks slightly slower than normal. However, Kaplan added that compared to more severe delayers, Frankendancer’s delays are negligible, and he doesn’t consider it a “bad” thing. Furthermore, block delays are not a new concept on proof-of-stake blockchains. However, Firedancer’s upgrade could make this strategy more visible on Solana. Jump has not commented yet.
Interestingly, Firedancer software engineer Michael McGee described this phenomenon on this week’s Lightspeed podcast. He mentioned: “One thing we’re seeing among current validators is… [validators] tend to create more profitable blocks by delaying transaction execution.”
Victor Pham, analyst at Blockworks Research, noted that Solana validators who more noticeably delay blocks typically run modified versions of the Agave-Jito client.
For example, during cycle 802 in mid-June, Galaxy and Kiln both had median block times exceeding 570 milliseconds. According to Solana Compass data, some unlabeled validators also operated slowly, while Temporal’s validators had a median block time of 475 milliseconds.
Kiln co-founder Ernest Oppetit acknowledged that its validator—the sixth-largest staking validator on the Solana network—had delayed block slots for a period but said it has since stopped this practice.
“At Kiln, we pride ourselves on offering the highest staking APY in the market without sacrificing security. We continuously conduct R&D on different parts of our tech stack, including timing strategies, and maintain ongoing discussions with clients, client teams, and the foundation. Currently, we follow the spec and no longer delay blocks, though many other validators still do. We believe the incentive misalignment—where faster block production results in lower rewards—must eventually be addressed at the protocol level,” Oppetit said.
When asked about his validator’s apparent participation in the slow-block trend, Temporal engineering director Ben Coverston said: “I can say we’re not the reason people are aware of this phenomenon.”
A spokesperson for Galaxy stated: “As a service provider, we support validator configurations that prioritize maximizing customer staking rewards. On Solana, this might mean proposing slightly slower blocks to ensure higher reward capture. Galaxy has also responded to community feedback and adjusted block times within acceptable ranges.”
However, the broader Solana validator community generally agrees that slowing down the network is inappropriate, and slow validators are currently facing strong public backlash.
They may soon face more concrete penalties. According to Blockworks, Jito plans to blacklist slow validators from its stake pool, the largest on the Solana network.
Brian Smith, chairman of the Jito Foundation, said the organization is “drafting a governance proposal to empower a committee to remove laggards from the JitoSOL delegation set. This proposal should open for community discussion within days.”
Michael Repetny, co-founder of Marinade, said the liquid staking provider is “considering bringing this issue to a governance proposal to discuss the pros and cons of treating [slow validators] as a hard rule / delegation policy violation.”
Protocol-level solutions are also moving forward. Anza’s GitHub repository shows a new proposal suggesting halving Solana’s grace tick period. Additionally, proposed consensus mechanism reforms on Solana aim to resolve this issue.
“Alpenglow will address this by enabling skip voting,” said Brennan Watt, VP of core engineering at Anza.
Watt revealed on a recent episode of the Lightspeed podcast that Anza aims to launch Alpenglow on mainnet before the Solana Breakpoint conference in December this year.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Blockworks
