sc-exploits-minimized turns famous contract bugs into small Foundry tests

A teaching set, not an audit tool

SC Exploits Minimized is a repository of smart contract exploits, minimized, and the README puts it plainly: they are minimized for your learning pleasure.

The design decision is that each exploit is stripped down to the smallest contract that still demonstrates the bug. That is what makes the set useful. A real exploit write-up usually arrives wrapped in a protocol, a proxy system and a market, and the interesting part is easy to lose. Here the reentrancy is a reentrancy, the arithmetic bug is an arithmetic bug, and the test suite says which one it is.

The audience is Solidity developers learning to audit or to write safer contracts, and instructors who want a runnable example per bug class. The primary language is Solidity, the project is built on Foundry, and the last push was on 2026-06-22 with no GitHub releases attached.

The repository also links each exploit out to three other places. The Remix links open a minimal example of the exploit in the browser IDE, with the compiler set to a specific soljson version. The Ethernaut links open the OpenZeppelin challenge where the same exploit exists as a capture the flag. The Damn Vulnerable DeFi links point at the harder DeFi and on-chain finance versions of the same pattern. A fourth column points at case studies, and one of them is a community list of reentrancy attacks.

In other words, the same bug can be studied as a test, as a browser demo, as a wargame and as a real incident.

Two tools and a make target

The requirements are short: git and Foundry. The documentation even tells you how to confirm each one, with git --version for git and forge --version for Foundry.

The quick start is three commands:

git clone https://github.com/Cyfrin/sc-exploits-minimized
cd sc-exploits-minimized
make

The make step does the work of a default target that removes, installs and builds. Removal there is a real operation rather than a formality, and the Makefile shows what it does, since the remove target deletes the .gitmodules file and the contents of .git/modules, removes the lib directory, recreates an empty .gitmodules and commits the result. That is a way of stripping submodule bookkeeping before a fresh install, and it is the one target in the file a newcomer should read before typing make.

Installation then pulls three dependencies through forge install: the standard library foundry-rs/forge-std, the OpenZeppelin contracts pinned at version v5.4.0, and the kontrol cheatcodes from runtimeverification. The third one is the hint about what the project is for, since kontrol is the tool behind the formal verification section.

The build step is forge build, and the repository also carries a foundry.toml, a foundry.lock and a .gitmodules file, so the dependency versions are pinned rather than floating.

One command for the whole suite, one for a single bug

The test entry points are as simple as the setup.

The whole suite runs with:

forge test

A single test is selected by matching its name, for example:

forge test --mt test_reenter

That naming is a small but useful detail. The test function names in this project are readable, the reentrancy test is called test_reenter, so a matching expression is enough to run one case while you are working on it, and the suite is fast enough to run in full before every commit.

The formal verification path is separate and needs one more tool installed, Halmos:

halmos --function check_hellFunc_doesntRevert

The function name tells you the shape of the check, this one asserts that a function does not revert, which is the property you want to hold for a fix. The Makefile has a matching certora target for the other formal verification path, pointing at a configuration file under the invariant break tests:

certora :; certoraRun ./test/invariant-break/formal-verification/certora/conf/FVCatches.conf

So a fix in this repository can be checked three ways: by the unit test, by a Halmos proof and by a Certora specification, and the documentation includes cheat sheets for Halmos and for the difference between fuzzers and formal verification.

The catalogue: reentrancy, arithmetic, DoS and mishandled ETH

The table at the centre of the README is the catalogue, and each row pairs an exploit with the places you can go to see it in action.

Reentrancy is the first row, with a Remix link to the file src/reentrancy/Reentrancy.sol, the Ethernaut level 10 challenge, and the Damn Vulnerable DeFi side entrance challenge. The case study column points at a community maintained list of reentrancy attacks.

Arithmetic is the second row, linking src/arithmetic/OverflowAndUnderflow.sol, Ethernaut level 5 for the token challenge, and no Damn Vulnerable DeFi equivalent yet, with the case study marked as coming soon.

Denial of Service is the third row, with src/denial-of-service/DoS.sol, Ethernaut level 20, and the Unstoppable challenge from Damn Vulnerable DeFi. The case study for it is also marked as coming soon.

Mishandling of ETH is the fourth row, pointing at src/mishandling-of-eth/MishandlingOfEth.sol. The table continues beyond the part visible in the documentation available here, and the source directory is the place to see the full set.

