How to become a smart contract auditor

December 07, 2025

Updated for 2025

This article is a 2025 personal extension of How to become a smart contract auditor by cmichel. The original article remains an excellent resource, and this version builds upon it with updated protocols, tools, and EIP standards relevant to the current landscape.

— link

From time to time, I receive messages asking me for advice on how to get started as a smart contract security auditor. While there are already articles written about this topic, most of them are just a collection of security-related articles which they throw at beginners, overwhelming them. I’ll provide a path that I would take if I had to do it all over again. This will be ETH specific (or more general EVM-specific) as most auditing work is currently still in this ecosystem, although the landscape is rapidly expanding to new chains and Layer 2 solutions.

At the end, I’ll also go over frequently asked questions that are related to auditing and getting your first job.

Learn programming

I expect that you already know how to code, any language is fine. If not, learning how to code should be your first step as auditing code requires being able to read it. In my opinion, being a developer is a prerequisite, otherwise, you’re spending too much time trying to make sense of the syntax and the semantics of the individual instructions. It’d be like trying to read Nietzsche while being illiterate. Become literate first. This is definitely the step that takes the most time to learn, learning the security aspects happens a lot faster.

If you have no prior programming experience, be mentally prepared that it’ll take you years before your reviews will be useful. I’d start with JavaScript or TypeScript, they’re the most beginner-friendly and versatile languages. If it turns out you don’t actually like being an auditor, the transition to being a frontend, backend or smart contract developer is easy. The syntax of Solidity and JavaScript are also somewhat similar.

In 2025, Rust has become increasingly important. With Solana’s continued growth, the rise of Cosmos ecosystem chains, and new chains like Fuel and Movement Labs using Rust-based smart contract languages, being proficient in Rust opens up a massive amount of auditing work. If you’re serious about long-term career growth, investing time in Rust is no longer optional.

Learn ETH blockchain & Solidity basics

So you know how to code now but don’t know anything about Ethereum and Solidity yet. The quickest way to learn a new language is by using it in practice, by writing code in it - reading only the docs does not make the knowledge stick (and for some reason, even after all these years I still find the Solidity docs confusing and unstructured). There’s no better way to combine learning Solidity with learning about ETH security than solving CTFs.

CTFs (Capture The Flags / War games) are security challenges where vulnerable code is presented and you need to write a smart contract to exploit the vulnerability. These are the CTFs I recommend:

The Ethernaut challenges sometimes overlap with older vulnerabilities that only apply to old Solidity versions. You won’t see them in modern code anymore; be aware of that.

In 2025, I recommend using Foundry as your development framework from day one. It has become the industry standard and you’ll use it in every audit. Use forge test to solve these challenges locally with a forked mainnet environment. The fast feedback loop will accelerate your learning significantly.

There are also more advanced CTFs that are great for showcasing your skills:

  • Curta - Ongoing puzzle competition with on-chain verification
  • Secureum RACE - Timed quizzes that test deep EVM knowledge

Scoring well in these shows that you know what you’re doing and they are great for getting noticed by auditing firms or solo auditors looking for collaborators.

Become familiar with the most used smart contracts

