Foundry is an open-source toolkit for building, testing, and deploying Ethereum smart contracts, built entirely in Rust and written specifically for Solidity developers. It bundles four command-line tools — forge, cast, anvil, and chisel — that together cover the full lifecycle of a smart contract, from compiling code to debugging a failed transaction on mainnet. Unlike older JavaScript-based frameworks, Foundry lets you write your tests in Solidity itself, which is the detail that made it the default choice for a large share of Ethereum’s DeFi and security-focused development teams.
This guide starts with what Foundry actually is, then works through why it exists, who reaches for it, and how its four tools fit together in practice. By the end, you’ll know where Foundry earns its reputation for speed, where it still falls short of Hardhat, and how it connects to the RPC infrastructure a contract eventually needs to reach a live network.
What Is Foundry?
Foundry is a Rust-based development toolkit maintained by the foundry-rs organization, with its core development funded by Paradigm, the crypto investment firm. The GitHub repository has passed 10,600 stars and 2,600 forks as of September 2026, and the project reached its first stable release, Foundry v1.0, in February 2025 — a milestone that locked in a versioned, backward-compatible API instead of the frequent breaking changes typical of its early years.
The toolkit is a direct successor to dapptools, an earlier Rust-and-shell testing framework used to build the Eth2 Deposit Contract and Wrapped Ether. Foundry kept dapptools’ core idea — writing tests as Solidity contracts rather than JavaScript scripts — and rebuilt the tooling around it from scratch for speed and usability.
Toolkit: in this context, a bundled set of command-line programs that cover related tasks — compiling, testing, running a local network, and interacting with a live one — rather than a single monolithic application. See the official Foundry Book for the full technical reference.
Georgios Konstantopoulos, Foundry’s creator and Paradigm’s CTO, described the project’s scope directly: “Foundry is a workflow capturing toolkit — its goal is to never need to leave your terminal for anything smart contract lifecycle: dev, testing, debugging, auditing, research and more,” he wrote on X. That framing matters, because Foundry isn’t just a testing library bolted onto Solidity — it’s meant to replace the whole chain of separate tools a developer used to string together.
Why Do Solidity Developers Need Foundry?
Before Foundry, testing a Solidity contract usually meant writing JavaScript or TypeScript tests with a framework like Truffle or early Hardhat, which called into the EVM through a separate test runner. That setup worked, but it added a language switch — Solidity for the contract, JavaScript for the test — and a real performance cost, since every test still had to round-trip through a JSON-RPC layer built for a general-purpose scripting language rather than the EVM itself.
Foundry removes both problems by keeping everything native to Solidity. Tests are Solidity contracts, run directly against an in-memory EVM without a JavaScript intermediary, and the compilation and execution engine is written in Rust rather than interpreted JavaScript. The practical result shows up in raw numbers: independent 2026 benchmarks on an M2 MacBook running an 80-test suite put Foundry at 1.3 seconds cold and 0.4 seconds warm, against 2.1 seconds and 0.7 seconds for Hardhat 3’s newer Rust-accelerated engine — and a much larger 18-second cold run for the older, fully JavaScript-based Hardhat 2, according to a 2026 toolchain comparison on Dev.to.
That speed compounds. A team running thousands of fuzz-test iterations across a large contract suite in continuous integration feels the difference every single commit, not just once.
Who Uses Foundry?
Foundry’s user base splits into a few overlapping groups, and each reaches for it for a slightly different reason.
- DeFi protocol teams use Foundry as the default for contracts handling real value, since fast fuzz testing catches edge cases a handful of hand-written unit tests would miss.
- Security researchers and auditors rely on Forge’s built-in fuzzing, invariant testing, and gas-flamegraph tooling to probe a contract’s behavior across a wide input space before a manual review even starts.
- Solo developers and small teams use it for the fast local feedback loop — Anvil spins up a local chain in under a second, so a contract change can be tested without waiting on a testnet.
- Teams already on Hardhat increasingly run a hybrid setup: Foundry for testing and fuzzing, Hardhat for JavaScript-based deployment scripting and multi-network orchestration, since the two tools can coexist in the same repository.
That last pattern is common enough that it shows up in most current comparisons — the choice between Foundry and Hardhat is rarely all-or-nothing anymore.
How Does Foundry Work?
Foundry’s four tools each handle one part of the contract lifecycle, and they’re designed to be used together rather than as standalone products.
| Tool | What it does | Typical command |
| Forge | Compiles, tests, fuzzes, and deploys contracts | forge build, forge test, forge create |
| Cast | Sends transactions and reads on-chain data from the command line | cast call, cast send |
| Anvil | Runs a local Ethereum node for development and testing | anvil |
| Chisel | Provides a Solidity REPL for quickly testing snippets | chisel |
Forge: Compiling and Testing
Forge is the tool developers spend the most time in. forge build compiles a project’s Solidity source into bytecode and an ABI, and forge test runs every function in the project prefixed test as an individual test case — no separate test runner or assertion library required, since Forge ships its own.
Forge’s fuzz testing is one of its more distinctive features: give a test function a parameter instead of a hardcoded value, and Forge automatically generates hundreds of randomized inputs to try to break the assumption the test is checking. Invariant testing extends the same idea across a whole sequence of calls, checking that some property — total supply never decreases, for instance — holds no matter what order functions are called in.
Forge’s built-in gas reports also make it a common tool for catching the kind of avoidable gas waste covered in our breakdown of Solidity’s storage, memory, and calldata costs — a forge test –gas-report run flags exactly which function calls are the expensive ones.
Cast: Talking to an External or Local Chain
Cast is the command-line client for reading and writing chain data outside of a test environment. cast call reads a contract’s state without sending a transaction; cast send broadcasts a signed transaction to change it. Both need an RPC endpoint to actually reach a network, whether that’s a local Anvil instance or a external mainnet connection.
Anvil and Cheatcodes
Anvil is Foundry’s local test node, and it can run a plain empty chain or fork an existing network’s state with a single –fork-url flag — useful for testing how a new contract behaves against real, current mainnet state without spending real gas. That forked setup is also the fastest way to check what a contract actually costs before deploying it, the same question our guide to simulating a transaction on Ethereum covers from the RPC side.
Forge’s tests also get access to “cheatcodes,” special functions exposed through a fixed address (0x7109709ECfa91a80626fF3989D68f67F5b1DD12D) that let a test warp block timestamps, impersonate any address, or set an account’s balance directly — things that would be impossible to trigger through a normal transaction.
How to Install Foundry
Installing Foundry means installing foundryup, its version manager, and then using it to pull the four binaries. The steps are short enough to run in one sitting:
- Install foundryup by running curl -L https://getfoundry.sh/install | bash in a terminal.
- Restart the terminal, or run source ~/.bashrc (or the equivalent for your shell) to load the new command.
- Run foundryup to download and install the latest stable release of forge, cast, anvil, and chisel.
- Confirm the install with forge –version to check the binary is on the system path.
Windows users need Git Bash or WSL, since foundryup doesn’t run natively in PowerShell or Command Prompt, according to the official installation guide. By default, everything installs to ~/.foundry, though that location can be overridden with the FOUNDRY_DIR environment variable before running the installer.
Foundry vs. Hardhat: What’s the Difference?
Foundry and Hardhat solve the same problem from different directions, and the right one depends on what a team is already built around.
| Area | Foundry | Hardhat |
| Test language | Solidity | JavaScript/TypeScript, or Solidity in Hardhat 3 |
| Compilation & test speed | Fastest in most 2026 benchmarks | Competitive with Hardhat 3’s Rust layer; much slower on Hardhat 2 |
| Dependency management | Git submodules via forge install | npm packages |
| Debugging | DSTest assertions, gas flamegraphs | Native console.log() in contracts |
| Deployment scripting | CLI-driven, or Solidity scripts | JavaScript deployment scripts, more flexible for multi-step logic |
| Best fit | Solidity-native teams, fuzzing-heavy DeFi and security work | Full-stack teams already in a JavaScript/TypeScript codebase |
The gap has narrowed since Hardhat 3 shipped a Rust-based execution layer and native Solidity test support, closing what used to be a 10-to-20x speed penalty down to roughly 2x. Hardhat still wins on JavaScript-based deployment flexibility and native console.log() debugging inside a contract, which many developers find more intuitive than Forge’s Solidity-based assertions.
Neither tool is strictly better across every workload, which is why a growing number of production teams run Foundry for testing and Hardhat for deployment scripting in the same project rather than picking one exclusively.
What Are Foundry’s Limitations?
Foundry’s speed and Solidity-native testing come with real trade-offs, and a fair guide doesn’t hide them. Deployment scripting through the CLI gets unwieldy fast once a contract’s constructor takes several arguments, which is part of why Foundry added Solidity-based deployment scripts as a more structured alternative.
Debugging inside a contract also has a steeper learning curve than Hardhat’s console.log() — Forge relies on DSTest-style assertions and a separate trace decoder instead of a familiar print statement. And because dependencies are Git submodules rather than npm packages, a team used to package.json version pinning has to adjust to a different mental model for tracking library versions.
None of these are dealbreakers, but they’re the reason some teams keep a JavaScript-based tool in the loop even after adopting Foundry for testing.
Where Foundry Fits Into a Live Deployment
Everything Forge and Anvil do locally eventually needs to connect to a real network — forking mainnet state in Anvil, broadcasting a forge create deployment, or running cast call against a live contract all require an RPC endpoint rather than a local simulation. Running that endpoint by syncing a full node yourself is a heavier commitment than most teams want just to run a test suite against current chain state.
A provider such as NOWNodes gives Foundry that connection without the maintenance: pointing anvil –fork-url or a forge script broadcast at a hosted Ethereum endpoint works the same way as pointing it at a self-run node, minus the sync time and server upkeep. For teams building or testing through an AI coding assistant, NOWNodes’ MCP Server exposes the same documented API methods directly inside tools like Claude Code and Cursor, which fits naturally alongside a Foundry-based workflow already run from the terminal.
That connection matters most at two points in the Foundry lifecycle: forking real state for realistic tests, and the final forge create or cast send that actually puts a contract on mainnet. Our guide to deploying an ERC-20 token walks through that last step in more detail, including how Foundry compares to Hardhat and Remix for a first deployment.
Conclusion
Foundry is what a large share of Solidity teams now reach for first: a Rust-built, Solidity-native toolkit that compiles and tests faster than almost anything else available, with fuzzing and cheatcodes built in rather than bolted on. It isn’t the only correct choice — Hardhat’s JavaScript deployment scripting and native logging still win over teams building full-stack applications — but for contract-level testing on DeFi and security-sensitive projects, Foundry’s speed and Solidity-first design are hard to argue with.
The practical takeaway: install it with foundryup, start with forge init and forge test, and don’t be surprised if a Hardhat-based deployment script ends up living in the same repository. That hybrid setup isn’t a compromise — it’s how most mature teams actually run it in 2026.
FAQ
Is Foundry Free to Use?
Yes. Foundry is fully open source under a dual Apache 2.0/MIT license, with no paid tier, account, or usage limit on the toolkit itself.
Does Foundry Only Work With Solidity?
Foundry compiles and tests Solidity contracts specifically. It doesn’t support other smart contract languages like Vyper natively, though cast and anvil work at the RPC level and can interact with any deployed EVM bytecode regardless of the language used to write it.
Can Foundry Deploy Contracts Directly to Mainnet?
Yes, using forge create with a funded account and an RPC endpoint, or a Solidity-based deployment script for more complex constructor logic. Both routes need a live RPC connection rather than Anvil’s local simulation.
Is Foundry Harder to Learn Than Remix?
For a first contract, yes — Remix runs entirely in a browser with no installation, while Foundry requires a terminal, foundryup, and some comfort with command-line tools. Foundry pays that setup cost back on anything beyond a single quick deployment, particularly repeated testing.
Does Foundry Work With OpenZeppelin Contracts?
Yes. OpenZeppelin’s contracts install as a Git submodule through forge install OpenZeppelin/openzeppelin-contracts, and Forge compiles and tests them the same way it handles any other imported Solidity library.
