Jump Crypto Imposes Non-Refundable 1 SOL Burn for Firedancer Bug Bounty Submissions Amid Review Backlog Lessons

Jump Crypto has updated the terms for Firedancer, its independent validator software designed for the Solana blockchain, introducing a controversial requirement that researchers burn 1 SOL to qualify for bug bounty payouts. Under the terms, which became effective on October 18, the burned tokens are entirely non-refundable—even in scenarios where a security researcher submits a valid vulnerability report only to discover that another party has already filed the same issue.

This structural shift significantly narrows the pathways to compensation for secondary finders compared to the more permissive rules used during Firedancer’s spring audit contest. In a retrospective published by Jump Crypto on October 16, team member Ishan Bhatt addressed the friction caused by duplicate reports, openly attributing part of the problem to internal review delays. As the engineering team struggled to keep pace with incoming disclosures, researchers continued independently discovering and submitting vulnerabilities while earlier reports sat waiting for triage and action.

Under the current rules, the bug bounty program generally awards the primary submission for any given issue or its close variant, though the team preserves discretionary authority to issue rewards for select later reports. Despite these adjustments, the economic reality for security analysts has grown harsher, as uncovering a legitimate flaw no longer guarantees financial recovery if administrative bottlenecks or rival submissions interfere.

The updated framework contrasts sharply with Firedancer’s earlier Immunefi-hosted contest, which ran from April 9 to May 9. Published rules for that spring event explicitly permitted duplicate reports of unfixed bugs to remain eligible for rewards until a formal fix was publicly disclosed. According to Bhatt’s retrospective, that previous system charged a modest administrative fee of $100 per report alongside a daily submission limit of one per researcher.

The October framework discards that model in favor of a direct token burn paired with stricter limitations on duplicate eligibility. Under the current parameters, a later researcher can theoretically still earn a reward by demonstrating a significantly greater impact or a wider affected surface area than the initial filer. Furthermore, if an initial submission is incomplete or relies on incorrect technical assumptions, a subsequent report may be elevated to the primary finding. The team also retains the discretion to reward high-quality follow-up work that offers deeper insights.

However, the baseline requirements for validation remain rigorous. The terms dictate that relevant public repository materials—including code comments, pull requests, and mitigating changes located on public branches—are automatically classified as known issues. Privately known issues that can be demonstrated to predate a given report are evaluated on a case-by-case basis. Additionally, proof-of-concept requirements mandate a reproducible, end-to-end attack vector targeting the permitted branch and configuration to clearly illustrate practical impact, subject to narrow discretionary exceptions.

The submission portal mandates an irreversible transfer of funds to an incinerator wallet, making the 1 SOL cost non-refundable even if a report is ultimately deemed invalid, outside the program’s scope, or duplicate. Jump Crypto does not retain these funds as fee revenue; rather, they represent a direct financial exposure for the submitting researcher. While reports submitted without the required token burn may occasionally be reviewed, they are strictly ineligible for monetary bounties under the terms.

To offset these heightened barriers, Firedancer has temporarily boosted its reward multipliers. Eligible findings submitted by November 20 receive twice the standard payout, while findings specifically targeting Alpenglow consensus mechanisms qualify for triple the standard payout. Conversely, vulnerabilities affecting pre-Alpenglow consensus systems face significantly reduced discretionary rewards. The approaching deadline marks the expiration of this financial incentive boost rather than the conclusion of the bug bounty program itself. These updates align with the October 14 release of version v26.10.2, which incorporates Alpenglow support enabled by default in testnet and devnet configurations.

A Real Bug Can Still Leave Its Finder Out of Pocket

Firedancer makes bounty hunters burn 1 SOL even for duplicate bug reports

The decision to overhaul the reward structure stems from deep operational challenges encountered during the spring audit contest. Bhatt’s retrospective detailed a massive influx of data, noting 809 total submissions from 162 researchers, which yielded 127 unique security submissions outside of the contest’s broader insight category. Nearly half of all valid submissions turned out to be duplicates.

The most revealing metrics from the retrospective concern the triage queue. With submissions averaging roughly 26 per day, the engineering team’s backlog peaked at 299 open reports. Bhatt noted that approximately 80% of duplicate submissions arrived more than three days after the initial primary report, illustrating a clear feedback loop. Because earlier findings remained open, unfixed, and undisclosed while review protocols lagged behind the submission rate, other researchers were inevitably led to discover and independently submit the exact same flaws. This dynamic flooded the pipeline with redundant administrative work. Bhatt observed that duplicate submissions naturally tapered off only as the team’s triage capacity caught up with the incoming volume.

Compounding these review hurdles, the team observed that nearly every report generated during the contest appeared to have been discovered or assisted by automated AI agents. Jump Crypto suggested that independent researchers utilizing similar modeling tools naturally converged on the same underlying software bugs.

The issue of filing risks across major Solana infrastructure projects has drawn broader industry scrutiny. Similar financial hurdles emerged in August during a separate Alpenglow competition hosted by Anza, which required a 0.5 SOL burn per report. Firedancer’s retrospective highlights a crucial operational lesson for the broader developer community: internal review backlogs directly exacerbate the problem of repeated discovery by leaving vulnerability windows open longer.

The debate over charging researchers for participation extends beyond the Solana ecosystem. In January, prominent developer Daniel Stenberg announced the closure of the curl project’s bug bounty program, explicitly rejecting the idea of charging reporters due to the administrative friction involved and the inherent risk of deterring legitimate security talent from coming forward.

The Useful Test Is What Reaches a Fix

Beyond administrative queue management, Bhatt’s analysis detailed critical technical hurdles, including a high-severity scheduling finding that could theoretically cause Firedancer to execute transactions out of order and diverge dangerously from other validator clients.

In response to these findings, Jump Crypto has adjusted its processes, committing to document system invariants more explicitly to assist automated auditors. The live submission form now allocates up to 3,000 characters each for vulnerability descriptions, reproduction steps, impact assessments, and proof-of-concept data, complemented by a concise 1,024-character summary limit. Clearer foundational assumptions are intended to help researchers accurately evaluate suspected bugs, while structured reproduction instructions are designed to streamline the verification process for internal reviewers.

Under the current rules, researchers are advised to expect initial contact through a GitHub Security Advisory within 96 hours of submission and confirmation of the required token burn. However, this timeline covers only the initial acknowledgment window and establishes no definitive deadline for fully validating an attack, drafting a secure patch, or deploying a production fix across the network.