Foundry changed the standard for Ethereum development tooling.
It brought Solidity tests, fuzzing, and control over the test environment into a focused workflow. My argument was that those pieces belonged together, and Foundry understood that particularly well.
That is what I mean by “Foundry won.” It is a judgment about the workflow, not a claim that every team switched or that one framework will always be faster.
Update — September 7, 2026
The original publication date is August 22, 2025. The historical argument below remains, with corrections to the comparison and sources added during this review.
Hardhat's response deserves more weight than the title alone gives it. Nomic Foundation's June 2026 stable-release announcement dates the Hardhat 3 beta to August 2025 and describes the subsequent work on Solidity testing, fuzzing, invariants, and the build system. Those capabilities are part of the current comparison.
For measured performance, read the Foundry vs Hardhat benchmark. It separates builds from test commands and explains the workload, versions, and limits. Check the measurement date and configuration there before carrying a result into another project. An old speed comparison cannot settle a current framework choice.
The comeback of Hardhat develops the broader argument about its response. This article explains why Foundry's original insight mattered.
The workflow Foundry understood
For a team building contracts alongside a frontend or service, JavaScript and TypeScript tests are a reasonable fit. The test can use the same client library and application types as the code that will call the contract.
A developer concentrating on Solidity has a different immediate problem. They want to change a contract, exercise its behavior, and understand a failure without translating the entire test into another language.
Foundry made that the center of its design. Georgios Konstantopoulos's December 2021 introduction explicitly argued for Solidity tests, fuzzing, and overrides of virtual-machine state. It also credited DappTools as the foundation for those ideas. Foundry did not invent Solidity testing from nothing.
The useful change was how those ideas fit together. A test could call a contract directly, check the result in Solidity, and control the conditions around the call. The developer stayed close to the code being tested.
That is still the strongest part of the historical thesis. Language continuity and a short feedback loop matter together. A faster command is valuable; a testing environment that makes the next test easier to write is valuable too.
Security testing inside the daily loop
Fuzzing gives the runner responsibility for choosing inputs instead of requiring the author to enumerate every example. Foundry's original announcement already described parameterized tests and shrinking a failure into a smaller counterexample. That made an advanced testing technique accessible through the same test structure as an ordinary example.
Invariants extend the idea to sequences of actions. Forge's invariant testing documentation describes randomized calls with properties checked after each call. For a vault, a useful property might compare the assets it holds with the deposits it owes.
The hard work is still choosing the right property and the actions the runner can exercise. A campaign that never reaches a meaningful withdrawal is weak evidence about withdrawals, however many calls it attempts. Passing tests do not establish that a protocol is secure.
Cheatcodes support that work by letting a Solidity test control its environment. The original Foundry design exposed operations such as changing time or the caller through a test interface. That cohesion was the advantage worth emphasizing. It did not mean other tools had no way to manipulate a local chain.
My judgment is that putting these techniques beside ordinary unit tests was more important than any single speed ratio. It encouraged treating them as part of development instead of a separate phase at the end.
What the Hardhat comparison missed
Describing Hardhat as an entirely JavaScript execution engine was already wrong when this article first appeared.
Nomic Foundation's EDR announcement records that Hardhat 2.21.0 shipped its Rust-based Ethereum Development Runtime in March 2024. It explains the use of REVM and the move of Ethereum simulation into Rust. Node.js remained part of Hardhat's surrounding environment; its presence did not mean the virtual machine was still implemented in JavaScript.
Hardhat 3 also supports Solidity tests without a testing plugin. Its runner recognizes test functions, runs setup functions, accepts parameterized fuzz tests, and supports assertion libraries such as forge-std.
The current Foundry migration guide covers fuzz and invariant settings as well as compatibility limits. Some cheatcodes remain unsupported. A familiar test layout is a useful starting point, but a real repository still needs its tests checked against the destination runner.
These corrections narrow the original argument. Solidity testing and fuzzing are no longer reasons to dismiss Hardhat automatically. They remain reasons why Foundry's approach mattered.
Why the toolkit still appeals
Foundry's scope extends beyond the test runner. Its current toolkit includes Forge for contract development, Cast for command-line chain interactions, Anvil for a local node with forking, and Chisel for interactive Solidity experiments.
That is a coherent fit for work centered on contracts. I would still start by evaluating Foundry for a self-contained Solidity repository, especially when the team already relies on its test conventions and scripts.
Hardhat deserves evaluation when the repository also needs substantial TypeScript integration work. Its getting-started guide supports Solidity and TypeScript testing in the same project. The question becomes which environment makes the whole project easier to maintain.
Deployment workflows also need attention. Hardhat's migration guide explicitly notes that it has no direct equivalent of forge script and points to Ignition for declarative deployments. Moving a test suite does not automatically move the team's operational workflow with it.
Foundry won the argument that Solidity developers deserved a cohesive testing environment. Hardhat's response strengthens that historical judgment. For a project starting now, I would choose from the actual tests, scripts, integrations, and measured feedback time the team needs to live with.