02.13.2025|George NiculaeJennifer ParakzerosnacksYash AtreyaArsenii KulikovDani PopesMatthias SeitzGeorgios Konstantopoulos
When we first announced Foundry in December 2021, we set out to create the most flexible & fastest EVM development toolkit. Over the past three years, Foundry has evolved to the go-to developer tool for smart contract developers used by anyone from independent builders to teams at leading protocols.
Today, we're proud to announce Foundry v1.0, marking a major milestone in our journey to provide the most stable and performant toolkit for EVM development.
We believe that in order to accelerate Ethereum, we need to provide developers with the best tooling to code, test and ship faster. This is only possible thanks to our strong open source community driving improvements through feedback and contributions. Read on to learn what’s new in Foundry v1.0 and what comes next.
forge test
comes with new flags to enhance your testing experience e.g. by enabling re-runs upon failure, improved UX of tracking test progression and invariant testing metrics. Foundry v1.0 offers better debugging capabilities with internal call tracing and state visualization, letting you debug every detail of a transaction.foundryup
to stable
releases by default. The result is a mature, performant toolkit that sets a new standard for EVM development.We’ve built a strong and every-growing community of EVM builders. With 8.6k stars, 466 individual contributors and 4939 Pull Requests, Foundry is here to stay for the long term.
Fast code compilation and fast running test suits translate into short feedback cycles and allows developers and teams to ship products faster.
We performed benchmarks on the leading Solidity libraries to measure the time it takes to compile all contracts in each library. Our benchmarks show that Forge compilation is consistently faster than Hardhat by a factor of 2.1x to 5.2x, depending on the amount of caching involved.
Source: https://github.com/foundry-rs/foundry?tab=readme-ov-file#compilation-benchmarks
Faster tests means faster feedback cycles for developers. Our testing performance has seen a 2x improvement for invariant tests and unit/fuzz tests compared to v0.2. The following section on invariant tests will dive deeper into how we managed to significantly increase performance on invariant tests with v1.0.
We ran benchmarks with leading smart contract repositories to measure how long it takes to run test suites, including unit tests, fuzz tests, invariant tests and integration tests. The cached integration test also shows how effective Foundry is at repeated runs of forked tests ran at the same block height due to RPC caching.
Benchmarks were run using v1.0 vs v0.2 (nightly-de33b6af53005037b463318d2628b5cfcaf39916)
Fuzzing and tracking your code coverage are both crucial for smart contract security. Fuzzing helps developers discover edge cases by randomly generated test inputs. Running these tests can be computationally expensive, therefore Foundry v1.0 offers improved performance to ensure you can run your fuzz tests fast and seamlessly.
With the v1.0 release, Foundry is up to 40% faster execution time for fuzzing and code coverage. This enables developers to run more test cases in the CI without increasing cost, achieving a faster feedback loop during collaborative development.
Source: https://x.com/gakonst/status/1864060511253680180
To keep your smart contracts secure during fast-paced development, it is important to keep track which part of your codebase is covered by tests. With Foundry v1.0, forge coverage
helps you verify and track your code coverage up 3.5x faster. A comparison of v1.0 and v0.2 execution times for code coverage can be seen in benchmarks below:
Benchmarks for spark-psm project used 20 fuzz runs and a depth of 10 for invariant tests; for lockup and morpho-blue-bundlers forked tests were excluded.
Invariant testing ensures that critical assumptions of your system hold true across different states, it’s an important tool to help developers uncover logical bugs in their contracts.
When invariant tests fail, often the output are complex failure cases with several steps. Shrinking is the process of reducing the original counterexample while still preserving the failure. In the v1.0 release, the shrinking algorithm was rewritten with significantly better performance than in the previous implementation.
Benchmarks from the community demonstrate Foundry v1.0’s significant performance improvements compared to v0.2 and Echidna, with speed increases of up to 1000x. Echidna still performs better in more complex test scenarios like Unstoppable, primarily due to its coverage-guided fuzzing capabilities. To address this, coverage-guided fuzzing has been added to the Foundry roadmap for this year, in order to further improve performance on invariant testing.
While speed matters, what matters more is to be able to find the breaking sequence, with foundry v1.0 we’re successfully finding failing cases that v0.2 missed (such as in Unstoppable).
Tests were performed from solidity-fuzzing-comparison
By passing the --decode-internal
flag when debugging transactions with cast run
or running forge test
you can debug decoded internal calls, see state changes and track decoded event emissions to help you debug transactions more granularly.
Example of a Uniswap V4 swap. Source: https://github.com/foundry-rs/foundry/pull/8222
Another useful tool in our toolbox is to run forge test
combined with --flamechart
or --flamegraph
options, which visualizes expensive operations, deep call stacks and potential optimization targets.
Flamecharts helps visualize the gas usage over time, when each function is called (execution order) and how much gas it consumes at each step in the timeline.
Source: https://x.com/zerosnacks/status/1837142546436202968
Foundry v1.0’s improved tracing includes fully decoded calldata and return values for calls to external libraries, calls to fallback functions, state diffs for storage slots, balance changes, code modifications, and event emissions, giving you more visibility into your contract's execution path and interaction with dependencies. Below you can see an example of Foundry stack trace with storage changes, where counter (storage slot 0
) is changed twice, first time by explicitly setting to 9
and then incrementing to 10
.
Foundry now automatically saves the execution context and allows you to replay any failed test deterministically. This means you can quickly reproduce and debug any test failure and fix your tests faster.
Foundry v1.0 hugely improves the developer experience for large smart contract codebases by providing real-time testing execution progress with forge test --show-progress
:
For effective invariant testing, developers require metrics to gain more insights into what is actually being tested. With v1.0, we introduced detailed metrics to give you confidence in your test coverage by enabling invariant metrics in your foundry.toml
to get full visibility on the successful calls, revert rates, and discarded calls.
Source: https://x.com/lucasmanuel_eth/status/1854630498636878130
Most of the time, simply testing your smart contracts outputs isn’t enough. Cheatcodes let you manipulate the state of the blockchain, as well as test for specific reverts and events.
Gas optimization is critical for smart contract development. Our new gas snapshot cheatcodes let you measure gas usage with pinpoint accuracy, helping you identify and optimize your contract's hotspots. Gas snapshots are written to a snapshots
directory to be checked into .git
, allowing you to measure and evaluate the impact of your gas golfing over time.
Sometimes the fuzzer can uncover real, but anticipated errors in the contract under testing, especially when tests are performed against stateful forks. The assumeNoRevert
cheatcode allows to discard the current run and start a new fuzz run if the next call reverts.
Foundry v1.0 enhances expectRevert
test utility to allow checking the number of reverts expected from the upcoming calls and also to ensure a revert does not happen (expecting 0 reverts).
Some use cases, such as multi-chain deployments, may require advanced wallet management. Foundry v1.0 provides rememberKeys
cheatcodes to derive and save multiple wallets in the script environment, while getWallets
returns an array of addresses whose private keys are available in scripts:
Foundry v1.0 unlocks the possibility to deploy a contract through cheatcodes by fetching the contract bytecode from the artifacts directory. This can be done with the newly introduced deployCode
cheatcode, which can be called with the contract name or path to contract artifact.
Foundry v1.0 comes with getBroadcast
cheatcodes that allow accessing deployed addresses and details of prior broadcasted transactions. For example, after deploying a Counter
contract, the transaction hash and the address of the newly created contract can be fetched easily:
Additionally, two new cheatcodes getArtifactPathByCode
andgetArtifactPathByDeployedCode
help you to programmatically find artifacts that corresponds to each contract deployment:
For efficient testing and debugging, we developed cheatcodes for visualising the side effects of a transaction. This is done by recording state transitions using startStateDiffRecording
and then using getStateDiff
and getStateDiffJson
cheatcodes to fetch the diff of the chain state from before and after transaction execution, see an example below.
Note: in upcoming versions the output of state diffs cheatcodes will be improved to show decoded values.
Symbolic execution is a powerful technique that helps find edge cases by treating input variables as mathematical expressions to explore all possible execution paths. This can help identify subtle bugs like integer overflows, reentrancy vulnerabilities, and complex mathematical edge cases without having to explicitly write test cases for each scenario.
While it’s not built into Foundry v1.0, we made it easy to plug into your favourite symbolic execution tools, such as Kontrol or Halmos. Below is an example of what that looks like, using Kontrol to verify an OpenZeppelin ERC20's mint function behaves correctly for any address and any balance:
Take a look at Cheatcodes Reference in the Foundry book to explore all our cheatcodes and documentation.
The Ethereum Pectra hardfork is scheduled for March or April 2025 and will come with exciting features for the EVM such as enabling account abstraction (EIP-7702).
EIP-7702 unlocks features such as gas sponsorship, but also other use cases such as transaction bundling or granting limited permissions to a sub-key. This EIP introduces a new transaction type, allowing an Externally Owned Account (EOA) to function like a smart contract.
Forge
has supported EIP-7702 since October 2024 in order to enable developers to start prototyping with new features before they are available on the L1. To get started, just set evm_version="prague"
in foundry.toml
or pass --evm-version prague
as an argument.
With cast
, a user can sign an authorization that will delegate all calls to their address to the bytecode of smart contract:
With cast send --auth
you can send the signed authorization (or have it sent by another party which e.g. subsides gas). For more information check out the Odyssey examples for EIP-7702.
To run an EIP-7702 compatible node instance, the prague
hardfork can be used when starting Anvil: anvil --hardfork prague
Foundry v1.0 comes with a set of cheatcodes that can be used to sign EIP-7702 authorizations and delegate calls as EIP-7702 transactions: signDelegation
for generating a signed authorization,attachDelegation
for designating the next transaction as an EIP-7702 delegation and signAndAttachDelegation
that combines both signing and attaching into a single step, simplifying the delegation process.
Source: https://book.getfoundry.sh/cheatcodes/sign-delegation
EIP-7212 introduces a precompile for the secp256r1 elliptic curve, a curve that is widely used in protocols like Apple Secure Enclave and WebAuthn and essentially unlocks the ability to sign a transaction with your passkey.
Foundry v1.0 comes with a cheatcode signP256
which lets you easily sign a digest with a secp256r1 private key.
The Ethereum hardfork following Pectra is named Fusaka and will include a new series of EIPs known as EOF. The exact schedule is yet to be defined, however Foundry already gives developers the ability to try it out.
EOF aims to improve efficiency and security of smart contract deployment and execution. It introduces a new container format for smart contracts on the Ethereum blockchain.
To compile contracts with EOF, you can simply pass the --eof
flag.
Same --eof flag
can be used for deploying the contract.
To decode and inspect EOF container bytes, Foundry v1.0 comes with cast decode-eof option.
The screenshot below shows how the command returns the decoded response highlighting header and code sections to help understand how the contract bytecode is organized under the new format. For a deeper dive into EOF, checkout our EOF example.
With v1.0 we want to make Foundry's transition to a stable API with concrete guarantees for the community with regards to regular release cadence, clear timeline and migration paths and a versioned API.
Our release process is structured as follows:
master
contains nightly builds and new feature developmentsrelease
branches off for specific release candidates before a new stable releasestable
accommodates stable version releases which are made available via foundryup
Before any release
we will make the version available as release candidate and give the community the chance to test and share feedback with us. All our releases are attested & verified using Github artifact attestations for you to verify integrity of our binaries.
Migrating to v1.0 is easy with our migration guide.
While v1.0 represents a stable and mature toolkit, our vision for Foundry continues to evolve. We are particularly excited about the following features on our roadmap:
anvil
into reth-anvil
, by making use of Reth and bringing even more powerful local development capabilities with reth performance and features out-of-the-box.revm
.Just run the command to install foundryup
:
We’re hiring for the Foundry team. Reach out with your Github and resume to georgios@paradigm.xyz.
Foundry v1.0 would not be possible without our vibrant community of contributors and thousands of developers use Foundry daily, providing valuable feedback and pushing the boundaries of Ethereum development.
Copyright © 2025 Paradigm Operations LP All rights reserved. “Paradigm” is a trademark, and the triangular mobius symbol is a registered trademark of Paradigm Operations LP