Firedancer, Jump Crypto’s independent validator software for Solana, requires researchers to burn 1 SOL to qualify for a bug bounty under terms effective Oct. 18. The burn is non-refundable even when a report identifies a real vulnerability that someone else submitted first.
The change narrows the route to payment for later finders compared with Firedancer’s spring audit contest. In an Oct. 16 retrospective for Jump Crypto, Ishan Bhatt partly attributes the duplicate-report problem to the team’s own review delays: researchers kept finding bugs while earlier reports waited for action.
The current terms generally award the first submission about the same issue or a similar variant, while preserving discretionary rewards for some later reports.
A real bug can still leave its finder out of pocket
Firedancer’s earlier Immunefi contest ran April 9–May 9, 2026. Its published rules explicitly made duplicate reports of an unfixed bug eligible for rewards. Once a fix was publicly disclosed, new reports became invalid, while reports submitted before the fix remained eligible.
That was already a paid submission system. In his Oct. 16 Hardening Firedancer retrospective, Bhatt says the contest charged $100 per report and imposed a limit of one submission per researcher a day. The October development is a different fee structure paired with narrower duplicate eligibility.
RuleApril–May contestCurrent Firedancer bountySubmission cost$100 per report, according to BhattNon-refundable 1 SOL burn for bounty eligibilityDuplicate eligibilityUnfixed duplicates eligible before public disclosure of a fixFirst submission generally receives the reward; later-report exceptions remain discretionaryResearcher exposureA qualifying later report could share in contest rewardsThe burn remains a cost even when a duplicate earns no reward
A later researcher may earn a reward by demonstrating greater impact or a wider affected surface. An incomplete first submission, or one resting on incorrect assumptions, may allow a later report to become the chief finding. The team can also reward high-quality later work.
Eligibility also extends beyond duplicate status. The terms treat relevant public repository material, including code comments, pull requests and mitigating changes on public branches, as known issues. Privately known issues that demonstrably predate a report receive case-by-case consideration. The baseline proof-of-concept requirements call for a reproducible end-to-end attack against the allowed branch and configuration, showing practical impact, subject to specified discretionary exceptions.
The submission form describes an irreversible transfer to an incinerator wallet. The terms also make the burn non-refundable for invalid and out-of-scope reports. This is a cost burned by the researcher; Jump does not collect it as fee revenue. Reports without a burn may or may not be reviewed, but cannot receive a bounty under the terms.
Firedancer is keeping rewards available and temporarily increasing them. Eligible findings receive twice the standard payout through Nov. 20, 2026, or three times the standard payout for Alpenglow consensus findings. Findings affecting only pre-Alpenglow consensus receive greatly reduced discretionary rewards. The deadline ends the boost, rather than the bounty itself.
The Oct. 14 v26.10.2 release includes Alpenglow support enabled in default testnet and devnet configurations.
The duplicate queue had a review problem
Bhatt’s account of the spring contest explains why the payment change reaches beyond spam deterrence.
He reports 809 total submissions from 162 researchers, resulting in 127 unique security submissions outside the contest’s insight category. Nearly half of valid submissions were duplicates. The 127 figure counts distinct non-insight submissions; the duplicate share refers to the broader pool of valid submissions.
His more revealing figures concern the queue. At roughly 26 submissions a day, the backlog peaked at 299 open reports. Around 80% of duplicate submissions arrived more than three days after the primary report, he says.
Bhatt describes a feedback loop. Earlier findings remained unfixed or undisclosed while review lagged, leaving other researchers to discover and submit the same problems. Those reports added more review work. Duplicate submissions declined as the team’s triage caught up, according to his account.
Bhatt also says the team believes nearly every contest report was discovered or written by an agent. He suggests researchers using similar models converged on the same bugs.
CryptoSlate reported a similar filing-risk issue in August during Anza’s separate Alpenglow competition, which required a 0.5 SOL burn per report. Firedancer’s retrospective adds a specific operational lesson: its own review backlog helped keep opportunities for repeated discovery open.
In his Jan. 26 account of curl’s bounty closure, Daniel Stenberg rejected charging researchers at that point partly because of administrative friction and the risk of deterring legitimate reporters. He announced the bounty would stop Jan. 31 while private security reporting continued.
The useful test is what reaches a fix
Bhatt’s retrospective describes a high-severity scheduling finding that could make Firedancer execute transactions in a different order and diverge from other validator clients.
Firedancer has changed parts of that process. Bhatt says the team is documenting system invariants more explicitly for automated auditors. The live form allows 3,000 characters each for the vulnerability description, reproduction steps, impact and proof of concept, with a 1,024-character summary. Clearer assumptions can help researchers assess a suspected bug; concise reproduction instructions can help reviewers act on it.
The current terms also tell researchers to expect contact through a GitHub Security Advisory within 96 hours after submission and confirmation of the required burn. That expectation covers initial contact. It supplies no deadline for validating the attack, preparing a patch or deploying a fix.
