When doing bug bounty hunting for a living, both good and bad experiences contribute to the list of things to check for next time, when picking a BBP.
Crossing a certain threshold of experiences helped us overcome decision paralysis. We now rely on a set of checks and biases, so where to hunt (and where not to hunt) becomes clear.
In this article, we will omit some of these steps, and we apologize in advance. In our defense, we've been doing bug bounty hunting for so long that much of the process has become second nature, like breathing and blinking, making it difficult to distill what we do by instinct into a step-by-step beginner's guide.
Rest assured, we'll torture ourselves overnight each time we remember something we should have included but didn't.
How do you pick a program to hunt on these days?
(1) Target bounty
We always start by setting a minimum bounty threshold.
In Immunefi, our 2023 target list only included protocols offering five-figure rewards for critical bugs.
In 2025, after several five-figure payouts, we started hunting on protocols offering six figures.
By 2026, after a couple of six-figure payouts, our focus moved towards protocols offering seven-figure bounties per critical bug.
We expect to submit fewer reports this year, but a single confirmed critical should improve our ranking on Immunefi significantly.
(2) Programming languages
The set of programming languages we can read (or even feel like reading) narrows the list of targets.
In 2022, we started learning Solidity and spent the next couple of years exclusively auditing Solidity smart contracts.
Later, while brainstorming the most efficient way to achieve our 2025 goal (six-figure payouts), we decided to move beyond Solidity and target an ecosystem that:
- Does not host public audit competitions.
- Cannot directly benefit from Solidity best practices.
- Lacks widely used security-focused libraries for common operations (e.g., OpenZeppelin).
- Has enough protocols running bug bounty programs on Immunefi to reduce the risk of encountering an unfair project.
In 2025, Parachains met all five criteria, and since several were listed on Immunefi, we started learning Rust.
Moving from smart contracts to a large blockchain codebase written in a verbose and unfamiliar language (at the time) was overwhelming beyond description.
Still, the story had a happy ending: 4 critical, 1 high, and 5 medium bugs in total, across 6 different Parachains, were reported and rewarded via Immunefi.
We began with a bounty goal that filtered out most protocols, then brainstormed the easiest way of achieving it, and ended up with a small set of protocols to audit.
As of today, anyone can replicate the same strategy across one or two additional ecosystems if their goal is to secure one or two six-figure payouts within the next 12 months.
We won't disclose protocols or ecosystems. Publicly framing an ecosystem as potentially having critical bugs would be inappropriate; however, the hints provided should be sufficient to narrow it down.
(3) Project state
For each project, we review its website (landing page), its dApp (often on a separate subdomain), its GitHub, and its Twitter account.
Here is a concrete example of why this step matters:
INTMAX is running a bug bounty program.
As of today, its Terms & Conditions and even the main website appear normal.
However, visiting the dApp reveals a banner instructing users to stop their nodes and withdraw funds.
That rings a bell.
Further investigation leads to their Twitter account, where, after some scrolling, you can find an announcement from almost a month ago explaining what we interpret as: "There is a critical bug, the fix for which requires such a drastic protocol reimplementation, that we recommend everyone shut down their nodes, withdraws their money, and waits until further notice."
Based on that announcement, it is prudent to skip auditing that protocol; otherwise, you risk spending weeks rediscovering an issue they already identified or uncovering a new one that is ultimately irrelevant because the codebase is being deprecated or there are no funds at risk because everyone has already withdrawn their assets.
At this point, an inexperienced hunter may look for someone to blame: the protocol for not updating or pausing the bounty, or Immunefi for not tracking the status of the hundreds of independent dev teams that host bug bounty programs on its platform (which is not feasible to do).
The uncomfortable truth is that the responsibility ultimately lies with the researcher.
We do not assume that every protocol running a bug bounty program is in a healthy state; we verify it.
Additionally, we ensure the in-scope assets do not point to outdated implementations, and that the protocol's treasury seems healthy enough to pay the advertised bounty.
This step eliminates another portion of potential targets to hunt on and helps prioritize some protocols over others.
(4) Liquidity of the payout token
Some bug bounty programs pay in their own token. We use CoinMarketCap and the like to verify there is enough tradable liquidity to exchange the payout to a stablecoin.
(5) Novelty
Protocols that reinvent the wheel or introduce novel concepts in smart contracts or blockchains are highly likely to contain critical security issues. These consistently rank at the top of our target list.
This tip is less helpful for beginners because recognizing novelty requires familiarity with how battle-tested systems are typically implemented. Auditing well-known protocols is what helps internalize safe design patterns and develop a "spider-sense" for code smells.
(6) GitHub code update frequency
We love projects with frequent code changes.
Auditing these codebases is the best time investment we can make, because, even if they are free of bugs today, they may be a couple of pull requests away from introducing one.
This is even more relevant in 2026.
Many well-funded DeFi projects connect multiple AI Agents (as security experts) to their repositories. While they may catch some bugs, they also create a false sense of security, reducing reliance on thorough audits for small code changes and increasing the chance that a critical vulnerability reaches mainnet.
Conversely, we avoid codebases with no meaningful updates for a year or more. Even if a vulnerability could be found, we won't be able to continue to get value out of the time we already invested in learning how that protocol works.
(7) Primacy
We prioritize bugs that lead to loss of funds; therefore, we move up in our list of bug bounty programs to audit those that follow the Primacy of Impact and programs that follow the Primacy of Rules, but provide a scope open enough so that impactful vulnerabilities fall under scope.
For example, we give projects following the Primacy of Impact the same priority as a blockchain following the Primacy of Rules, but in the list of assets in scope, there is a link to the full node.
We generally avoid programs that follow a Primacy of Rules with a narrow, strictly defined asset scope.
Conclusion
When we apply these 7 general steps on top of whatever bug hunting strategy we have for the year, we consistently end up with a small list of bug bounty programs ranked from "best next target" to "well.. fingers cross".