How to Become a Smart Contract Auditor

Most people who ask how to become a smart contract auditor want to skip straight to audit contests. The fastest route goes the other way: build first, then understand, then attack.

The steps below are simple, but they are not easy. They only work with an unreasonable amount of effort over an unreasonable amount of time.

Time is the key ingredient. None of the steps matter without it.

The Roadmap at a Glance

1. Build something. Write a lot of Solidity and design your own protocols.
2. Learn the DeFi primitives. DEXes, vaults, lending and staking.
3. Read and understand codebases. Quickly, and at a deep level.
4. Build your vulnerability toolbox. Learn the bug classes and how to apply them.
5. Audit like crazy. Contests and reviews, for hundreds of hours.
6. Build a personal brand. Publish your findings and share what you learn.

Progress is not linear. Every day builds on every day before it, so the curve bends upward the longer you stay with it.

1. Build Something First

Too many people want to become auditors before they have been developers. Sit on the other side of the table first.

Skip the building phase and you skip the intuition for what a well-designed smart contract looks like. That intuition is what lets you spot pitfalls in someone else's design.

It shows you where something is weird, or where the code could have been much simpler. That is usually where the bugs are.

Over time you develop code smells: a sixth sense that zeroes in on a spot and says something is not right here. Sometimes you recognize a bug because you made the same mistake yourself.

A lesson in parallel data structures

Guardian's founder learned this the hard way on his first DeFi protocol. It kept a mapping from address to a request struct, plus a list of the same request structs.

The list and the mapping pointed to the same data in different ways. They fell out of sync, and the result was a critical bug: users could not withdraw their funds.

The funds were saved and returned to users. The lesson stuck: whenever two storage variables track the same state in different ways, alarm bells should go off.

That one memory has since led to a good number of high and critical findings in other codebases.

What to build

Start simple, then add features and complexity until you are comfortable with the language.

• A faucet contract. Get the basics down.
• Meta transactions. Add them to the faucet so users can claim without paying gas.
• Something you care about. An optimizer vault or an NFT exchange. Interest carries you over the learning curve.
• Your own DeFi protocols. A lending and borrowing protocol, perpetuals or an optimizer vault, inspired by the leading codebases of each type.

Only when you implement these yourself do you hit the niche issues each type of protocol has.

You also learn the common design patterns and the common vulnerabilities to guard against.

For the habits worth building early, see Solidity security best practices.

2. Learn the DeFi Primitives

With Solidity in hand, dive into popular DeFi protocols and learn the basic building blocks. Aim to master, or at least know, every major kind of DeFi application:

• DEXes such as Uniswap, Balancer and Curve
• Autocompounder vaults such as Yearn and Beefy
• Lending protocols such as Compound and Aave
• Staking

One hack: use the protocols you are learning about, and even put money in them. This is not financial advice, and you may lose some.

Having a stake turbocharges your understanding and gives you the motivation to keep learning. Good starting points are constant product AMMs and Uniswap V3 concentrated liquidity.

3. Read and Understand Codebases

Train the muscle of reading a codebase quickly and at a deep level.

The faster and deeper you go, the more exploits you will uncover, and the more interesting they will be.

Get your hands on as many codebases as you can and devour them:

• Trace what a normal user interaction looks like as it flows through each function and contract.
• Work out the purpose of every function.
• Ask why a line is written the way it is, or why a function does not just do the work itself.

This is probably 95% of manual analysis. Any bug worth something in a contest has to do with the details of one specific protocol.

When you practice, do not hunt for bugs at all.

Open a new codebase, reach a high-level understanding as fast as possible, then learn the intimate details of the implementation, strictly for understanding.

4. Build Your Vulnerability Toolbox

Design sense plus fast, deep reading is a strong base. Now add sheer knowledge of exploits and bug classes, and you have the trifecta of a manual reviewer.

Learn every type of reentrancy, denial of service attacks, flash loans, gas griefing, front-running and oracle manipulation.

The list goes on: 22 vulnerabilities to check first is a good place to start.

The toolbox is what you reach into while reading. You see a line that makes an external call, and you have questions about gas griefing, denial of service and reentrancy.

