Why release Foundry v1.0?

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.

What's New in Foundry v1.0?

  1. Faster code compilation: We ran our benchmarks with leading Solidity libraries. The v1.0 release includes significantly faster compilation up to 5.2x faster than alternative tools on the market, and >2x better than Foundry v0.2.
  2. Faster and deeper test coverage: Foundry v1.0 is 2x faster compared to foundry v0.2. Our benchmarks show improvements of up to 40% faster execution time for fuzzing and coverage tests.
  3. Better UX for Testing & Debugging: 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.
  4. New Cheatcodes: We’ve included new exciting cheatcodes for gas snapshots, testing & deployment and seamless integration with symbolic execution tools.
  5. Support for Pectra & Fusaka: We’ve added support for future EVM related EIPs to give developers the ability to start prototyping and work on projects that rely on these new features.
  6. More Stability & Reliability: We have stabilized APIs for long-term reliability, pointing 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.

Better Performance

Fast code compilation and fast running test suits translate into short feedback cycles and allows developers and teams to ship products faster.

Faster Code Compilation with forge build

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

Better testing performance with forge test

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)

Better performance for Fuzzing and Coverage

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.

Better Performance for Invariant Testing

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

Better Testing & Debugging UX

Improved tracing

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.

Replaying of failed tests

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.

Advanced Test Reporting and real-time metrics

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 :

Invariant Testing Metrics

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

New Cheatcodes

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 Snapshots

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.

Improved test revert handling

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).


Wallet utilities

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:

Code deployment

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.

Deployments and broadcasted artifacts

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:

State diffs

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

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.

Pectra

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: Set EOA Account Code

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.

Testing 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

RIP-7212: Precompile for secp256r1 Curve Support

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.

Fusaka

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 (Ethereum Object Format)

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.

Stability & Reliability

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 developments
  • release branches off for specific release candidates before a new stable release
  • stable 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.

How to Migrate to v1.0?

Migrating to v1.0 is easy with our migration guide.

What’s Next?

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:

  • We will boost performance of our local development node 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.
  • We will ship continued performance optimizations by integrating Solar- our fast, modular and contributor friendly Solidity compiler.
  • We will ship performance improvements on testing including improved fuzzing parallelism.
  • We will add new fuzzing and testing features like coverage guided fuzzing, symbolic testing out of the box and mutation testing.
  • Increased modularity and flexibility through integrating the latest version of revm.

Try out Foundry v1.0 today

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.

Acknowledgements

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.

Disclaimer: This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. This post reflects the current opinions of the authors and is not made on behalf of Paradigm or its affiliates and does not necessarily reflect the opinions of Paradigm, its affiliates or individuals associated with Paradigm. The opinions reflected herein are subject to change without being updated.

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