There is no shortage of Web3 security tooling. The harder part is figuring out which tools are actually useful, what each one is good at, and where they fit into a real development workflow.
A Solidity developer looking for a quick static check has very different needs from an auditor reverse-engineering bytecode, or a protocol team trying to monitor contracts after launch. The same repository of tools can be indispensable to one of those people and noise to the other two.
So instead of another giant list with little context, we went through open-source projects and security collections on GitHub and pulled together 50 resources worth knowing. The full directory spans static analyzers and fuzzers, wallet security tools, CTFs, monitoring systems, and security frameworks.
Below are some of the projects we would start with, and where each one earns its place.
Start with the basics: static analysis
If you write Solidity, Slither is probably the most obvious place to begin. Developed by Trail of Bits, it scans Solidity and Vyper contracts for common issues and gives you a quick way to catch problems before a human audit ever starts. It is fast enough to be part of a regular development workflow rather than something you only run before mainnet.
Mythril takes a different approach. It uses symbolic execution to explore different paths through EVM bytecode, which makes it useful for bugs that depend on particular states or combinations of inputs.
Then there is Aderyn, a newer Rust-based Solidity analyzer from Cyfrin. If you want something lightweight that developers can run regularly while building, it is worth a look.
Wake is more of a full development and security framework. It combines testing and analysis in a Python environment, which makes it especially interesting for auditors who want to build their own checks or automate parts of a review.
None of these replaces manual review. That is not really the point. The value is in catching obvious or repeatable problems early, so human reviewers can spend their time on the things automated tools are worse at: business logic, assumptions, permissions, economic design, and weird interactions between contracts.
Fuzzing is where testing gets more interesting
A unit test usually answers a question you already thought to ask. A fuzzer tries to find the questions you did not.
That distinction matters in smart contracts, where a perfectly reasonable function can behave very differently once state, timing, input ranges, or external calls start interacting in unexpected ways.
Echidna is one of the best-known tools here. You define properties that should always remain true, then let Echidna search for inputs that break them. If your protocol should never allow withdrawals to exceed deposits, for example, you can express that as an invariant rather than manually inventing hundreds of test cases.
Medusa, also from Trail of Bits, takes a coverage-guided approach and is designed to run fuzzing workloads in parallel.
For developers already using Foundry, you may not need to introduce another tool immediately. Foundry already supports fuzz testing and invariants alongside the rest of the Solidity development workflow. And for properties that deserve deeper analysis, Halmos brings symbolic testing into a Foundry-style environment.
If you are setting up a security workflow from scratch, a stack as simple as Foundry + Slither + Echidna gets you surprisingly far. It gives you normal tests, fuzzing, invariants, and static analysis without turning the development process into a security research project of its own.
Study real hacks, not just vulnerability names
“Reentrancy” is easy to understand as a definition. It gets much more useful once you see how an attacker actually turned it into money.
That is why DeFiHackLabs is such a good resource. It recreates real DeFi exploits so you can inspect the transactions and reproduce the attack yourself. DeFiVulnLabs takes a similar hands-on approach, but with deliberately vulnerable contracts built around common attack patterns.
These repositories are especially useful once you already know some Solidity and want to start thinking like an auditor. You stop memorizing lists of vulnerabilities and start asking more useful questions:
- What assumption failed here?
- What could the attacker control?
- What did the developers believe would always be true?
- And what would have caught this before deployment?
That shift in thinking matters more than knowing the names of 30 vulnerability classes.
Sometimes you do not have the source code
Security work gets more awkward when all you have is deployed bytecode.
That is where tools such as Heimdall-rs and evmole come in. Heimdall-rs can decompile and inspect EVM contracts, while evmole is useful for quickly extracting things such as function selectors from bytecode.
For contracts that do publish source code, Sourcify helps verify that the source actually corresponds to what was deployed. That may sound mundane, but it solves a very real problem: an audit is only useful if the code that reaches mainnet is the code that was reviewed. Tools such as evm-mirror exist for the same reason. “Audited” and “deployed” should not quietly become two different versions of a contract.
Contract security is only half the story
Plenty of serious Web3 incidents never begin with a clever Solidity exploit. They begin with a compromised signer, a malicious transaction, a phishing site, poor key management, or someone approving something they did not understand.
eth-phishing-detect, used in the MetaMask ecosystem, maintains data for identifying known phishing domains. SafeLens is aimed at a different problem: helping users inspect Safe multisig transactions before signing them. And the ERC-7730 Clear Signing Registry tackles one of the most persistent wallet UX problems in crypto — asking people to approve transactions they can barely read.
For teams building custody or treasury infrastructure, there are also open-source MPC and threshold-signing libraries such as Coinbase cb-mpc and tss-lib. The design questions there are the same ones that decide any key custody model, which our guide to encryption and key custody covers in the document context.
The important point is that a secure contract does not automatically mean a secure protocol. If the admin keys, multisig process, signing flow, or operational controls are weak, the Solidity may be the least of your problems.
Mainnet is when security changes, not when it ends
A lot of teams still treat the audit as the finish line. It is not.
Once a protocol is live, the problem changes from “Can we find bugs?” to “Can we see something going wrong quickly enough to do anything about it?”
OpenZeppelin Monitor is one open-source option for watching smart contract activity and blockchain events. Blockscout is useful for exploring transactions and contracts across EVM networks, especially when you need to investigate what happened after the fact. There are also increasingly useful collections of blockchain OSINT resources for tracing transactions, addresses, counterparties, and off-chain clues during an investigation.
This is the part of Web3 security that often gets less attention than auditing because it feels operational rather than technical. Until there is an incident. Then it becomes the only thing anyone cares about.
Security frameworks are boring until you need one
Tools are easier to get excited about than process. But if you are running an actual protocol, a toolchain alone is not enough.
The SEAL Security Frameworks are worth reading because they look beyond individual vulnerabilities and toward the way crypto organizations handle security as a whole. The long-running Smart Contract Security Best Practices repository is another useful reference for developers. And SlowMist’s Web3 Project Security Practice Requirements covers areas that are easy to ignore when all the attention is on contract code: access control, infrastructure, deployment, keys, monitoring, and incident response.
Access control is the one that transfers most directly from document platforms to protocols: who holds which role, how the role is granted, and who can prove it later. Our access control practices guide works through the same problem in a different setting.
The lesson across all of them is fairly simple. Security is not a stage in the release process. It is a set of habits that starts before the first contract is deployed and keeps going after the audit PDF lands in your inbox.
Want to learn by breaking things?
For developers moving into security, CTFs are still one of the best ways to build intuition.
Ethernaut is a great starting point. The challenges are small enough to work through without getting lost, but they introduce many of the behaviors and mistakes that show up in real contracts. Once that feels comfortable, projects such as Paradigm CTF get considerably harder.
The full directory
We collected 50 Web3 security tools and resources across eleven areas: static analysis, symbolic execution, fuzzing and invariant testing, reverse engineering, wallet and signing security, MPC and key management, monitoring, blockchain OSINT, security frameworks, training and CTFs, and AI-assisted security.
The projects this guide walks through, grouped the same way. The full directory — all fifty entries, including the OSINT collections and the AI-assisted tooling this guide does not name individually — is in our Web3 security resources table:
- Static analysis and symbolic execution — Slither, Mythril, Aderyn, Wake, Halmos
- Fuzzing and invariant testing — Echidna, Medusa, Foundry
- Reverse engineering and verification — Heimdall-rs, evmole, Sourcify, evm-mirror
- Studying real exploits — DeFiHackLabs, DeFiVulnLabs
- Wallet and signing security — eth-phishing-detect, SafeLens, ERC-7730 Clear Signing Registry
- MPC and key management — Coinbase cb-mpc, tss-lib
- Monitoring and investigation — OpenZeppelin Monitor, Blockscout
- Security frameworks — SEAL Security Frameworks, Smart Contract Security Best Practices, SlowMist Web3 Project Security Practice Requirements
- Training and CTFs — Ethernaut, Paradigm CTF
AI-assisted security is the newest of the categories, and the one where the tooling is changing fastest. The same caution applies there as everywhere else in this list: an assistant that reads your contracts is another reviewer, not a replacement for one, and anything it touches inherits the same access questions — a point our notes on AI agents and document security make about AI access in general.
So what should you actually use?
If you are a Solidity developer and just want a sensible starting point, do not install 20 tools. Start with Foundry, Slither, and Echidna.
If you are moving into auditing, add Mythril, Wake, Heimdall-rs, and DeFiHackLabs.
If you are responsible for a live protocol, your list should look different again. You need to think about deployment verification, wallet operations, monitoring, access control, and incident response — not just whether Slither found anything.
That is probably the most useful way to think about Web3 security tooling in general. There is no “best stack.” There is only a stack that matches what you are trying to protect.
One habit is worth adopting regardless of which list you pick: treat every approval and every signature as a security event. Phishing and malicious approvals do not need a bug in your Solidity at all, which is why the risks of handing out access too freely apply to external sharing and guest access just as much as they do to a wallet prompt.
And if your entire security story is still “we got audited,” there is probably more work to do.