Crypto is the wild west, which is both a strength and a weakness. It’s a strength because its norms of freedom, tolerance, and open-mindedness allow for a culture that genuinely supports building radically new things — what Silicon Valley used to represent. But it comes at a cost. Frontiers can be lawless places with bad actors who take advantage of tolerance, limited oversight, and lack of regulations to scam, defraud, and hack.

This, of course, represents a huge problem for the builders and developers in Web3, who need some form of security to protect their projects from being wiped out in an instant.

Smart projects adopt the standard of the DeFi Security Stack, which includes audits, automated monitoring, and bug bounties.

This article is going to focus on bug bounties — but not from the perspective of a hacker. Rather, from the perspective of the project.

How can projects run a successful and ethical bug bounty program on Immunefi, keep themselves secure, and promote good norms that boost security for all of DeFi?

Some projects have asked us for a starting guide. That’s what this article is about.

No Project Code Is Perfect “Right out of the Box”

Although the Web3 space is home to talented developers ahead of their time, there is no such thing as “perfect code”. Solidity is a living (and young) language, and Ethereum is a living blockchain. Add that to the growing number of projects and smart contracts being added to the space, with 100k-200k new addresses daily according to Etherscan.

Each of these smart contracts can interact with other contracts in unanticipated ways, which open up a myriad of ways to coordinate, but also new vectors of attack. This means that security is not a “set it and forget” mechanism, but rather an ongoing effort of developers, whitehats, and user communities who have to constantly improve and stay vigilant — or get hacked.

This is why bug bounties are a necessity. They’re blockchain’s last line of defense against devastating hacks. But bug bounties are relatively new to blockchain. Just over a year ago, they barely existed, and so the knowledge of how to run successful and ethical programs is still immature.

Running a Successful and Ethical Bug Bounty Program

Many whitehat hackers are DeFi users, too, and they want to help secure the very same place they invest their money into. Together, whitehats in crypto have saved billions of dollars of user funds and countless projects from total ruin through responsible disclosure via Immunefi. All this in less than a year.

Whitehats are doing their job and acting ethically. And of course, Immunefi makes sure that their interactions with projects occur within appropriate boundaries. So, how can projects with bounty programs also do their job and act ethically to keep themselves and their users secure?

Here are some steps projects can take to make sure their bounty program is an ethical bounty program with the highest chance of successfully receiving serious vulnerabilities, patching them, and paying them out.

• The project website should have a link to their bug bounty on Immunefi, so whitehats know that the bug bounty is verified and where to report vulnerabilities. It also increases trust among users of the project.
• Once bug reports start coming in, the project should have a streamlined process to review the findings, and at least one person on the project should be tasked with responding to bug reports, so that there’s accountability and clear responsibility. It’s good to explicitly document this responsibility and ensure coverage for reviewing the reports in case a main point of contact is not available.
• At least one person on the project should be tasked with actively maintaining the bounty program. When new project repos go live, this person should be communicating with Immunefi to get them listed as assets in scope.
• Responses to bug reports should be fast, detailed, and provide an honest assessment of the severity of the bug. A project may want to downplay the severity, but this is unethical behavior. Remember, whitehats are saving projects — and their users — from devastating losses. They should be rewarded appropriately and enthusiastically.
• If a project already knows of an issue and either intends to fix it or hasn’t bothered to fix it, they must disclose this in their bug bounty program in advance. Otherwise, the project appears as though they’re trying to avoid rightfully paying out a bounty to the whitehat, which decreases the project’s reputation.
• Most importantly, the response should be fair. If a project fixes a vulnerability, they should pay — not try to argue that it’s out of scope or doesn’t deserve to be paid. That’s bad faith behavior.

With a well-managed bug bounty program, a project can not only build a mutually beneficial relationship with security researchers, but also build trust with their users. It shows that the team is serious about the ongoing safety of the project, and adds a good vibe to the community.

Sometimes, however, there are disagreements about the validity of a vulnerability, in which case, if a project doesn’t believe a bug report constitutes a real vulnerability and doesn’t want to pay, the whitehat is free to publicly disclose the report. We believe transparency is the best policy.

In line with transparency, Immunefi will soon release a leaderboard of blockchain projects that are running the most successful and ethical bug bounty programs.

Neglect at Your Own Peril

A protocol that does not take its bug bounty program seriously endangers its own users, as well as those of other protocols. Since the DeFi space is so closely entwined, any protocol that leaves itself open to attack also affects others.

And a protocol that acts unethically will quickly start to lose trust with its users, and whitehats may either refuse to report future vulnerabilities or take matters into their own hands. This is a bad outcome for everyone, and exactly what we are trying to avoid with bug bounties in the first place.