Full Report
WhiteMage is currently #1 on Immunefi for earnings in 2025. Somebody asked about how people pick bug bounty targets. This was his response to it. First, pick any topic; not target, topic. This can be specific functionality, a type of protocol or anything that is specific. The more specific the better. Next, find all projects with a bounty or a large TVL, like 20 of them. To me, this is unique. I tend to pick a project that is isolated and spend several months on it. Go over each one of the projects to understand what they are doing. Notably, since they are all similar, note down how they do it and what could go wrong. To begin, just get the gist of it and don't go too deep. After a while, the same thing will be done over and over again. If something is being done differently, it's a good place to look at bugs. Take time to look at suspicious things in depth. Go deeper and deeper into the intricacies of the functionality. With this, you'll gain more and more knowledge about this niche thing. These small details may lead to a bug or a wrong/sus pattern. Understand under what circumstances that this can be triggered and cause havoc. They refer to this as a almost crit. At this point, you may have a lead at an issue. Save this and keep going! They have a great quote about it: " A lead is not a checklist bug, nor a vulnerability on a writeup. It's the understanding of something that on very specific scenarios can trigger a serious vulnerability." Check all of the other projects for the same types of issues. It won't be exactly the same but there's a chance that similar types of mistakes were made. Now, prove that the issue leads to impact on the code. Prove this on all possible projects, write a PoC and report it. For a bug on Scroll, the cross-chain messaging had a to.call(data), where the to had some magic values that shouldn't be controllable. They learned this pattern from reading bridges in the past and noticed that a particular check was missing in this code. Another bug was in Story around block sizes. When Story/Omni changed the default block size maximum, this was fine. However, because the mempool is separated from the block creation in their protocol, this felt weird to the WhiteMage. A mismatch between expectations and reality seemed like a good path for a bug. Having experience with memory exhaustion and triggering node crashes seemed to help them. He has a few do-nots: Pick an amount of contracts that is actually doable. Don't pick all contracts on Ethereum. Don't read all of the code. Only Just read the common denominator between all of the projects. Don't follow checklists or writeups blindly. If it's on a checklist, it's probably been found. Feel free to use the checklist for inspiration but not much more. They have a great quote at the end: "It's always some new idea around the same old concepts, but you have to do it for yourself. Then you can come up with some creative name like "read-only reentrancy" Thanks for sharing!
Analysis Summary
# Best Practices: The "Deep Niche" Vulnerability Research Methodology
## Overview
This summary outlines the specialized methodology used by **WhiteMage** (#1 on Immunefi, 2025) for high-impact bug hunting. Rather than horizontal scanning of multiple unrelated projects, this strategy focuses on **niche functionality mastery**, identifying logic flaws through cross-project comparative analysis, and exploiting "mismatches" between protocol expectations and reality.
## Key Recommendations
### Immediate Actions
1. **Define a Topic, Not a Target:** Choose a specific protocol type (e.g., Cross-chain bridges, Liquid Staking, Mempool management) rather than a single company.
2. **Breadth-to-Depth Filtering:** Select ~20 projects with high TVL or active bounties within that niche to establish a baseline of "normal" behavior.
3. **Identify "Common Denominators":** Scan the codebases to identify core logic shared across all 20 projects. Do not read the entire codebase yet; focus only on the shared functionality.
### Short-term Improvements (1-3 months)
1. **Spot Architectural Deviations:** Analyze projects that deviate from the standard pattern. If 19 projects handle a function one way and the 20th does it differently, investigate that deviation immediately.
2. **Develop "Leads" Over "Checklists":** Ignore standard bug checklists. Instead, look for "leads"—unique scenarios where specific conditions could trigger a vulnerability.
3. **Identify "Almost Crits":** Map out scenarios that feel "wrong" or "suspicious" even if an exploit isn't immediately obvious. Deep dive into the intricacies of these specific functions.
### Long-term Strategy (3+ months)
1. **Cross-Project Exploitation:** Once a vulnerability pattern is proven in one project, systematically test the "lead" across the remaining 19 projects.
2. **Pattern Recognition Mastery:** Build a mental library of historical failures (e.g., bridge messaging flaws or node memory exhaustion) to apply to emerging technologies.
3. **Creative Vulnerability Synthesis:** Move beyond known bug classes to discover "new" variants (e.g., the next "read-only reentrancy") by understanding the friction between different system components.
## Implementation Guidance
### For Independent Researchers
- Focus on specialized niches where you have a competitive edge. Do not try to scan all of Ethereum; stay within a "doable" amount of code.
### For Security Auditing Teams
- Assign "Topic Specialists" rather than "Generalist Auditors." Force a comparative analysis between the current audit target and previous targets in the same sector.
### For Protocol Developers
- Pay close attention to points where your protocol interacts with external components (mempools, cross-chain relays). These "mismatch" zones are high-risk areas for critical failures.
## Configuration Examples
*While specific code was not provided, the following logic patterns were highlighted as high-risk:*
- **Cross-Chain Calls:** Inspect `to.call(data)` patterns where the `to` address or `data` contains "magic values" that may be user-controllable.
- **Resource Limits:** In protocols where mempool management is decoupled from block creation, verify that maximum block size changes do not lead to memory exhaustion or node crashes.
## Compliance Alignment
- **NIST SP 800-53:** Supports System and Information Integrity (SI) controls through deep-dive vulnerability analysis.
- **OWASP Top 10 / ASVS:** While checklists are discouraged as a primary tool, this method aligns with "A04:2021-Insecure Design" by focusing on logic and architecture.
## Common Pitfalls to Avoid
- **Blind Checklist Usage:** If a bug is on a popular checklist or writeup, it has likely already been found and patched. Use them for inspiration only.
- **Information Overload:** Do not read every line of code in every project. Read only what is necessary to understand the niche functionality.
- **Surface-Level Analysis:** Avoid reporting "checklist bugs." Focus on the "Lead"—the deep understanding of specific scenarios that trigger havoc.
- **Target Hopping:** Avoid jumping from project to project daily. Stick to the chosen "Topic" until you understand the intricacies better than the developers.
## Resources
- **Immunefi:** Platform for identifying high-TVL bounty targets.
- **Project Documentation:** Use documentation to understand "intended" behavior vs. "actual" code implementation.
- **Historical Bridge Writeups:** Resource for learning "magic value" and cross-chain message patterns.