Rethinking bounty discovery at Immunefi
The Explore page was just a listing. Hundreds of bug bounty programs with no real way to tell what was actually there, or which ones were worth a whitehat's time. I rebuilt discovery around how security researchers actually evaluate a project, not just how the data happened to be stored.
The problem
Before this work, the Explore page showed every bug bounty program on the platform in one flat list. There was no filtering by language or framework, no signal on which projects were strong, and finished programs looked the same as everything still active.
That cost everyone time. Whitehats had to click into programs one by one just to figure out if they were even a fit, and good projects had no way to stand out from the rest.
What I owned
I owned this end to end, over several years, alongside the rest of my work on the platform. That meant sitting down with whitehats directly to understand how they actually decide whether a project is worth their time before I designed anything.
How I approached it
The real problem was that nobody had ever built a proper categorization system for this industry. It didn't exist yet, so I had to build it from scratch. I talked to whitehats about what they actually looked for: the language a project was written in, the framework, whether something like Solidity was being used in a nonstandard way, the kinds of vulnerabilities they cared most about finding. I learned how they thought about evaluating a target, then built a taxonomy around that thinking so they could filter as broad or as precise as they wanted.
The cards themselves were doing double duty too. Not every project on the platform was equally good to work on, so strong projects carried badges for things like response rate, payout history, and vault size. It let the best programs stand out and pushed engagement toward the projects that actually deserved it, without anyone having to manually curate a thing.
The split between "learn more" and "view results" on finished programs is because they're actually pointing at two different products. The standard bug bounty program is open ended, with no education built in. Attackathons, which I also built, is timed and has an educational component from the start. Splitting the action made sure people landed on the right one instead of guessing.
Outcome
- Helped protect $180B+ in Web3 funds
I don't have discovery specific numbers to point to, since this work played out over several years alongside everything else I was building. But better categorization meant better matches between researchers and projects, which meant more payouts and stronger security outcomes across the board. It also saved time on both sides. Researchers stopped guessing, and projects stopped fielding questions from people who were never going to be a fit.
Looking back
The best filter is the one that tells you it won't work before you waste time trying it.
Building the categorization system taught me that good information architecture is really just translated empathy. I had to learn how whitehats already thought about a target before I could organize anything for them. That's stuck with me since. Structure only works when it comes from how people already think, not from how the data happens to be stored.