Firedancer Offers Up to $300K for Alpenglow Bugs

Firedancer’s $300K bounty carries a 1 SOL cost

The terms effective October 16 put standard critical rewards at $50,000 to $100,000. During the boost, the corresponding range is $100,000 to $200,000, or $150,000 to $300,000 for Alpenglow-specific findings. The multipliers apply to the standard range, rather than stacking into a sixfold award.

The team retains discretion over eligibility, severity and payment. Researchers must complete identity checks, and accepted awards are paid in USDC. A headline maximum therefore describes an incentive, not money already paid or a guaranteed return for identifying suspicious code.

The mandatory burn creates an upfront cost. At the observed SOL price, 1 SOL was approximately $102, although its dollar value changes. The terms make the fee nonrefundable for duplicate, invalid and out-of-scope reports, so payment alone does not establish that a finding qualifies.

The submission page requires GitHub authentication, a payout wallet, an affected release and a proof of concept. Each submission opens a draft GitHub Security Advisory for triage. Its description, reproduction, impact and proof-of-concept fields each show a 3,000-character allowance, alongside a shorter summary field.

The form also warns that reports cannot be edited after submission. That makes the affected release and reproducibility information consequential before a researcher pays the submission cost. A report that merely names a possible weakness leaves reviewers with different evidence from one that demonstrates an observable result.

Firedancer’s 809 reports exposed a review bottleneck

Jump said the earlier competition received 809 reports from 162 researchers, yielding 127 unique security submissions excluding informational findings. Nearly half of valid submissions were duplicates. These are research-program statistics, rather than counts of attacks, victims or wallets losing money.

The team believes nearly every submission was discovered or written by an AI agent. That is Jump’s assessment of the reports, not an independently measured proportion. It said the review backlog peaked at 299 open reports and now imposes shorter submission sections.

The distinction between generating a plausible report and confirming its practical impact explains the platform’s emphasis on reproduction. More submissions can reveal additional weaknesses, but their volume alone cannot establish either improved protection or a worsening live incident.

Firedancer’s official documentation describes an independently written Solana client with restrictive process sandboxing and minimal system calls. Its purpose includes reducing shared software and dependency risks. A validator client is the software operators use to check transactions and participate in agreement on the ledger.

Independent code can reduce exposure to a defect shared by other implementations, while still requiring its own scrutiny. A bounty creates a channel for that scrutiny; the existence of a reward schedule is not a certification that all important flaws have been found.

This connects to Fidelity researchers’ Solana concentration assessment: counting validator identities is different from assessing how many independent software failure paths a network has. Client diversity and the quality of each client’s testing address related parts of that problem.

Alpenglow support does not cover Solana’s migration

Firedancer’s October 14 release v26.10.2 lists Alpenglow support, enabled in default testnet and devnet configurations. The same notes explicitly say migration from Tower to Alpenglow will not be supported.

The release also adds vote-history handling for failover and describes support for Solana 4.3 features. Those capabilities should be read alongside its migration limitation, rather than treating a general compatibility statement as permission to ignore transition instructions.

The Solana Foundation’s upgrade page schedules activation for epoch 1064, expected around 15:00 UTC October 21. Its operator instructions require an Agave-based client built on Agave 4.3.0 and say Firedancer and Frankendancer are not supported during the migration.

That distinction gives the bounty a specific context: testing code that supports a new consensus system and participating in the handoff to that system are separate tasks. A triple reward for Alpenglow findings does not remove a documented operational restriction.

Anza’s Alpenglow documentation describes Votor replacing Tower BFT’s voting and finality logic. It targets roughly 150-millisecond finality under normal conditions, while nodes outside the admitted validator set can learn of finalization later through subsequent blocks or partner connections.

The target concerns when transactions become irreversible, rather than a guaranteed response time for every application. Security testing, consensus performance and the timing visible to infrastructure users therefore measure different aspects of the rollout.

Alternative.me’s index displayed 53, classified as Neutral, versus 55 previously when checked around 18:00 UTC. It measures broad crypto sentiment, rather than confidence in Firedancer’s code.

The next scheduled milestones are the October 21 consensus transition and the November 20 reward deadline. The reviewed announcement does not establish how many new-program reports will qualify or the total that will be paid. Those outcomes, alongside updated client instructions, remain the concrete developments to watch.