At USENIX Security on Aug. 12, researchers presented a Solana Proof-of-History clock attack they had disclosed privately to Solana developers in December 2025. Anza’s 50,000 SOL Alpenglow competition closed seven days later, and its rules appear to place the attack outside the scope.
The paper describes a protocol-valid way for a scheduled leader to stretch its effective block window and suppress honest leaders’ proposals in a fork-assisted version. The path relies on Proof-of-History and TowerBFT, the machinery Alpenglow is intended to replace but had not yet displaced on mainnet in Agave 4.2.
The finding creates both a contest-scope story and a transition-risk question.
The competition rules excluded behavior reachable only when Alpenglow was inactive. Public design documents indicate that the paper’s exact legacy path should become unreachable after activation, but Anza and the Solana Foundation have not published a paper-specific adjudication or implementation analysis.
How a leader can stretch Solana’s clock
Proof-of-History (PoH) uses a sequential hash chain to give Solana a logical clock. Validators continue advancing their local view of that clock when a scheduled leader does not immediately publish a block.
The researchers say a malicious scheduled leader can withhold a protocol-valid block while honest validators move ahead, then release the block anchored to an earlier point in logical time. If validators adopt that branch, they align their PoH state to the block’s earlier point. The researchers call the reset “re-anchoring.”
Time Inflation (TI) repeats that maneuver to give the attacker more physical time to choose transactions while logical time advances more slowly, and Fork-Assisted Time Inflation (FTI) combines the reset with TowerBFT fork choice.
Under the modeled conditions, the attacker’s branch can orphan an honest leader’s block, and Solana’s one-block-per-slot rule prevents that leader from simply producing another block for the same slot.
The threat model gives the adversary less than 33% of stake and no control over the network scheduler. It assumes a known, stake-weighted leader schedule, partial synchrony, and delivery of an honest block to honest validators within one nominal slot after the network stabilizes.
For an attacker controlling ℓ consecutive four-slot leader rounds, the experiments use a conservative, stake-agnostic maximum delay of 4ℓ + 1 slot units. One round maps to a five-slot-unit delay parameter.
The paper says more stake could widen a risk-free release window, but does not present that experimental setting as a universal mainnet result.
The researchers implemented TI and FTI on a local Solana testnet and used simulations for full-epoch attacker configurations. They did not identify a specific affected Agave release, so the paper does not establish that every current client version is exposed in the same way.
What public data shows
The researchers also studied public mainnet data and selected two validators that repeatedly sat in the tail of the timestamp-interval distribution. Those validators paired longer intervals with higher transaction inclusion and low skip rates.
The pattern is consistent with TI’s incentive channel because a longer physical window creates more opportunities to select fee-bearing transactions.
The paper says hardware differences, local batching or other configuration choices, network conditions, and operational disruptions could create similar timing patterns. It also found no significantly elevated downstream skip rate and said the observed pattern was inconsistent with attribution to FTI.
The research establishes a protocol-valid fairness and latency issue through controlled tests and suggestive measurements. It stops short of showing a live exploit, theft, demonstrated mainnet manipulation, or a consensus-safety break.
Why the Solana Alpenglow contest probably excluded it
Alpenglow competition submissions closed Aug. 19 at 16:00 UTC. The rules covered the Alpenglow feature-active consensus surface, integration code whose behavior changed because Alpenglow was active, and the TowerBFT-to-Alpenglow migration path.
Behavior reachable only when Alpenglow was inactive belonged to the TowerBFT domain and was outside the competition. Previously public issues were also ineligible.
| Question | Legacy PoH and TowerBFT path | Alpenglow path |
|---|---|---|
| Core consensus | PoH-derived logical time with TowerBFT voting and fork choice | Votor voting, block production, and finality with local timeouts |
| Paper’s mechanism | Uses PoH re-anchoring and legacy fork-choice behavior | Designed to make that exact path unreachable, without a public paper-specific adjudication |
| Competition treatment | Excluded when reachable only with Alpenglow inactive | Feature-active behavior and migration code were in scope |
| Mainnet transition | Relevant while legacy consensus remains active | Code was present in Agave 4.2 but not activated on mainnet |
The competition covered faults caused by Alpenglow or its migration, and the paper targets the legacy time and fork-choice model Alpenglow is meant to replace.
What Alpenglow changes
Anza’s Alpenglow overview says the upgrade replaces TowerBFT and PoH as core consensus components with Votor. The official SIMD-0326 proposal describes local timeouts that perform a timing role without synchronized time and calls the change backward-incompatible.
Those designs remove the PoH re-anchoring and TowerBFT fork-choice prerequisites TI and FTI use. The public record lacks an Anza or Solana Foundation analysis mapping each attack step onto shipping Alpenglow code or ruling out an analogous issue in migration logic.
According to the researchers, the Solana development team responded within one day of the December 2025 disclosure. The paper says the team considered the behavior known internally, expected a future protocol upgrade such as Alpenglow to address it, monitored for it, and regarded the most severe scenarios as unlikely under current conditions.
The authors also said they had not fully deployed mitigation by publication.
A Solana Foundation overview of Agave 4.2 said the client included Alpenglow code for community test clusters but did not activate the new consensus on mainnet, with activation expected in Agave 4.3.
The paper’s legacy PoH attack appears to have fallen outside the 50,000 SOL contest, and Alpenglow is designed to remove its exact prerequisites. Until activation and a public implementation-level response, the transition remains the unresolved part of the story.
