I’m Robert Forster, and if you’re reading this to start your blockchain bounty hunting career, I’m extremely jealous of you. There’s absolutely no better time to be getting into this industry. I’m currently the director of the decentralized coverage protocol Armor, but I previously lived off bounty hunting while working on other projects. The lifestyle it could provide even two years ago, however, is much, much different from today.

I wouldn’t be surprised if the amount of bug bounty rewards in the ecosystem totalled under $1M at that time. Just the other day, a single protocol posted a $10M bounty.

That being said, I still absolutely loved it. There’s something so alluring and addictive about the hunt. With 2 hours of hunting you can make multiple months of salary; hell, nowadays in Web3 you can retire off of a single bug discovery. It’s a treasure hunt in which you’re not only finding gold and jewels but simultaneously being a damn superhero by protecting the users. Not to mention, of course, that it’s quite the adrenaline rush when you find a bug in a live contract holding millions of dollars (or more), and you’re the only person in the world to know about it.

Skills Needed

You don’t need to be a genius hacker to do bug bounties. I started doing bug bounties at nearly the same time I started coding Solidity. The difference between then and now is simply my expectation of finding bugs. Back then, my primary reason for bug bounties was to learn by reading someone else’s code, with the added bonus of potentially making a few bucks. As you gain experience, however, you can really start looking at bug bounties as a way to make money. What should you learn to get to that point, though?

One of the most important areas to study is past vulnerabilities. Consume everything you can find on executed hacks and discovered bounties, and learn what scenarios they can happen in. Flash loan attacks, malleable signatures, improper initialization, re-entrancy, bad randomization, etc. are all bugs that continue to be found today. The more you learn about the past, the more you know what to look for in the present.

In the same vein, if a new type of vulnerability is found, there’s a sort of gold rush that begins for hackers. They start checking contracts that were audited before the vulnerability was on the top of developers’ and auditors’ minds. You can see this with many notable hacks in the past that then spawned a string of “copycats.” Keep up with the news and take advantage of this! The blackhats sure do.

Another area of important learning is to keep up-to-date on as many protocols in the ecosystem as possible. The composability of contracts means two individual contracts may not be vulnerable, but, when combined, misbehavior in one can lead to a vulnerability in the other. Many hacks in the past have occurred because of composability. Hell, Armor paid out $15,000 for a bug that came about as a result of a protocol we built on top of updating their contracts, which led to our contract not functioning as intended.

Finding a Bounty

Each hunter may have different reasons for hunting. I’ve done some hunting just because the protocol had similar functionality to one I was writing, and I wanted to learn how they chose to do it, while also having the chance to make some cash. Some people may only have a few hours to spend and want to have the best chance at finding a bug within that time. Some may be bounty hunting as a job and have the time to dive much deeper into the hunt. Keep in mind who you are, and function based off of that.

If simply making some cash is the main motivator and you must pick and choose which bounties to work on, there are many clues you can use to spend your time wisely. How clean is the code? Are best practices being followed? Do they use notoriously vulnerable functionality? Are there verified audits? When you run tests, are there warnings that the developer didn’t bother to fix? Are the tests lacking in coverage? What’s their DefiSafety rating? Even the smallest details such as typos in comments can hint at a lack of attention to detail, which could possibly mean bugs.

I was immediately a little suspicious when looking at a certain contract because there were no comments in the code and gas optimizations were not being followed. Another contract I looked deeper into because there were complications in the code that could’ve been made much more elegant, hinting at a possibly inexperienced developer. A third had large sections of code commented out rather than deleted, which looked dirty and made me think there may be some dirty functionality as well. All of those had high-critical bugs in them.

That being said, never make assumptions as to whether code is safe. The most beautiful code can have the simplest mistakes. The code that’s been around the longest or has the most amount of money in it could have easily been written off by others long before new vulnerabilities were discovered that it falls prey to. Maybe a piece of code that technically functions perfectly wasn’t initialized correctly. There’s always a chance that code has a bug in it, and, given the value of bounties in large protocols nowadays, the code that other hunters have assumed is safe may be the most lucrative.

Reading Documentation

Read it. All. Just do it. I know, you want to jump right in. Don’t. The documentation, all comments, anything you can read about the protocol not only helps immensely in being able to learn how the code should work and spot anything working in an unintended manner, but also shows you exactly where to focus your hunt. The bit of time spent here will be more than made up later.

I received a $25,000 bounty at one point when I was mostly just examining a contract to explore how other developers were implementing certain functionality, but I saw a comment mentioning certain protection was in place to stop users from getting extra rewards, so I checked for–and found–ways to bypass that protection.

The Hunt

To start hunting, you first must determine where the critical aspects of the code are. Since you’ve already read every piece of documentation there is, this should not be difficult. Critical aspects may be a point in which users are paid out, the counting of votes in a governance contract, or privileged functionality that gives exceptional power over the contract. Once you know where to begin your hunt, you can get to hunting.

It is certainly helpful to use security analysis tools such as Mythril in your bounty hunting, especially given the ease-of-use. Sometimes the simplest of bugs make it through audits, and sometimes the software may point you in the right direction toward something more serious. Writing your own analysis software may be very helpful as well to potentially give you advantages other hunters may not have and allow you to update analysis immediately to search for patterns related to new vulnerabilities being popularized. If the code being examined does not have adequate unit test coverage, adding tests is also a very good place to start. That being said, the majority of my hunting was manual and that’s often how the biggest bugs are found, so just jump right in if that’s how you feel like working.

My preferred way of manually looking for a bug is to work backwards. We’ve determined the critical aspects of a contract, so the best place to start is there. If you’re looking at an auction contract and there’s a section where it returns funds to users after being outbid, is there a way to make it return more funds than a user’s balance? No? Is there a way to make the user’s balance higher than what was deposited? No? Is there a way to make the amount deposited be read incorrectly? No? Okay, expand into other problems there could be. Is there a way to make the transaction fail when it returns funds so that no one can bid above you? No? Is there a way to make it so that when it returns funds you immediately call back into the contract and outbid the person who put a bid above you? Yes? Great.

There’s some alpha for you hackers if you can find the right contract. I forgot to report it.

If you think you’ve found something, test it. Spin up a mainnet fork and test it out on Hardhat or whatever you use. Information on the best testing environments is located in a more boring article. There will be many circumstances where something seems vulnerable but weird functionality elsewhere prevents an exploit, so tests to confirm the vulnerability will always be required.

Conclusion

The goal of this article was to help beginners learn ways to start on their whitehat blockchain hacking journey. Hopefully you didn’t read this far thinking I’d start spewing some genius technical blabber. If so, I’m sorry. There are lots of people more suited for that than me. But hopefully you’re someone interested in exploring this world, and now know a little bit more. And hopefully you’re stoked to get started because bug bounties are awesome and they’ll make you rich and famous.