The Remix links are configured in a specific way that is worth noting if you use them. Each one is a permalink with the file path in the URL, the Solidity compiler version set to soljson v0.8.20, optimisation off, and 200 runs, so a reader lands in a working editor rather than an empty one. The examples in the repository live under src/ and the tests under test/, which is the conventional Foundry layout.

The Makefile is the real documentation of the toolchain

The default Foundry project template gives you a Makefile, and this one is worth reading line by line because it names every tool the author expects a smart contract developer to reach for.

Beyond install, build and test, there are targets for forge clean, forge snapshot to record gas snapshots, forge fmt for formatting, forge update to refresh dependencies, and forge coverage with a coverage-report target that writes the debug report to a text file. There is also an anvil target that starts a local chain with the standard test mnemonic, step tracing and a one second block time, which is what you need to run the examples against a local node.

Then the static analysis and formal verification targets appear. Slither runs with the repository's own configuration file:

slither :; slither . --config-file slither.config.json 

Aderyn is run against the project root. The Certora target runs a specification from the invariant break tests, and there is a second Certora target for the invariant variant that the Makefile explicitly marks as not working, with a comment asking why, which is an honest thing to leave in a build file.

There are also tree-based scope targets that rewrite the tree output into a readable scope file, one of them using sed to normalise the box drawing characters, which tells you the author wanted a plain text view of the source layout for review.

One thing to keep in mind is that several of these targets call tools that are not listed in the requirements, so make test works out of the box while make certora, make slither and make aderyn need their own tools installed first.

Invariants, formal verification and the extra artefacts

The repository has a section on invariants and formal verification, and it carries a couple of files that hint at how the work is organised.

There is a lemmas.k file at the top level, which is a K specification file, the format used by the Kontrol proof system, and it aligns with the kontrol cheatcodes being installed as a dependency. The formal verification configuration lives under the invariant break tests in the Certora directory, which is the same place the Makefile points at.

The distinction the documentation offers is between two ways of gaining confidence in a fix. A fuzzer explores inputs and paths at random and is good at finding a counterexample. Formal verification attempts to prove a property holds for all inputs, which is a stronger and slower claim. The cheat sheet for that comparison sits alongside the Halmos cheat sheet, and both are listed in the table of contents.

The rest of the tree is conventional. There is a src/ directory holding the vulnerable contracts, a test/ directory holding the Foundry tests and the formal verification material, images/ for the README, a lib/ directory for the installed dependencies, and a foundry.lock pinning them.

For a teaching repository, the value of that structure is that a reader can pick a single exploit directory, run its test, and see the failure, then read the fixed version next to it. The property tests and the specifications are the part that generalises, because they state what the contract should do rather than what the attacker does.

No stated licence and no releases

Two administrative facts deserve attention before anyone builds on this code.

The first is the licence. The repository records no recognised licence, and the licence field is listed as unknown. That is not the same as a permissive grant, and it is not the same as a prohibition either, but it means the default position is that you do not have permission to reuse the code. For a repository whose entire purpose is to be read, copied and modified, that is an unusual gap, and anyone intending to lift a contract or a test into their own project needs to sort it out first rather than assume.

The second is the release history. There are no GitHub releases, so there is nothing to pin and no changelog to diff. The last push was on 2026-06-22, and the project is a working teaching repository rather than a released package, which is defensible for the purpose but means you follow the main branch.

The tooling around it is solid, though. The repository has a Makefile, a foundry.toml, a foundry.lock, a slither.config.json and a .gitmodules file, and the dependency versions are pinned, OpenZeppelin at v5.4.0 for example. The documentation is organised with a table of contents that links each section, and the external links to Ethernaut and Damn Vulnerable DeFi mean a reader can move from a failing test to a harder, gamified version of the same bug in a couple of clicks.

Editorial conclusion

sc-exploits-minimized suits a developer learning to audit Solidity, or an instructor who wants a runnable example for each classic bug class, and it is the wrong tool for a real audit, because these are deliberately simplified contracts rather than production code. Before using the code outside a classroom, check the licensing yourself, because the repository has no stated licence, and read the Makefile carefully, since its remove target deletes the submodule configuration and the lib directory.

Frequently asked questions

Official sources

1. Cyfrin/sc-exploits-minimized on GitHub
2. Issues
3. README