Solana’s 50,000 SOL security contest did not cover a clock attack disclosed months earlier

At USENIX Security, one of the field’s major peer-reviewed conferences, researchers on Aug. 12 presented a Solana Proof-of-History clock attack that they had privately disclosed to Solana developers in December 2025. Anza — the firm that develops the Agave validator client — closed its 50,000 $SOL Alpenglow competition seven days later, and its rules appear to have placed the attack outside the scope.

The paper describes a protocol-valid method by which a scheduled leader can stretch its effective block window and suppress honest leaders’ proposals in a fork-assisted variant. The technique depends on Proof-of-History and TowerBFT — Solana’s logical clock and the consensus mechanism built on top of it — the components that Alpenglow is intended to replace but had not yet displaced on mainnet in Agave 4.2.

The result raises two separate issues: whether the attack belonged inside the contest scope, and whether the protocol transition itself leaves room for risk.

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, or PoH, uses a sequential hash chain to provide Solana with a logical clock. Validators continue advancing their local view of that clock when a scheduled leader does not immediately publish a block.

According to the researchers, a malicious scheduled leader can withhold a protocol-valid block while honest validators move ahead, then later release the block anchored to an earlier point in logical time. If validators accept that branch, they align their PoH state to the block’s earlier point. The researchers call this reset “re-anchoring.”

Time Inflation, or TI, repeats that maneuver to give the attacker more physical time to choose transactions while logical time advances more slowly. Fork-Assisted Time Inflation, or 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 — under the one-third fault bound that Byzantine-fault-tolerant protocols are conventionally designed to tolerate — 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 that more stake could widen a risk-free release window, but it 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 — a transaction-ordering advantage of the kind the broader industry discusses under the label maximal extractable value, or MEV.

The paper says hardware differences, local batching or other configuration choices, network conditions, and operational disruptions could also 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 does not show a live exploit, theft, demonstrated mainnet manipulation, or a consensus-safety break.

Why the Solana Alpenglow contest likely 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.

The gap is a familiar one in time-boxed security competitions: scope rules, not severity, decide what is rewarded. The competition covered faults caused by Alpenglow or its migration, while the paper targets the legacy time and fork-choice model that Alpenglow is designed 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 — a Solana Improvement Document in the network’s formal change process — 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 used by TI and FTI. The public record does not include 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 treated the behavior as 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 — expected in Agave 4.3 — and a public implementation-level response, the transition remains the unresolved part of the story.