How to Start Web3 Bug Hunting in 2026 (Ethical Path Only)

How to Start Web3 Bug Hunting in 2026 (Ethical Path Only)

How to start web3 bug hunting in 2026 is not about spraying mainnet with exploits. It is about reading written scope, practising on local forks and public CTFs, and filing professional reports through authorized platforms. This Andrax tutorial — by Syed Zada Abrar — is the ethical entry point for absolute beginners who want a real path into smart-contract security research.

No malware. No unauthorized drains. No live-mainnet abuse. If that fence is a problem, this series is not for you.

Who this tutorial is for (and who it is not)

Absolute beginners welcome

You do not need a security job title to start. You do need patience, basic programming comfort (or willingness to build it), and a bias toward reading before poking. Useful backgrounds include:

• Developers who know some Solidity, JavaScript, or another typed language and want to pivot into audits/bounties
• Web2 bug bounty hunters who already understand reports, severity, and triage — but not yet EVM economics
• Students who have finished (or are finishing) a Solidity intro course and want a structured next step

You do not need prior Immunefi payouts, a private audit roster, or a paid bootcamp. You do need to treat every lab as authorized practice: local fork, official CTF, or written program scope.

What we will not teach (malware, unauthorized drains, mainnet abuse)

Andrax will not teach:

• How to build drainers, phishing kits, or wallet stealers
• How to attack protocols outside a written bounty / VDP / contest scope
• How to “test” PoCs against live user funds on mainnet or public testnets
• How to publish unpatched vulnerabilities for clout

Those topics are crime-adjacent or platform-ban material. Everything practical in this series stays on authorized bug bounty / responsible disclosure, local Foundry/Hardhat forks, public challenge contracts, or official program scope.

What “Web3 bug hunting” means in 2026

Smart contracts vs websites/apps on bounty programs

Most Web3 bounty pages split assets into categories. On Immunefi, severity is classified largely by impact, across blockchain/DLT, smart contracts, and websites/apps — see the Immunefi Vulnerability Severity Classification System v2.3. For beginners aiming at EVM protocols:

• Smart contracts — logic bugs (reentrancy, access control, oracle/accounting errors, proxy/storage mistakes). PoCs are usually Foundry or Hardhat tests on a local fork.
• Websites and apps — frontends, APIs, wallet-connected UIs. XSS or subdomain issues can still move funds if they trick a connected wallet. Rules and impacts differ from pure Solidity work.
• Blockchain / DLT — client or consensus-layer issues. Out of scope for this beginner track.

This series is EVM / smart-contract first. Frontend scope appears later only where a program lists it.

Contests vs ongoing bounties vs private audits (plain English)

Three common money paths — different skills and timelines:

Treat past contest write-ups as a study corpus, not as a license to re-attack those contracts live.

Hard ethics and legal fence

Authorized programs and written scope only

Your hunting surface is whatever a program writes down: assets, impacts, out-of-scope lists, PoC rules, KYC, disclosure policy. If it is not in writing, assume it is not authorized. When in doubt, do not touch production.

Local forks and CTFs — never “test” live user funds

Safe practice surfaces for this series:

1. Local forks — Anvil/Hardhat fork of a block; your PoC never hits public mempools
2. Public CTFs / challenges — Ethernaut, Damn Vulnerable DeFi, and similar educational contracts
3. Official contest codebases — downloaded repos from First Flights or similar, run locally

Never send exploit transactions to mainnet or a public testnet “just to confirm.”

Responsible disclosure and platform rules (Immunefi-style bans for mainnet testing)

Immunefi’s Rules state plainly that any testing with mainnet or public testnet contracts is grounds for an immediate and permanent ban. Their guide Why You Should Never Test Exploits on Mainnet or Public Testnets explains why: public chains broadcast your every move to bots and copycats, and you can damage live funds even when you “meant well.”

The same standard appears in Immunefi’s How to Submit Bug Reports That Get Paid: PoCs belong on a local network / mainnet fork, not mainnet or public testnet. That article also warns against AI-generated spam reports, spray-and-pray low-quality submissions, and severity misclassification — all ban/warn territory.

Read every program’s custom prohibited activities too. Scope pages often restate the local-fork rule and add project-specific bans (phishing, DoS, traffic-heavy automation).

