A Hacker’s Guide to Submitting Bugs on Immunefi

Published in
9 min readDec 22, 2021


Many whitehat hackers and bug bounty hunters who discover Immunefi already have some experience under their belt. They’ve often submitted bugs on other bounty platforms. They think that Immunefi — and Web3 hacking — is pretty much the same as Web2, except with a different language.

That assumption is wrong.

Web3 hacking, as we’ve written about previously, represents an entirely new revolution in security.

It’s not just a new language (Solidity, Substrate, Vyper, etc.), and it’s not just a few different classes of vulnerabilities.

In Web3, hundreds of millions of dollars are regularly at risk of being hacked, unlike in Web2. Without whitehats submitting bugs on Immunefi, it’s possible that blackhats would have stolen $2 billion dollars in user funds in a year’s worth of time.

What this means is that the bounty payouts have to be higher — orders of magnitude higher. It’s not enough to have a bounty of $1,000, $5,000, or even $10,000 when countless millions of user funds are at risk.

It makes sense to price bounties relative to funds at risk, or otherwise price them as high as is feasible for the project. That’s why Immunefi hosts the world’s largest bug bounties.

But what does this have to do with hackers submitting bugs on Immunefi?

Some whitehats come to Web3 having been poorly treated and underpaid in Web2, and they bring that attitude to Immunefi — not knowing that they now have far more rights and respect than before.

It’s time for hackers on Immunefi to receive a mindset upgrade.

Web2 Bugs vs. Web3 Bugs

The whitehats who hunt on Immunefi are a special cadre of some of the best hackers in the world at the cutting edge of technology, finding world-changing vulnerabilities. No hacker who finds bugs on Immunefi is a regular hacker. They are by definition, an elite hacker. And elite hackers have the right to be treated like elite hackers.

Whitehats on Immunefi have the power to negotiate their payout by firmly pointing to the severity of the vulnerability. If it is indeed a critical bug, it should be paid like one, and projects should be reminded that paying a big bounty is much, much better than being exploited and losing massive reputation. Sometimes, hacks even destroy projects permanently.

But make sure not to abuse this power. With great power comes great responsibility. Using this power in an unjustified way is a violation of the rules.

Negotiating Your Payout

At Immunefi, we’ve pioneered the scaling bug bounty standard, which is the idea that bounties should be priced proportionate to funds at risk: 10% of funds at risk is ideal. For now, most projects don’t meet that goal, but many still have very large bounties, which makes it worth the whitehat’s time to find and deliver a critical vulnerability in the form of a well-written, well-explained report.

However, we’ve seen some less-than-healthy behavior from projects, and whitehats end up feeling like they don’t have any negotiating power and that they should be happy to just accept whatever payment they’re offered, even if it doesn’t make sense according to the terms of the project’s own bounty program!

Sometimes, when this happens, whitehats have to know their rights and begin negotiation.

First, whitehats should know that when projects onboard to Immunefi, they consent to a Service Level Agreement (SLA) that determines the response times they commit to for receipt of report, decision on report, and payout for valid reports.

Here is the table:

If projects take longer to respond than is listed in the SLA, whitehats are well within their rights to poke them for a response.

Whitehats also need to realize all the ways that projects benefit from their hard work. With an important vulnerability patched, projects can protect their brand image and keep user funds safe. User trust is often as important, if not more, than the funds being protected. Keep this in mind when negotiating. Knowing the needs and values of a project can help you find common ground and make things easier when you ask for a proper valuation of the bounty reward.

This approach is known as Tactical Empathy, a term coined by Chris Voss, the founder of business negotiation consultancy The Black Swan Group, who has years of experience leading high-stakes negotiations for the FBI.

If you listen well and align your narrative with the facts to be in your favor, then you are more likely to stay in control of the negotiation and get the right payout amount for your bug submission.

Always remember: there is an abundance of bugs, and a scarcity of talented bug hunters. Economically, you as a Web3 whitehat are at an advantage. This is also partly why Web3 bounties are priced much, much bigger than they are in Web 2.

So negotiate. By negotiating with projects, you also have to raise the quality of your skills, which is more work, but definitely will make it more valuable for you in terms of payout and time spent.

Hunting Sizeable vs. Tiny Bugs

Submitting low-quality bugs from a code scanner is a poor use of your valuable time. Additionally, we may penalize you for submitting those bugs if you don’t verify them, as it’s a waste of your time and of ours.

As a Web3 hacker, you have the potential to find critical vulnerabilities that affect millions of dollars in user funds. If you spend all of your time and efforts scanning for common issues, making hundreds of low-effort, repetitive bug reports hoping to hit a few, you may only end up with a low payout.

Why spend hours tediously submitting hundreds of tiny bugs for pocket change, when you can focus your energy and find the one huge critical that will set you for life?

Avoid “spray and pray” behavior: repetitive low-effort bug reports that often lead to no payout, and has little-to-no potential of a follow-up from a project.

Also, known vulnerabilities stick out like a sore thumb during the audit process, so chances are they are already taken out by the time the project is live and running a bug bounty program.

You may think that there is only a slim chance of finding a huge bug, but exploits still happen often enough that never finding one is almost an impossibility.