There are certain contracts, patterns or even algorithms that you will see over and over again during your auditing career. It’s good to become familiar with them and deeply understand how they work and their nuances.

  • Token contracts: The most used token standards are ERC-20 for fungible tokens, ERC-721 for NFTs, and increasingly ERC-1155 for multi-token contracts. It’s important to understand that the original ERC-20 standard evolved a lot and there are tokens that do not comply with the final EIP-20 (most notably USDT), which does not return a success boolean among other issues. You should also understand that tokens can have different decimals and they’re to be interpreted as a floating-point number with the decimals precision, i.e., 1e18 TOKENS (= 10**18 TOKENS) ~ 1.0 TOKENS for a token with 18 decimals. You’ll encounter a lot of bugs where some computed token amount is in the wrong number of decimals.

  • Proxies: Ethereum contracts are not upgradeable. If you want to update the code, you need to deploy a new contract. However, that means that the storage which still resides in the original contract is also lost. Thus proxies implement the idea to separate the storage from the logic. There are many different proxy implementations, have a look at the OpenZeppelin Proxy documentation. You should understand how delegatecall is essential for building proxies, and be aware of the UUPS vs Transparent proxy patterns.

  • Staking and reward distribution: The classic MasterChef algorithm is still the foundation. Paradigm calls it the Billion-dollar algorithm. You should understand how it works and why it’s needed in a blockchain setting (cannot update all users at the same time). This pattern appears everywhere in staking, liquid staking (Lido, Rocket Pool), and restaking protocols (EigenLayer, Symbiotic).

  • Lending protocols: Aave V3 and Compound V3 are the current standards. The older Compound V2 code is still worth studying for its clarity, but V3 introduces isolated pools and a comet architecture. Morpho and Euler V2 represent the next generation of modular lending. Understanding interest rate models, liquidation mechanics, and oracle integrations is essential.

  • AMMs and DEXs: While Uniswap V2 is still the best starting point for understanding the x * y = k constant product formula, you must also understand:

  • Cross-chain and bridges: In 2025, cross-chain protocols are everywhere. Understanding LayerZero, Wormhole, and Chainlink CCIP is increasingly important. Bridge exploits have been some of the largest in history, making this a high-stakes area.

  • Restaking and AVS: EigenLayer has created an entirely new primitive. Understanding how restaking, operators, and actively validated services (AVS) work is essential for auditing the growing ecosystem built on top of it.

  • Intents and solver networks: Protocols like CoW Swap and UniswapX use intent-based architectures with off-chain solvers. This is a major shift in how transactions are processed.

Important EIP Standards

Beyond the basic token standards, there are many newer EIPs in 2025 that are worth studying in depth. Understanding these standards is crucial for auditing modern protocols:

Token Extension Standards:

  • ERC-2612 - Permit: Enables gasless ERC-20 approvals via signatures. Watch for signature replay and deadline handling issues during audits.
  • ERC-4626 - Tokenized Vault Standard: Unified interface for yield-bearing vaults in DeFi. This is one of the most common standards in 2025. Understanding share calculations, inflation attacks, and rounding issues is essential.
  • ERC-6909 - Minimal Multi-Token Interface: A lighter alternative to ERC-1155, used by protocols like Uniswap V4.
  • ERC-7540 - Asynchronous ERC-4626 Vaults: Supports async deposits and redemptions, used for RWAs and assets requiring settlement time.

Account Abstraction:

  • ERC-4337 - Account Abstraction: Smart contract wallets via UserOperations and Bundlers. Understanding EntryPoint, Paymaster, and validation logic is key for auditing wallet infrastructure.
  • ERC-6900 - Modular Smart Accounts: Defines plugin architecture for smart accounts. Increasingly important as modular accounts gain adoption.
  • ERC-7579 - Minimal Modular Smart Accounts: Another modular account standard, competing with ERC-6900, adopted by Safe and others.

Access Control & Storage:

  • ERC-7201 - Namespaced Storage Layout: Defines storage locations for proxy contracts to avoid storage collisions. Widely used in new OpenZeppelin contracts.
  • ERC-7546 - Upgradeable Clones: Combines the low gas cost of Clones with upgradeability.

Oracles & Data:

  • ERC-7412 - On-Demand Off-Chain Data Retrieval: Allows contracts to request off-chain data, popularized by Synthetix V3.

Protocol-Level EIPs:

  • EIP-1559 - Fee Market: Understanding base fee and priority fee is crucial for analyzing MEV and transaction ordering.
  • EIP-4844 - Blob Transactions: Introduced in the Dencun upgrade. Understand how L2s use blobs for data availability.
  • EIP-7702 - Set EOA Account Code: Coming in the Pectra upgrade, allows EOAs to temporarily have smart contract functionality.

The best way to learn these standards is by reading reference implementations from OpenZeppelin, Solady, and Solmate, and reviewing audit reports for protocols that use them.

Learn the finance basics

There will be a time when you’re auditing a DeFi project that uses a lot of traditional finance terms and you don’t understand anything. When you look these terms up, you’ll get definitions that refer to even more terms that you don’t know. I, therefore, found it really helpful to go through a basic finance course that does not assume anything and actually explains the intent of why one would use this specific financial instrument.