The 2026 platform map (where beginners actually learn and earn)

Immunefi — ongoing bounties and impact-based severity

Immunefi remains the primary ongoing Web3 bug bounty marketplace for smart-contract and blockchain programs. Severity follows impact under IVS v2.3 (Critical → Low). Expect runnable local-fork PoCs, per-program KYC/scope quirks, and triage that cares about funds at risk now, not vibes.

HackenProof, Cantina, Sherlock — what each is good for

• HackenProof — hybrid crypto bounty + crowdsourced audit surface; many L1/L2, CEX, and wallet programs. Useful if you already have Web2/Web3 hybrid skills.
• Cantina (cantina.xyz redirects here) — curated bounties and large competitive reviews with Spearbit-network style triage. Stronger once you can read production codebases.
• Sherlock — collaborative audits, contests, and post-launch bounties in one lifecycle model. Contests and bounties are real targets later; day 1 is still skills + CTFs.

Pick one primary bounty home after you can finish CTFs without copying write-ups. Immunefi is the default teaching target for report craft in this series.

CodeHawks First Flights — beginner contests after CTFs

CodeHawks First Flights (Cyfrin) are smaller auditing challenges with XP/learning rewards rather than large cash pools. Docs describe them as the hands-on bridge after courses: real submission UX, judged findings, feedback, leaderboard XP. After Ethernaut / DVD comfort, First Flights are the natural next contest step — before staking reputation on high-stakes paid contests.

Code4rena and Hats — historical note (do not treat as primary submit targets)

• Code4rena — competitive audit platform that announced a wind-down around 13 May 2026 (The Coinformer; The Crypto Times on Immunefi’s migration partnership for bounty customers). Treat C4 as a historical report corpus, not a primary 2026 submit target.
• Hats Finance — centralized/custodial ops were reported to cease around 31 December 2025 (industry coverage of the Hats wind-down announcement). Do not recommend Hats as a primary hunt surface.

Platforms change. Always verify a site is still accepting submissions before you invest time.

Skills ladder (preview of this Andrax series)

Mindset → setup → Solidity reading → tools → vuln classes → DeFi → report → submit

This Day-1 piece is the ethics + orientation spoke. The rest of the Andrax Web3 path (hub + later spokes, published under /tutorials/) will climb roughly in this order:

1. Mindset & ethics — this article
2. Learning-path hub — ordered curriculum map (Day 2)
3. Wallet, RPC, explorers — read-only setup for hunters
4. Solidity reading — read first, write second
5. Verified / unverified contracts — how to actually inspect code
6. Foundry + Slither — compile, test, static triage
7. Vuln classes — reentrancy, access control, flash loans, oracles, proxies, EIP-712, ERC-4626, DeFi patterns
8. Report craft + submit workflow — Immunefi-aligned reports; platform mechanics
9. First real public-scope target — fork-only testing under written scope

Upcoming titles appear in the hub curriculum table as they ship.

How long this takes (honest ranges, no fake salary promises)

Honest, non-hype ranges for a motivated beginner studying several hours most days:

These are study calendars, not income forecasts. Payouts depend on skill, luck, program quality, and triage — and many excellent researchers go months without a valid critical. Anyone selling guaranteed salaries is selling something else.

Lab — Read a public bounty page like a hunter

Lab rule: open one public program page and fill the checklist below. Do not scan live contracts, send transactions, or run automated tools against the project. Reading is enough for Day 1.

Recommended page: the ENS bug bounty on Immunefi (Information) and its Scope tab. ENS is a long-running, well-documented program — ideal for practice reading.

Checklist: in-scope assets, impacts, out-of-scope, KYC, PoC rules

Copy this into your notes and fill it while reading ENS (or any other public Immunefi program):

1. Program identity — project name, live-since / last-updated dates, max bounty stated on the page
2. Asset categories — smart contracts? websites/apps? both?
3. Assets in scope — list or summarize contracts/URLs from the Scope tab (names/addresses as published — do not probe them)
4. Impacts in scope — Critical/High/Medium/Low impacts the program will pay for
5. Out of scope — known issues, exclusions, custom bans (ENS, for example, marks ens.dev out of scope and lists known NameWrapper issues)
6. PoC requirement — required for which severities? (ENS: PoC required for all severities)
7. KYC — required, not required, or reserved rights? (ENS: generally not required; may request if legally needed)
8. Testing rules — local-fork only? oracle/third-party testing bans? DoS / automation bans?
9. Disclosure / publication — responsible publication category if listed
10. Reward mechanics — flat vs % of funds at risk; any Primacy of Impact vs Primacy of Rules notes
11. Your one-sentence hunt thesis — “I would study X because impact Y is in scope and asset Z is listed” — still without touching anything live