Leave a note there and come back to it.

Use the tools, do not just throw them

This is not pattern matching. Many researchers copy findings from reports and paste them at a new codebase to see what sticks.

Do not throw a hammer at the nail. Pick it up and use it the way it is meant to be used.

Take an idea like denial of service and work out how it applies to this codebase in a new way. Security review is not memorizing findings.

It is combining intimate knowledge of the codebase with your toolbox to find unexpected behavior that causes significant damage.

Read reports the right way

Reading reports from top solo auditors and firms is the classic way to build the toolbox. Look for what similar findings have in common.

Then go a step further. Open the codebase at the line numbers a finding cites and read until you understand exactly why it was valid.

Then work out why it was ranked at its severity. Once you know both, you have fully understood the finding. Severity is covered in smart contract audit severity levels.

Useful material includes collections of CTFs, videos and audit reports, past Secureum races in quiz form, a corpus of Code4rena findings and Guardian's public audit reports.

Reports have diminishing returns, though. Do not spend months reading and preparing.

Learning vulnerabilities never really ends, but after a few dozen hours, start auditing.

5. Audit Like Crazy

Once you have read a first handful of reports and have a working grasp of the fundamental bug classes, go all out. Dive into audits.

Guardian's founder spent little time reading reports before auditing. He then put in a thousand hours of auditing before looking up, and by then he was already decent.

Your first contest may overwhelm you with the size of the codebase.

Pick a smaller one first, and once you can handle it, move to something more complicated with more, and more interesting, bugs.

Your capacity for large codebases grows along the way. Go back to a small one later and it feels easy.

At first it will feel like an uphill battle, and you may think you are bad at it. Of course you are: you just started. That is temporary, and it says nothing about who you are.

Nobody rides a bicycle on the first try, and auditing is a lot harder than riding a bike. It takes a lot of effort before it becomes effortless.

What the hours look like

A thousand hours is five hours a day for 200 days. For most dedicated people, that takes around a year.

For a structured method once you start, see how to audit a smart contract.

6. Build a Personal Brand

Once you are competing in contests and doing private audits, build a corpus of portfolio work.

A strong portfolio of past findings and audits makes you stand out.

• Private audits: ask the client if you can release the report.
• Audit contests: wait for the contest report, then compile and publish a report of your own findings.
• Share what you learn: found a cool new exploit? Write a thread about it. Someone else may be looking into something similar, and you can learn from them.

Set Expectations on Time

Guardian's founder needed at least six months before he felt he had a handle on security reviews.

After the first year there was only a little momentum; two years in, it kept getting easier.

Nothing happens within a few weeks. After six months you have some experience, after a year some momentum, and after that it compounds.

Stick with it, and remember that today builds on every day before it.

Security Research at Guardian

Guardian hires full-time security researchers at several levels, from GSR-1 researchers who conduct manual analysis with guidance from senior teammates to fully autonomous reviewers.

If you have put in the hours, see the open roles on Guardian's careers page.

Frequently Asked Questions

How long does it take to become a smart contract auditor?

Plan on about 1,000 hours of auditing before you have a real handle on it. That is five hours a day for 200 days, or around a year for a dedicated person.

Should I learn Solidity before I start auditing?

Yes. Writing your own contracts and DeFi protocols builds the design intuition, or code smells, that point you to bugs in other codebases. Without it you cannot zero in on the parts of a design that are off.

Is reading audit reports enough to learn auditing?

No. Reports help you build a toolbox, especially when you open the code at each finding's line numbers. They have diminishing returns, so after a first handful, move on to auditing and learn by doing.

How do new auditors build a portfolio?

Compete in audit contests and publish a report of your own findings once the contest report is out. For private audits, ask the client if you can release the report. Share new exploits you learn about with the community.

Sources

• Owen Thurm (YouTube): 4 Steps To Become A Master Security Researcher (October 2023)
• Owen Thurm (YouTube): The 4 Step Auditor's Roadmap (March 2023)
• GitHub: GuardianAudits/Audits, Guardian's public audit reports