I recommend Khan Academy’s Options, swaps, futures, MBSs, CDOs, and other derivatives chapter where you’ll learn the terminology of options, shorting, futures (~perpetual contracts). From there, you can further expand and go deeper into the individual topics.

For DeFi-specific concepts in 2025, you should also understand:

  • Perpetual DEXs (GMX, Hyperliquid, dYdX V4) and funding rates
  • Liquid staking derivatives (stETH, rETH) and their rebasing mechanics
  • Points and airdrop farming mechanics (as they create unique economic attack vectors)

Getting real experience

At this point, your training is over and you’ll just keep reading more code and exploit post mortems to get better. Whenever the theory part gets too boring, you should try finding issues in real code. The great advantage here is that they are permissionless. You can be anonymous, there’s no need to pass a job interview, the payouts are purely skill-based.

Competitive audit platforms:

  • Code4rena - The original competitive audit platform, great for beginners
  • Sherlock - Offers coverage-backed audits with different judging mechanics
  • Cantina - Run by Spearbit, attracts high-quality codebases
  • CodeHawks - Cyfrin’s platform with good educational resources
  • Hats Finance - Decentralized security marketplace

Bug bounties:

  • Immunefi - The largest Web3 bug bounty platform with payouts up to millions for critical vulnerabilities

Receiving an actual bug bounty is a great addition in case you want to apply to auditing firms. Reading the final audit reports after each contest ends is the fastest way to learn, even if you didn’t find the bugs yourself.

FAQ

Here are answers to frequently asked questions about auditing.

How do you stay up-to-date with security?

Be on Twitter/X for real-time notifications of hacks and vulnerabilities. Subscribe to newsletters and feeds:

  • Rekt News - Post-mortems of major exploits
  • BlockThreat Newsletter - Weekly security aggregation
  • Solodit - Searchable database of audit findings
  • Follow security researchers on Twitter/X and study their threads when exploits happen

What’s the compensation?

Hourly rates for auditors vary widely based on experience and reputation:

  • Junior: $100-150/h
  • Experienced: $150-350/h
  • Top Auditors: $350-1000+/h

I’d categorize compensation into two categories:

  1. Fixed: You get paid a fixed (hourly) salary for your work at an auditing firm
  2. Skill-based: The more or higher-severity bugs you find, the bigger your compensation (contest platforms, bug bounties)

If you are a junior, I’d recommend joining an auditing firm or doing lots of contests to build skills. If you’re on the other side of the bell curve, it’ll be more lucrative to seek opportunities with the skill-based compensation model. Note that top bug bounty hunters can earn much more with payouts in the millions for critical vulnerabilities.

How long does it take to review a codebase?

Scoping audits is always a tough task and in my opinion, you only get better at it with experience. But to give a rule of thumb: Let’s say you can audit 150-200 lines of code per hour (adjust that parameter down if the code is complex, math-heavy, or if the documentation is bad). You then take the lines of code and divide it by your LOC/h rate to get the hours required for a single person.

If you’re an independent auditor you should also add 5h-10h for compiling the report and all the biz-dev work, plus answering questions. For complex protocols with novel mechanisms, double or triple your estimate.

How do you know when to stop looking for bugs?

That’s a good question. I could always spend more time on the code and it would increase the likelihood of me finding bugs. But at some point, there’s the point of diminishing returns, where it’s not reasonable to spend any more time on the code.

A good heuristic: set yourself the goal of fully understanding the system to the point where you could reimplement it from scratch without being allowed a look at the original codebase. Not from remembering the code, but from having understood what the application is supposed to do. If you have examined a project that far and have not found a bug, the chances of finding one by continuing is low.

Realistically, I often stop before reaching that point due to time constraints and opportunity costs when I think my limited time is better spent elsewhere.

Can you be an auditor but not a developer?

In my opinion, auditors’ and developers’ skills mostly overlap. I’d even say being an auditor has made me a better developer. You’ve probably heard of this myth of a 10x engineer but it’s just someone who has worked on a lot of similar projects before and can copy-paste from their previous work such that assembling a new protocol happens a lot quicker compared to someone with no prior code to draw upon. I’ve probably seen hundreds of Solidity codebases by now and know exactly where to look and copy code from if I had to build a new protocol.

