Foundry vs Hardhat 3: I benchmarked the same Solidity tests

One month ago, I wrote The comeback of Hardhat after noticing something that went against the direction of Ethereum tooling for the last few years: 1inch was migrating projects to Hardhat 3, and performance was part of what made the move interesting.

That made me pause.

Teams had spent years moving from Hardhat to Foundry because Foundry was faster. My own article, Foundry vs Hardhat: why Foundry won, made exactly that argument. Foundry gave Solidity developers fast feedback, native tests, fuzzing, invariants, and cheatcodes while Hardhat was still associated with slower JavaScript test suites.

Now a major DeFi team was moving in the other direction while working directly with the Hardhat team on its production workflow.

Hardhat had also replaced its old execution layer with EDR, a Rust runtime built on REVM. It had added first-class Solidity tests, built-in fuzzing, stateful invariants, and support for most common Foundry cheatcodes.

I did not want to write another comparison based on reputation or vendor claims. I wanted to know whether the performance story had actually changed.

Most numbers shared online still compare modern Foundry Solidity tests with old Hardhat JavaScript tests running through ethers.js and a pre-EDR network. That is not a useful comparison anymore.

So I built one Solidity project, compiled it with the same compiler, ran the exact same tests through both frameworks, and measured everything from cold builds to fuzzing and invariants.

Foundry won every benchmark. But on the actual Solidity test workloads, Hardhat came within 12 to 22 percent.

The benchmark setup

I created one shared Solidity project that both Forge and Hardhat run directly.

The workload contains:

• 81 source contracts compiled with optimization enabled
• 200 Solidity unit tests
• Two fuzz tests with 256 runs each, producing 512 fuzz cases
• One stateful invariant with 64 runs and a depth of 32, producing 2,048 calls

Both tools used the exact same native Solidity 0.8.25 compiler binary with the optimizer enabled and 200 optimizer runs.

The versions were:

• Foundry 1.5.1
• Hardhat 3.12.0
• Node.js 23.7.0
• Solidity 0.8.25

The machine was an Apple M3 Pro with 12 logical CPUs and 36 GB of memory.

For cold builds, I deleted each framework's artifacts and cache before every observation. I collected seven runs because compiling the full workload is relatively expensive.

For warm builds and test workloads, I performed two excluded warmup runs followed by 15 measured runs. The harness alternated which framework executed first to reduce ordering and thermal bias.

The test numbers represent the command a developer actually runs, including process startup, cached compilation checks, test discovery, execution, and reporting. They are not isolated EVM microbenchmarks.

The complete generator, harness, configuration, raw observations, and summary statistics are available in the repository under benchmarks/foundry-hardhat.

The results

All figures below are median wall-clock times.

Foundry won all five scenarios.

That part was expected. The size and location of the gap were more interesting.

Test execution is much closer than the old story suggests

Hardhat took 13 percent longer to run 200 unit tests and 12 percent longer to execute the fuzz workload.

On the stateful invariant campaign, Hardhat took 22 percent longer.

These are real differences, but they are not different categories of performance. In normal development, both unit suites returned in roughly a third of a second. Both fuzz workloads did the same.

This is where EDR has changed the comparison. Hardhat's Solidity tests no longer need to move through the old JavaScript, client library, and JSON-RPC path. They execute through an in-process Rust runtime.

Foundry still has the faster runner and a leaner native command-line path. Hardhat has nevertheless closed most of the test-execution gap that made older comparisons so dramatic.

The larger difference is around the build

Cold compilation showed a wider gap. Foundry finished in a median of 2.187 seconds. Hardhat took 3.012 seconds, or about 38 percent longer.

Because both tools invoked the exact same solc binary with the same settings, this difference is not solc generating bytecode faster for one framework. It comes from the work around the compiler: discovering inputs, constructing compiler jobs, processing output, and writing each framework's artifacts and build metadata.

The no-change build produced the largest relative difference. Foundry returned in 122 milliseconds, while Hardhat took 274 milliseconds.

Hardhat took 2.24 times as long, but the absolute difference was 152 milliseconds. That is noticeable in a tight loop, although it is far removed from the multi-second delays associated with older Hardhat versions.

This is also a useful warning about benchmark headlines. Saying one tool is "2.24x faster" sounds dramatic. Saying it saves 152 milliseconds on a no-change build describes the developer impact more honestly.

What the benchmark does not prove

This is one controlled synthetic workload on one machine. It does not establish a universal speed ratio between Foundry and Hardhat.

Real repositories differ in ways that can change the outcome:

• Number and size of compilation units
• Import graph complexity
• Different Solidity versions
• Use of viaIR
• Fork testing and RPC latency
• Filesystem performance
• Coverage and tracing
• FFI and filesystem cheatcodes
• TypeScript integration tests
• Plugin hooks and custom build steps
• Parallelism and CI hardware

The benchmark also measures end-to-end commands rather than pure EVM throughput. That is intentional because command latency is what developers feel, but it means the result includes framework startup and reporting overhead.

I also did not benchmark TypeScript tests. Hardhat's advantage is that it can combine Solidity unit tests with TypeScript integration tests. Comparing those TypeScript tests against Forge would not be an equivalent workload.

Finally, this measures speed, not test quality. Fuzzers and invariant engines can differ in input generation, shrinking, state exploration, revert handling, and the ability to discover a bug. Finishing the same number of runs faster does not automatically mean finding more vulnerabilities.

Is Foundry still faster?

Yes.

Foundry was faster in every scenario, had lower median times, and generally showed lower variance. For a Solidity-only repository where every millisecond of feedback matters, it remains the performance leader.

But the result does not support describing modern Hardhat as slow.

Hardhat 3 completed 200 Solidity unit tests only 37 milliseconds behind Foundry. It completed 512 fuzz cases 33 milliseconds behind. Even the invariant campaign differed by only 58 milliseconds.

The more meaningful tradeoff is now about the complete workflow.

Foundry offers the leanest Solidity-first experience, a broader cheatcode surface, mature security workflows, forge script, Cast, Anvil, and Chisel.

Hardhat offers a runner that is now close on Solidity-test performance while retaining TypeScript integration, a plugin system, Hardhat Ignition, multichain simulation, built-in coverage, verification workflows, and a broader application-development environment.

Speed alone is no longer enough to make the decision.

The real winner is the developer

Foundry forced Ethereum tooling to take performance seriously.

It proved that Solidity developers did not have to accept slow feedback, language switching, and security tooling assembled from separate systems. Hardhat responded by rebuilding its execution layer and adopting the workflow developers had chosen.

The benchmark shows the result of that competition.

Foundry is still faster. Hardhat is now close enough that teams can choose based on how they build, test, deploy, and operate their software rather than relying on performance assumptions from four years ago.

That is a much healthier tooling ecosystem than one framework winning by default.