In Web2 bug bounty you send a request and read the response. In Web3 the entire source code is sitting in front of you, everything is public, and protocols still lose millions. That is the difference: most Web3 bugs are not implementation mistakes, they are logic and assumption mistakes.
This roadmap is the path most Web3 hunters actually walk: fundamentals, then Solidity, then the vulnerability classes that pay, then tooling, then real programs. No shortcuts, but no filler either.
Who this is for
- You can read code and want to move from Web2 bounties into Web3
- You are a developer who wants to audit instead of ship
- You are starting from zero and want an order to learn things in
If you have never seen a transaction on a block explorer, start at Phase 1 and do not skip it.
The short version
Web3 basics
-> Ethereum and EVM
-> Solidity
-> Smart contract vulnerability classes
-> DeFi mechanics
-> Foundry
-> Static analysis
-> Manual code review
-> Fuzzing and invariants
-> Public audit reports
-> CTFs and labs
-> Bounty programs
-> PoC
-> Report
Phase 1: Web3 fundamentals
| Topic | What to actually understand |
|---|
| Blockchain | Blocks, state, finality |
| Bitcoin vs Ethereum | UTXO vs account model |
| Wallets and keys | Private key, seed phrase, signatures |
| Transactions | Nonce, gas, calldata, revert |
| Tokens | ERC-20, ERC-721, ERC-1155 |
| Ecosystem | DeFi, DEX, DAO, NFT, oracles, bridges, L1 and L2 |
Checkpoint: open any random transaction on Etherscan and explain, in your own words, which contract was called, which function ran, what state changed and which events fired. If you cannot do this yet, you are not ready for Phase 2.
Phase 2: Ethereum and the EVM
You do not need to write assembly, but you do need the mental model.
- EOAs vs contract accounts
- Storage, memory, calldata, stack
- Function selectors and the ABI
- Gas, opcodes, events
- Deployment, constructors, immutables
Wallet -> Transaction -> Contract -> Function -> State change -> Event
Tools for this phase: Etherscan, Remix, MetaMask, Foundry.
Phase 3: Solidity, read it before you write it
Your job as a hunter is reading, not shipping. Aim for fluency in:
- Visibility and modifiers
- Mappings, structs, arrays
- Inheritance, interfaces, libraries
- Payable functions and Ether transfers
- Custom errors and require checks
These globals decide most access control bugs:
msg.sender // direct caller
msg.value // ETH sent
msg.data // raw calldata
tx.origin // original EOA, almost never safe for auth
block.timestamp
block.number
address(this)
And know exactly how these differ:
| Call | Context | Common bug |
|---|
call | Callee context, returns bool | Unchecked return value, reentrancy |
delegatecall | Caller storage | Storage collision, proxy takeover |
staticcall | Read only | Unexpected revert on state change |
transfer / send | 2300 gas stipend | Fails with smart contract wallets |
Phase 4: Vulnerability classes that actually pay
Access control
Three questions per function: who can call it, who should call it, and what happens when someone else does.
Reentrancy
Contract -> External call -> Attacker contract -> fallback / receive -> Original function again
Four flavours, and the last two are where the money still is:
- Classic single function reentrancy
- Cross function reentrancy
- Cross contract reentrancy
- Read only reentrancy, where a view function returns a mid transaction state
Accounting and business logic
Never test a single function in isolation. Test the whole path:
Deposit -> Accrue -> Claim -> Withdraw
Signatures
Upgradeable contracts
User -> Proxy -> Implementation
Bridges and cross chain
Phase 5: DeFi mechanics, the real unlock
Most high severity Web3 findings are DeFi findings. You cannot spot them without understanding the money flow.
Learn the mechanics of lending, borrowing, AMMs, liquidity pools, staking, liquidations, stablecoins and flash loans, then keep these seven variables in your head while reading any protocol:
price, liquidity, collateral, debt, shares, reserves, exchange rate
Oracles
Oracle price -> Collateral value -> Borrow limit -> Loan size
Flash loans
Borrow -> Manipulate -> Profit -> Repay, all in one transaction
A flash loan is rarely the bug. It is the amplifier for a bug in price assumptions, reserve maths or share calculation.
Phase 6: Tooling
Foundry, your main weapon
forge init # new project
forge build # compile
forge test -vvvv # run with full traces
forge test --fork-url $RPC_URL # test against real mainnet state
cast call ... # read on chain data
anvil # local node
Fork testing is the single most useful skill here. You can reproduce an attack against live protocol state without touching the live protocol.
Static analysis
slither .
Slither, Aderyn, Mythril, Semgrep and Echidna will give you a shortlist. Every finding still needs manual verification, and tools will never find business logic bugs. Treat them as a filter, not as an oracle.
Phase 7: Manual review that finds things
Read contract by contract, function by function, and build this table as you go.
| Function | Who can call | State changed | External calls | Risk |
|---|
deposit() | Anyone | balances, totalSupply | token.transferFrom | Fee on transfer, accounting |
withdraw() | Depositor | balances | ETH transfer | Reentrancy, rounding |
liquidate() | Anyone | debt, collateral | Oracle, DEX | Price manipulation |
setOracle() | Owner | oracle | None | Access control |
When the table is complete you have a call flow map, and cross function bugs become visible instead of theoretical.
Phase 8: Fuzzing and invariants
Fixed value tests only prove the happy path.
// fixed
deposit(100);
// fuzzed
function testFuzz_deposit(uint256 amount) public { ... }
Then write invariants, conditions that must never break:
totalAssets >= totalLiabilities
totalSupply == sum(userBalances)
sum(shares) * pricePerShare <= totalAssets
A broken invariant is usually a real, reportable finding. Chase the root cause, not the failing input.
Phase 9: Learn from public reports
For every report you read, extract five things:
Root cause -> Attack path -> Exploit -> Impact -> Fix
Read Code4rena and Sherlock contest reports, Immunefi disclosures and audit firm PDFs. Do not memorise findings. Memorise the reasoning that led to them.
Phase 10: Programs, PoC and report
Platforms worth knowing: Immunefi, Code4rena, Sherlock, Cantina, HackenProof and HackerOne. Contests are better for learning because findings get judged and published. Bounties pay more but expect a polished submission.
Read the scope, the out of scope list, the severity definitions and the disclosure policy before you touch anything. Only test authorized targets, and never test against live user funds.
Proof of concept
Initial state -> Attack setup -> Exploit -> State change -> Impact
Keep it reproducible, minimal and runnable with one forge test command.
Report structure
Title
Severity
Summary
Root cause
Attack scenario
Proof of concept
Impact
Affected contract and function
Recommendation
Good title: Unauthorized withdrawal allows an attacker to drain user deposits
Weak title: Critical bug in contract
Severity in one question set
- Can an attacker steal funds?
- Can an attacker freeze funds?
- Can an attacker corrupt accounting?
- Can an attacker bypass authorization?
- Can an attacker take the protocol offline?
Every severity claim needs reproducible technical impact behind it. A theoretical path with no PoC gets downgraded or closed.
The 90 day plan
| Days | Focus | Output you should have |
|---|
| 1 to 15 | Web3 and EVM fundamentals | You can explain any transaction on a block explorer |
| 16 to 30 | Solidity and vulnerability classes | Notes on 15 vulnerability patterns with code examples |
| 31 to 45 | DeFi and oracles | A written breakdown of one lending protocol |
| 46 to 60 | Foundry, Slither, fork testing | Working exploit PoCs for 3 past hacks |
| 61 to 75 | Real code review | 5 to 10 protocols reviewed, findings written even if unsubmitted |
| 76 to 90 | Contests and bounties | First submission on a small scoped program |
Daily rhythm
| Time | Task |
|---|
| 1 hour | One vulnerability class |
| 1 hour | One real audit finding |
| 2 hours | Review live contract code |
| 1 hour | Write Foundry tests |
| 1 hour | CTF or authorized lab |
| 30 min | Notes |
Learn -> Read -> Code -> Break -> Explain
If you cannot explain it, you have not learned it yet.
Setup checklist
The one skill that matters
Tools are not the skill. Protocol understanding is.
For every function, trace the full path:
Input -> Validation -> Calculation -> State change -> External call -> Output
And for every protocol, ask one question:
What assumption is this protocol making, and what happens the moment that assumption becomes false?
Every large Web3 hack is that question, answered by someone else first.
Free live session on Web3 security
Techonquer is hosting a free live podcast on Web3 security with Web3 security researcher and bug hunter Manish Singh, covering real world vulnerabilities, smart contract security, AI in security research and how beginners can enter the field, followed by a live Q and A.
Do not just learn how smart contracts work. Learn how they fail.