If you cannot complete items 3–8 from the page alone, you are not ready to submit to that program.

Primacy of Impact vs listed assets (concept only)

Primacy of Impact is an Immunefi best-practice some programs adopt: if a report shows a real in-scope impact, the project may treat it as in-scope even when the affected asset was missing from the assets table. Important limits from Immunefi’s own explanation:

• It does not cover out-of-scope impacts
• It does not cover purely theoretical risk with no current impact
• It may apply only to certain severities or categories (e.g. smart-contract Critical only)

ENS’s rewards section shows Primacy of Impact on several severity rows and Primacy of Rules on others — read those labels before assuming a missing asset is fair game. Primacy of Impact is not permission to ignore out-of-scope lists or to test on mainnet.

Your first 7-day action plan

Day-by-day habits (study, CTF, notes — no live hunting yet)

Tooling you will install next (Foundry/Slither teaser → Spoke 05)

Soon you will install Foundry (forge / cast / anvil) for compile-test-fork workflows and Slither for static detectors — covered in the upcoming Foundry + Slither setup tutorial in this series. Do not rush production forks this week. Finish CTF reps and scope-reading muscle first.

Common beginner traps

Spray-and-pray AI reports

Immunefi explicitly warns and bans around AI-generated or automated reports that lack real impact analysis, and around floods of low-quality submissions. A three-line ChatGPT dump wastes triage time and can end your account. Use AI, if at all, as a rubber duck — never as the submitter.

Out-of-scope “findings” and severity inflation

Marking a best-practice nit Critical, or reporting an asset/impact the program excludes, burns trust. Match your claim to the program’s impact table and IVS definitions. When unsure, severity goes down, not up.

Skipping protocol economics

Many “bugs” are intended market risk: thin liquidity, governance power, oracle delay assumptions. Hunters who skip tokenomics and invariant reading file noise. Read docs, whitepapers, and prior audits before declaring insolvency.

Next steps in the Andrax Web3 path

Series hub and upcoming setup tutorial

Series hub (live): Web3 Bug Hunting Learning Path 2026: From Zero to Your First Immunefi Report. Next practical spokes (live): Wallet, RPC & Etherscan Setup, Solidity Essentials for Bug Hunters.

External learning we recommend alongside Andrax (Cyfrin, DVD, Ethernaut — with URLs)

Verified free companions:

• Cyfrin Updraft — Smart Contract Security — structured auditor-oriented course (Foundry, fuzzing, reviews)
• Damn Vulnerable DeFi (v4 release notes — Foundry migration, modern challenges) — DeFi-shaped CTFs; still follow responsible disclosure for real bugs
• OpenZeppelin Ethernaut — classic EVM puzzle ladder

Use them for skill. Use Immunefi/CodeHawks for authorized submission practice later.

FAQ

Do I need to know Solidity first?

You need to read Solidity sooner than you need to ship production contracts. A short developer course plus Ethernaut is enough to start CTFs. Deep compiler/Yul knowledge can wait. If you cannot follow a simple withdraw function and its modifiers, pause hunting and study reading first.

Can I start on Immunefi immediately?

You can create an account and read program pages immediately — that is today’s lab. You should not submit until you can: (1) map scope accurately, (2) demonstrate impact with a local-fork PoC when required, and (3) write a complete report. Premature spam is how beginners get warned or banned.

Is Web2 bug bounty experience transferable?

Partly. Report discipline, clear repro steps, and respect for scope transfer well. What does not transfer: “probe the live target to confirm.” On-chain, that instinct is how you earn a permanent Immunefi ban. Relearn confirmation as local fork + runnable test, and learn protocol economics that Web2 apps rarely have.

---

Educational content by Syed Zada Abrar for Andrax (andraxpentester.in). Authorized research only.