Solana contest excluded disclosed PoH clock attack

A Proof-of-History clock attack disclosed to Solana developers in Dec. 2025 and presented Aug. 12 fell outside Anza’s 50,000 SOL Alpenglow contest that closed Aug. 19.

Researchers privately notified Solana developers in December 2025 about a Proof-of-History clock attack that can extend a scheduled leader’s effective block window. The research team presented the finding at a security conference on Aug. 12. Anza’s 50,000 SOL Alpenglow contest closed on Aug. 19 and its rules excluded behavior reachable only when the legacy PoH and TowerBFT consensus path was active.\n\nThe paper describes a protocol-valid method in which a scheduled leader withholds a valid block, then publishes that block anchored to an earlier point in the PoH hash chain. If validators adopt the branch, their logical clock realigns to the earlier anchor; the researchers call this reset re-anchoring. Repeating the action, labeled Time Inflation (TI), can give the attacker more physical time to select transactions while logical time advances more slowly. A fork-assisted variant, Fork-Assisted Time Inflation (FTI), pairs re-anchoring with legacy TowerBFT fork choice and can orphan an honest leader’s block. Solana’s one-block-per-slot rule prevents an orphaned leader from producing a replacement for the same slot.\n\nThe research models an attacker holding less than 33% of stake, with no control of the network scheduler, and relying on a known, stake-weighted leader schedule. The model assumes partial synchrony and that an honest block reaches honest validators within one nominal slot after network stabilization. Experiments used a conservative delay tied to consecutive leader rounds. The team implemented TI and FTI on a local Solana testnet and ran simulations for full-epoch attacker configurations. The paper did not identify a single Agave client release as definitively exposed and did not report a live mainnet exploit, theft, or a consensus-safety failure on mainnet.\n\nThe authors examined public mainnet timing data and identified two validators that repeatedly appeared in the tail of the timestamp-interval distribution. Those validators combined longer intervals with higher transaction inclusion rates and low skip rates, a pattern the paper notes is consistent with TI’s fee-selection incentive. The researchers warned that hardware differences, local batching, configuration choices, network conditions or operational disruptions could produce similar timing patterns. The paper reports no clear evidence of FTI in public data and does not claim proof of on-chain manipulation.\n\nThe Alpenglow contest rules covered behavior that appears when Alpenglow is active and migration code whose behavior changes because of Alpenglow. The rules excluded faults reachable only when Alpenglow was inactive. Public design documents for Alpenglow show the upgrade replaces PoH and TowerBFT with a Votor design and local timeout mechanisms that do not rely on synchronized PoH-based time, removing the prerequisites TI and FTI use. Anza and the Solana Foundation have not published a paper-specific adjudication mapping each attack step to shipping code or ruling out migration-path risks.\n\nAccording to the paper, Solana developers were notified within a day of the December disclosure. The development group monitored for the behavior, expected a future protocol upgrade such as Alpenglow to address it, and judged the most severe scenarios unlikely under current conditions. The research team reported they had not fully deployed mitigations by publication. Agave 4.2 included Alpenglow components for community test clusters but did not activate the new consensus on mainnet; activation was expected in Agave 4.3.\n\nUntil Alpenglow is activated on mainnet and an implementation-level analysis or adjudication is published, the transition from the legacy PoH/TowerBFT path to Votor leaves open whether the exact legacy attack path is fully removed or whether migration logic could introduce similar risks.

Articles by this author