And if you think there’s not enough bounty rewards available, think again: there are currently over 20 bounties on Immunefi that pay up to $1 million dollars or more, and over 100 bounties that pay $100,000 or more. Even scoring just 1 out of these bounties can be life changing for most people, and there is plenty more in the $10,000 — $99,000 range.

Chances are, it’s a much better use of your time to study and look for high value bugs than common ones that are easy to find.

Play By The Rules

Study the Immunefi rules carefully, in addition to the rules listed on every bounty page. Make sure that you abide by them, but also ensure that the project does so as well. The rules establish what type of vulnerabilities are in scope, and at what level of severity. These are factors that will affect your payout at the end of the day, so make sure that you know them and hold them accountable to it.

Don’t give a project any reason to disqualify your submission. And remember that if you play fast and loose with the rules, you are essentially forfeiting your payment, as well as endangering any future prospects you might have within a bug bounty program. So do not harass projects or test exploits on mainnet or on public testnet. Doing so is extremely dangerous and will get you banned.

Submit High Quality Reports

You are a bounty hunter, not a bounty laborer. Think of yourself as an elite specialist, because not many people can do what you do.

Bugs you find could destroy a project entirely, or severely hinder its operation. Both your report and payout should reflect how serious the situation is. So take it seriously. Don’t submit a three-line report. That’s not likely to get much attention at all. Be as thorough, deliberate, and detailed in your report as you need to be, in your pursuit of a big bug bounty.

Your relentlessness will pay off, quite literally. The difference between a surface-level report and a well-written one can be massive. It’s time to upgrade your report quality, if you haven’t already.

Web3 whitehats go beyond simply “finding the bug”. This is why they are highly paid and respected. They understand the system design and mechanics at a deeper level than the project themselves, and this is what enables them to find previously unknown vulnerabilities in the smart contract.

This means your report must include an explanation of not only the exploit itself, but also the background of the mechanics and design of the code involved. Essentially, providing valuable context for the issue in order for a project to fully understand and prevent it from happening again.

There are many ways to do this. For example, in our latest post-mortem about the patched uninitialized proxies bug on Harvest Finance, we dive into the mechanics of exactly how the bug could be exploited. But also, there’s an explanation of why the bug occurs in the first place:

“This critical bug could have led to the self-destruction of the implementation contract, which could have rendered the proxy contracts useless.

This is because of the upgradeable proxy pattern used: one with the upgrade logic residing within the implementation contract rather than the proxy.”

In your report, you should also be able to articulate precisely how much economic damage can be done by the exploit. In our experience, the absence of this information is one of the biggest factors that slows down the bug reporting process. If you leave it out, you might not get paid what the bug is actually worth. Make your life–and everyone else’s life–easier. Present the economic damage clearly and explicitly. As Algernon Sydney said in his seminal 1698 work Discourses Concerning Government, “God helps those who help themselves.”

This is where having a complete and functioning PoC, or a detailed step-by-step example of how the exploit works can come in handy. The PoC must not require the project to complete it.

When writing your PoC or step-by-step exploit example, you could also make an effort to further optimize your attack parameters, to find the maximum economic damage that can be done by the vulnerability. This is highly correlated to the scope and severity of your submitted bug, and could very well affect the final payout you get.

And the most important part? PoCs should be tested on a local network like a mainnet fork or as a unity test. If exploits are tested on mainnet or public testnet, this not only constitutes a malicious attack, but will earn you a permanent ban from Immunefi. It’s important that we operate as whitehats, not blackhats. And being a whitehat means *not* testing your exploit publicly, so that someone could see what you’re doing and replicate it.

Knowing When To Escalate

There are times when you’ve submitted a bug and haven’t received a word on it for weeks. Or a project may come back to you and declare that they decided to pay a much lower bounty than agreed upon, or some may try not to pay at all.

When this happens, you should not be passively waiting for a solution or trying to create one yourself, but instead highlight the issue to Immunefi. And don’t forget that projects have signed SLAs, as mentioned above!

If it’s only been a few hours, or a few days, it’s fine to wait. But if it’s been up to 14 days without a response on a critical bug submission, delay no longer. You should reach out to the project and also the Immunefi team via the submission thread, so that they can contact the project and check on the status of your submission.


As a whitehat working in Web3, there is much more to your job than simply “search and destroy”. You are an elite member of an exclusive network of bounty hunters who target, isolate, and eliminate errors in code design and architecture in a world where less than 0.01% of people probably even fully understand what you do.

There is more to what you do than simply “making pocket money”. Your actions could determine whether the industry will continue to exist, or perish under the corruption and selfish actions of malicious actors.

And while you are here, Immunefi is here to: 1) help you learn and become an elite ethical hacker, 2) provide you with the platform to hunt bugs and get paid, 3) provide help and support when you need it.

Apart from the core team, Immunefi includes a community of ethical hackers who are in the same boat as you, and have probably experienced much of the same things you have experienced while hunting for a bug or trying to get a bounty payout. You can always ask for advice from other whitehats in our Discord.

Remember that you are a valuable part of everything that is happening in DeFi and Web3, and always don’t be afraid to ask for help, even if you are kind of a superhero in this space.




Immunefi is the premier bug bounty platform for smart contracts, where hackers review code, disclose vulnerabilities, get paid, and make crypto safer.