On the other side, a protocol dev knows more about areas like proper deployments, managing the day-to-day on-chain tasks, monitoring, etc. They also have better muscle memory for the syntax from actually typing out the code whereas auditors are mostly reading it.

What tools do you use when auditing?

The tooling landscape has evolved significantly. In 2025, a modern auditor’s toolkit includes:

IDEs and extensions:

  • VSCode with “Solidity Visual Developer” extension - highlights storage variables and function parameters
  • “Solidity Metrics” for complexity analysis
  • Cursor or other AI-assisted editors for faster code navigation

Testing and fuzzing:

  • Foundry - Industry standard for testing, fuzzing with forge test
  • Echidna - Property-based fuzzing
  • Medusa - Parallel fuzzer for deeper coverage

Static analysis:

  • Slither - Fast static analysis for common vulnerabilities
  • Aderyn - Rust-based static analyzer

Formal verification (for high-stakes code):

  • Certora - Industry leader in formal verification
  • Halmos - Symbolic testing for Foundry

I still believe the most important tool is your brain and taking good notes. The @audit, @audit-info, @audit-ok, @audit-issue markers from Solidity Visual Developer are invaluable for organizing your thoughts.

What makes a good auditor?

Besides the technical skills like knowing many types of exploits, knowing the EVM well, or having seen issues of similar protocols, a personality trait that I think is useful: conscientiousness - I feel like some auditors don’t even try to find all bugs and just want to be done with their job as quickly as possible. This is more likely to happen if the incentives are not aligned and you get paid a fixed salary as is often the case with traditional auditing firms. So you want to hire people that are conscientious, who take their job seriously and take pride in their work.

Curiosity is another key trait. The best auditors are genuinely curious about how systems work and break. They go down rabbit holes, question assumptions, and never accept something at face value.

Do I need to know math?

I see more and more math-heavy DeFi protocols, so being good at math is definitely a plus. Areas where math is particularly important:

  • AMM invariants and curve mathematics
  • Interest rate models
  • Oracle price manipulation calculations
  • Options pricing (Black-Scholes, etc.)
  • Fixed-point arithmetic and precision loss

You don’t need a PhD, but comfort with algebra, basic calculus, and the ability to reason about numerical edge cases is essential.

What does your auditing process look like?

My auditing process is pretty straightforward:

  1. Read the documentation - Understand what the protocol is supposed to do
  2. Draw architecture diagrams - Map out the contract relationships
  3. Read the code systematically - Order contracts logically (base classes first, then derived)
  4. Take heavy notes - Use @audit, @audit-info, @audit-ok, @audit-issue markers
  5. Write tests - For anything suspicious, write a PoC in Foundry
  6. Revisit notes - Resolve any loose ends or things I didn’t understand earlier
  7. Create the audit report - Transform notes into a structured report

I don’t rely heavily on automated tools for finding bugs, but I use them for quick sanity checks and to make sure I’m not missing obvious low-hanging fruit.

Can you easily audit projects on other blockchains? Are newer chains more secure?

The blockchain landscape in 2025 is much more diverse than it was a few years ago. Here’s my take:

Solana/Rust-based chains: The Rust learning curve is steep. The non-conventional account model needs time getting used to. However, the safety guarantees that Rust gives you do catch some low-hanging bugs. Major Solana exploits still happen regularly though.

Move-based chains (Aptos, Sui): The Move language has strong resource-oriented safety guarantees, but economic bugs and logic errors remain.

L2s and rollups: Most L2s use the EVM, so your Solidity skills transfer directly. However, understanding the specific L2’s trust assumptions, sequencer behavior, and bridging mechanics is crucial.

Some reasons why ETH mainnet still sees many exploits:

  1. The most innovative and complex protocols are often on ETH first
  2. The cross-contract function invocation model is great for re-entrancy bugs
  3. No built-in contract upgradeability leads to complicated proxy patterns
  4. ETH’s open-source culture is much stronger than on any other chain
  5. ETH is still where the majority of TVL is, which attracts more attackers

The bigger hurdle to auditing a new chain is understanding how the blockchain works and the security implications - this information is often scattered across docs, blog posts, and Discord channels. But if you have strong fundamentals, you can pick up a new chain in a few weeks.