Hardhat vs Foundry: which to choose in 2026

Developing a smart contract involves compiling code, testing its behavior and preparing deployment. Hardhat and Foundry provide tools for that work, with different approaches to organizing tests and connecting the project to other applications.

Hardhat 3 supports tests in Solidity and TypeScript, while Foundry organizes much of its testing workflow around Solidity. The choice depends on the team’s working practices and project integrations. A representative comparison should include the project’s permissions, contract interactions and failure scenarios.

What changes with Hardhat 3

The choice is no longer JavaScript versus Solidity. Hardhat 3 supports Solidity and TypeScript tests, including fuzzing. Foundry provides Forge for compiling, testing and deploying contracts, Cast for interacting with networks and Anvil for local development. A comparison needs explicit versions and a defined workload.

Selection criteria

If a repository relies on TypeScript plugins, scripts and services, assess which Hardhat features it still needs. Check each plugin against the selected version: upgrading the framework does not automatically upgrade its extensions.

Foundry keeps tests and scripts close to the contract language. Invariant tests and simulation tools help explore sequences of operations, beyond isolated inputs. Campaign configuration matters as much as tool availability: define actors, bounds, reachable states and properties that must hold.

We do not claim one tool is always faster. Run the same repository, compiler, optimiser and test count in the same environment. Separate cold compilation, warm caches and fuzzing duration. A result without these conditions cannot be reproduced.

A useful adoption trial

• Compile contracts and verify reproducible artefacts.
• Run unit, integration and invariant tests with recorded seeds.
• Simulate deployment and check permissions, addresses and configuration per network.
• Execute the complete CI workflow and retain logs without secrets.

What it means for a campaign to find a failure

A deposit-and-withdrawal contract provides one evaluation example. A unit test can check a specific withdrawal; an invariant campaign can explore sequences of users and operations. For a useful comparison, both configurations must represent the same accounting rules and reach the same relevant states.

If the generator mostly produces rejected calls, it may execute many tests without exercising the intended logic. Examine participating functions and actors, discarded inputs and the sequence that reproduces a failure. Execution counts alone do not establish campaign quality.

Retain the configuration and failing case so they can be replayed after remediation. The regression test should express the violated property; changing a seed until the suite passes does not fix the problem.

Deployment and repository maintenance

Include the path from a clean compilation to a test network in the adoption trial. Check initialisation arguments, final permissions and recorded addresses. A team may prefer a tool that integrates this process better even if another finishes one testing stage sooner.

Document versions and execution conditions alongside the decision. If both Hardhat and Foundry remain, give each a defined responsibility and check for configuration drift. The comparison then supports project maintenance as well as the initial installation choice.

When to combine them

Using both can make sense when each meets a concrete team need. The cost is maintaining two configurations and avoiding differences in compilers, dependencies or deployment. This combination should not be presented as universal auditor practice or a security guarantee.

For a smart contract project, document the decision with acceptance tests and operational ownership. Tools help check properties; they do not establish contract correctness by themselves.