Firedancer Keeps Your 1 SOL When the Bug's a Duplicate, and the Retrospective Doesn't Add Up
Firedancer's bug bounty takes a 1 SOL deposit from researchers, and duplicate reports don't get it back. A team retrospective now blames repeat discoveries for slow review, which means the researcher pays for the team's bottleneck. Nobody's published the numbers on how often that happens.
Firedancer will take 1 SOL from you before it reads your bug report. If someone else got to the same bug first, that SOL stays with Firedancer.
That's the mechanic. Here's why it deserves more attention than it's gotten.
The Sequence
Firedancer is Jump Crypto's answer to Solana's client concentration problem, and it's the most scrutinized piece of software on that network. Solana holds tens of billions in onchain value and runs, for practical purposes, on one dominant validator client. A second client isn't a nice-to-have. It's the thing that stops a single memory bug from taking the whole chain down. So for this particular project, bug bounties aren't marketing. They're the security model.
This spring, the team ran a bounty contest. Reports that qualified earned rewards, and eligible duplicates could earn something too. I'll say it plainly, that's a more generous posture than most programs take, and the team should get credit for trying it.
Then the contest ended and the retrospective landed. A Firedancer team member named Bhatt wrote it up and pointed at repeated discoveries as one explanation for slow review. Read that sentence again.
Duplicate reports, in the team's own account, contributed to the review bottleneck. And under the standing rules, duplicate reporters are the ones who lose their 1 SOL. So the spring contest was the exception. The default is that you absorb the cost of Firedancer's triage queue.
Deposits against spam are a real tool, and I won't pretend otherwise. A public bounty with no friction gets buried in low-effort submissions, and security teams drown. But there's a difference between filtering junk and charging admission to a conversation the team says it's too backed up to have.
Who Actually Pays
Here's where the incentive math gets ugly. A duplicate isn't proof that a researcher wasted anyone's time. It's proof that two people read the same code and reached the same conclusion about where it breaks. That's a signal the bug is real and reachable. Independent rediscovery is one of the strongest validation signals in security research, and the program treats it as a fee.
1 SOL moves with the market, so the deposit's real cost swings week to week, but it's never nothing. For a full-time auditor in Lagos or Buenos Aires or Manila, a handful of duplicates in a month is a meaningful line item. The researchers most likely to find the deep memory-safety issues in a validator client are exactly the ones reading the codebase hardest, and they're the ones most likely to independently trip over the same fault.
Now consider the other side. Who's responsible for the duplicate in the first place? Often, the team is. Private reports stay private. Fixes get merged quietly. A researcher working from a stale branch or a months-old commit has no way to know a finding is already in the queue, and the program doesn't appear to publish a deduplicated public tracker. Punishing the researcher for a gap the team created is backwards.
Let's apply the standard the industry set for itself. Show me the audit. How many duplicate reports came in during the spring contest? How many deposits were forfeited, and what's the total in SOL? Is there an appeals process, and who sits on it? Is the deposit policy written down anywhere as a formal rule, or does it live in a bounty page that can change between submissions?
None of that's public. The burden of proof sits with the team, not the community.
And here's the hot take that'll annoy some people. A bounty program that charges for duplicates is really a bounty program that outsources the cost of its own review backlog onto the least resourced party in the transaction. The team keeps the security benefit, the researcher eats the risk. That's not a bounty, it's a toll.
What To Watch
Three concrete things.
First, the next round. Firedancer has run contest cycles before, and the terms of the next one will tell you whether the spring duplicates rule was a genuine policy shift or a one-off gesture that quietly disappears. Watch for a published policy document with dates attached.
Second, the numbers. Any serious program should be able to report, per quarter, how many submissions it received, how many were duplicates, and how much it collected in deposits. If those figures never surface, that's your answer about how the incentive is designed.
Third, the precedent. Other client teams watch Firedancer closely, and if a 1 SOL duplicate fee becomes standard, every researcher in the Solana security market is paying it. That's a structural change to who can afford to do this work, and it'll shrink the pool of independent eyes on the code.
Here's the part that should worry the team more than any critic. The people who file duplicates are the people who file the real bugs. You can keep their 1 SOL. You just might not keep their phone number. A researcher who loses money reporting a genuine finding has a very simple way to avoid that outcome next time, and it doesn't involve telling Firedancer anything at all.
Skepticism isn't pessimism. It's due diligence.
Explore More
Key Terms Explained
A reward offered by crypto projects for completing specific tasks like finding bugs, writing code, or creating content.
A reward program where protocols pay security researchers for finding and responsibly disclosing vulnerabilities.
A high-speed Layer 1 blockchain known for cheap transactions and fast finality.
A transfer of value or data recorded on a blockchain.