Skip to content

Back to the catalog

Damn Vulnerable DeFi
github.comrepo

Damn Vulnerable DeFi

Damn Vulnerable DeFi is a Foundry-based Solidity smart contract security playground featuring intentionally vulnerable challenges around flashloans, price oracles, governance, NFTs, DEXs, lending pools, smart contract wallets, timelocks, vaults, meta-transactions, and upgradeability. Each challenge presents a prompt and vulnerable contracts; solvers write a Foundry test exploiting the flaw to drain funds or bypass restrictions, making it a benchmark for both human auditors and automated security tooling.

TL;DR A Foundry-based CTF-style repo of intentionally vulnerable DeFi smart contracts (flashloans, oracles, governance, DEXs) for sharpening Solidity auditing skills.
Open original ↗
Document

How it works

Each challenge lives in src/<challenge-name>/: a README.md prompt plus the vulnerable contracts. Your exploit goes in the Foundry test at test/<challenge-name>/<ChallengeName>.t.sol. You read the prompt, find the flaw, write your solution in the test, and a passing test means you solved it. Challenges may have multiple valid solutions.

Preconditions / Affected

  • Foundry, or the provided VSCode devcontainer ("Devcontainer: Open Folder in Container...").
  • An RPC URL in .env (copy from .env.sample) — only for challenges that fork mainnet state.
  • Pin a release rather than tracking main, e.g. git checkout v4.1.0.

What to do

Setup:

git checkout v4.1.0
forge build

Run a single challenge's test:

forge test --mp test/<challenge-name>/<ChallengeName>.t.sol

For challenges that cap the number of transactions, add --isolate or the test may pass/fail misleadingly:

forge test --mp test/<challenge-name>/<ChallengeName>.t.sol --isolate

Solving constraints the page makes explicit — these are the "final conditions" your solution is graded against:

  • Always act as the player account.
  • Do not modify the challenge's initial or final conditions.
  • You may deploy your own contracts and use Foundry cheatcodes to advance time.
  • External libraries are permitted but "shouldn't be necessary."

Caveats

All code is intentionally vulnerable and not for production. The --isolate transaction-counting detail is easy to miss and is the difference between a legitimate solve and a false pass on transaction-limited challenges — worth noting if you're benchmarking tooling against these rather than hand-solving.

Technologies named here

Techniques named here

  • Uncovering flaws in smart contracts via auditing
  • Custom smart contract deployment for exploitation

Related in Learning