Blockchain Testing Frameworks Compared: Hardhat, Foundry, and More

Why this guide, now

In the past 18 months, we've seen some significant shifts in the world of Ethereum developer tools. So, back on December 20, 2023, ConsenSys officially put Truffle and Ganache to rest by archiving them. This move really encouraged teams to start shifting their focus more towards Hardhat and Foundry. Hey, have you heard about Hardhat 3? It just dropped a bunch of awesome new features! One of the coolest additions is the built-in coverage tool, plus there's a toolbox that really zeroes in on Viem. It's definitely worth checking out! On another note, Foundry has just released version 1. We're rolling out some cool updates! You'll get quicker invariant and fuzz testing, plus some awesome new cheatcodes to play around with.

If you're into Python, you'll be happy to know that things have really calmed down with Ape, especially now that Brownie's taken a backseat and is in a low-maintenance phase. If you're looking to find the best way to test your important smart contracts in 2025, it's a good idea to pause and really think through your options. You’ll see that the differences are pretty noticeable, so it might be time to make some adjustments. If you want to get the complete details, be sure to head over to consensys.io for all the info!

---

Executive summary for decision‑makers

If your team is really into TypeScript and you want a reliable plugin setup plus some flexibility when it comes to deployment, I’d definitely recommend checking out Hardhat 3. Pair it up with the Viem toolbox and Ignition for a great experience! Hey, just a quick reminder to make sure you include gas and coverage gates in your CI process! If you're looking for more info, check out this link: hardhat.org. It’s super helpful!

If your team is all about cranking up that test speed and wants to jump into fuzzing or invariant campaigns with a focus on Solidity, then you should definitely check out Foundry. It's fantastic for unit testing, fuzz testing, running invariants, and even working with local forks.
You might want to throw in some static and dynamic analyzers to get some extra insights. They can really help you see things from different angles! (getfoundry.sh).

A lot of high-assurance teams end up going with a hybrid setup. They rely on Foundry for the tests that need to be super quick and for checking invariants. Meanwhile, they turn to Hardhat for everything TypeScript-related and for integrating their infrastructure--like plugins, verifications, and scripted deployments. It’s pretty much the best of both worlds! On top of that, they usually count on Tenderly and Anvil forks to run some pretty comprehensive end-to-end checks. (github.com).

---

What changed since 2023

So, here's the scoop: ConsenSys has made the call to wrap up Truffle and Ganache. That means there won’t be any updates coming for these tools after late 2023. Just a heads up if you’ve been relying on them! You can still find the archives, but a lot of projects have shifted their focus to Hardhat and Foundry these days. If you’re curious to dive deeper into the topic, check it out here.

Hey there! So, Hardhat 3 just dropped, and it’s packed with some awesome new features. You’ll find native code coverage, a more straightforward configuration process, typed artifacts, and even some snazzy new toolbox options. Plus, you can pick between Viem or Ethers, which is pretty neat! Plus, Ignition is still the top choice when it comes to declarative deployment. Hey, if you're interested, you can find all the details right here.

• Foundry 1. X has really stepped up its game lately, showing off some impressive improvements in both compilation and invariant test performance. The entire toolchain, which includes the forge, anvil, cast, and chisel, really speeds things up while putting the spotlight on top-notch Solidity tests. Curious to learn more? Check it out here!

Hey, Python lovers, just a quick heads up: Brownie has announced that it’s no longer being actively maintained. The Ape Framework has quickly become the go-to choice for Python lovers everywhere! If you're looking for more details, just check it out here!

---

Hardhat 3, concretely (2025 state)

Hardhat: A Development Environment for JavaScript/TypeScript

Hardhat is an awesome development environment that's got all the tools you need to create on Ethereum. It's super powerful and makes the whole building process a lot smoother! It's got this really cool plugin system that makes it super easy to add new features and capabilities. Hey there! Take a look at what's fresh and exciting in 2025!

Key Features of Hardhat

• Flexible Plugin Architecture: Hardhat makes it super simple to boost your project with all sorts of features thanks to its awesome collection of plugins.
• Built-in Task Runner: Effortlessly automate your tasks and keep your development workflow smooth and efficient. No sweat required!
• Console and Debugger: Get ready to really dig into your contracts! With the built-in console and some awesome debugging tools at your fingertips, you'll have everything you need to troubleshoot and explore.
• Network Management: Handle several Ethereum networks with ease for testing and deployment. It's super straightforward!

Getting Started

First things first, let’s get Hardhat set up! You’ll want to install it to get started. Just run:.

npm install --save-dev hardhat

Once you’ve got that all set up, go ahead and kick off Hardhat by typing in:

npx hardhat

I'll help you get your project set up! Let's walk through the steps together.

Resources

• Hardhat Documentation
• GitHub Repository

If you’re ready to dive into Ethereum development, Hardhat is definitely a great option for you! It's got everything you need to get started on a solid foundation.

• You can quickly check your test coverage straight away, without any hassle. You can easily check your Solidity and TypeScript coverage with just one command--no need to mess around with any extra plugins! For more details, just head over to hardhat.org. Hey there! So, for your latest TypeScript projects, you can totally grab the Viem-based toolbox if you’re into that. But if Ethers.js is more your vibe, that’s a solid option too! This toolbox is loaded with all sorts of goodies, like assertions, network helpers, verification tools, and even support for Ignition deployments. It's got you covered for just about everything! (hardhat.org). Give Ignition a look for an incredibly smooth deployment process. You might really enjoy how easy it is! You've got resumable journals, fee limits for each network, and it even lets you run steps at the same time. It's pretty cool! (v2.hardhat.org). Check out the Hardhat Network--it’s packed with awesome features! You can play around with mainnet forking, impersonate accounts, and even mess with time and blocks. It's a fun way to experiment and get creative with your projects! You've also got some cool state mutators like setBalance and setStorageAt. They're super handy, especially with the tools that make it a breeze to use them in your tests! (v2.hardhat.org). Hey there! Good news for all you Solidity developers - debugging just became a whole lot simpler! You can now use console.log directly in your local simulator. How cool is that? No more guesswork! (hardhat.org).
• Hey there! If you're into gas analysis, you definitely don’t want to overlook the awesome gas-reporter plugin. It's just been updated to work with the Etherscan API v2, and trust me, it's a game changer! Sure, you've got some built-in coverage, but trust me, this tool is still really handy! Check it out here!

Example: Enable Coverage for Solidity and TS Tests

If you want to grab your coverage reports for your Solidity and TypeScript tests, just follow these simple steps:

1. Set Up Your Environment. Don't forget to install solidity-coverage for your Solidity tests! It's super important to have it set up. You can totally do this with npm!

npm install --save-dev solidity-coverage

2. Create a Coverage Script. Hey there! If you're looking to run a coverage tool, just hop into your package.json file and add a script for it. Here’s how you can do it:

You might want to include something like this in the "scripts" section:

"scripts": {
  "test:coverage": "your-coverage-tool-command"
}

Just replace your-coverage-tool-command with whatever command you usually use for coverage. Once that’s done, you can run it in your terminal with npm run test:coverage. Happy coding! Here’s a sample entry that you might find handy:

"scripts": {
  "coverage": "solidity-coverage"
}

1. Run Your Tests
   Now, you can easily whip up your coverage report just by running this:

   npm run coverage

2. For TypeScript Tests
   If you're diving into TypeScript, don’t forget to grab ts-node and ts-jest. These tools will really help you out when you're running your tests. Happy coding! If you haven't done it yet, go ahead and install these!

   npm install --save-dev ts-node ts-jest

3. Configure Jest
   To get your jest.config.js all set up for TypeScript, here’s what you need to do for things to run smoothly. Just make sure you’ve got the right configurations in there to handle TypeScript files without any hiccups. Here’s a basic configuration:.

   module.exports = {
     preset: 'ts-jest',
     testEnvironment: 'node',
     coverageDirectory: 'coverage',
   };

4. Run TypeScript Coverage
   If you want to get coverage for your TypeScript tests, just throw in a coverage command in your script like this:

   "scripts": {
     "test": "jest --coverage"
   }

Now, when you run:

npm test

You'll be pleased to see a detailed coverage report for your TypeScript files!

Awesome! You’re all set! Now you've got coverage enabled for both your Solidity and TypeScript tests. Happy coding!.

# Run all tests with coverage
npx hardhat test --coverage
# Or only Solidity tests
npx hardhat test solidity --coverage

So, this instrumentation takes place while the code is being compiled, and the cool part is that it works well with various versions of solc. Hey, just a quick heads up: the coverage bytecode you’re dealing with isn’t exactly the same as the stuff you'd see in production. So, it’s a good idea to steer clear of using those coverage builds when you’re trying to set your gas baselines. (hardhat.org).

Example: Fork Mainnet and Impersonate an Address Inside a Test

Alright, in this example, I’m going to show you how to fork the mainnet and pretend to be a certain address while you run your tests. It’s a handy technique, so let’s dive in! This is a really cool trick that lets you practice interacting with Ethereum addresses without having to worry about your real money. You can play around and get the hang of things all while keeping your funds safe!

Step 1: Setting Up Your Environment

Alright, before we dive in, let's make sure you've got all the tools you need handy. You’ll need:.

Make sure you've got Node.js installed on your computer.

• Hardhat is an awesome tool that's just right for diving into Ethereum development.

If you haven't gotten around to setting up Hardhat yet, no worries! You can easily do it by running this command:

npm install --save-dev hardhat

Step 2: Creating a Hardhat Project

Alright, let’s go ahead and kick off a new Hardhat project! In your terminal, run:.

npx hardhat

Just follow the prompts to get your project up and running!

Step 3: Forking the Mainnet

If you want to fork the Ethereum mainnet, you’ll need to grab an API key from either Infura or Alchemy. Once you've got that sorted out, you can go ahead and set up your Hardhat project to make use of it. Give your hardhat.config.js a little makeover like this:

require('@nomiclabs/hardhat-waffle');

module.exports = {
  networks: {
    hardhat: {
      forking: {
        url: 'https://YOUR_INFURA_OR_ALCHEMY_API_URL',
        blockNumber: 12345678 // Optional: Specify a block number to fork from
      }
    }
  },
  solidity: "0.8.4",
};

Step 4: Impersonating an Address

Alright, here comes the fun part! If you want to impersonate an address in your tests, you’ll want to tap into the Hardhat network’s handy impersonation feature. It makes things a lot easier! Here’s a simple way to get it done:

async function main() {
  const [signer] = await ethers.getSigners();

  // Replace with the address you want to impersonate
  const addressToImpersonate = '0xYourAddressHere';

  await network.provider.request({
    method: "hardhat_impersonateAccount",
    params: [addressToImpersonate],
  });

  const impersonatedSigner = await ethers.getSigner(addressToImpersonate);

  // Now you can interact with the blockchain as the impersonated address
  console.log(`Now using account: ${await impersonatedSigner.getAddress()}`);
}

main();

Step 5: Running Your Test

Go ahead and run your test using this command:

npx hardhat test

Once you run your tests, you'll start seeing logs that show you're interacting with the block just like the address you’ve pretended to be.

---

And there you go! You’ve just forked the mainnet and created an address for your testing. Pretty cool, right? This is a great way to make sure your code works seamlessly in real-life situations. Happy coding!.

import { test, expect } from "node:test";
import { defineConfig, network } from "hardhat";
import { setBalance, impersonateAccount } from "@nomicfoundation/hardhat-network-helpers";

test("whale transfer on a fork", async () => {
  await network.create({ // Hardhat 3 Network Manager API
    forking: { url: process.env.MAINNET_RPC!, blockNumber: 20800000 }
  });

  const whale = "0x1234...abcd";
  await impersonateAccount(whale);
  await setBalance(whale, 10n ** 21n); // 1000 ETH in wei

  const { ethers } = await network.connect();
  const signer = await ethers.getSigner(whale);
  await signer.sendTransaction({ to: await signer.getAddress(), value: 1n }); // noop send
});

You can totally use a similar method with Ethers or Viem! These helpers make it super easy by wrapping JSON-RPC methods like hardhat_impersonateAccount and hardhat_setBalance. It really simplifies things for you! If you want to keep things steady in your CI, just remember to set a pinned blockNumber. It's a simple step that makes a big difference! If you're looking for more info, just head over to hardhat.org and dig in!

When Hardhat is the Better Default

Hardhat is a really popular development environment for Ethereum, and it can be incredibly helpful for your projects. Here are a few reasons why this option could be a great fit for what you're looking for:

1. Flexibility

One of the coolest things about Hardhat is how flexible it is. You can totally tweak and expand your development process however you like! If you’re thinking about creating a complex decentralized application (dApp), Hardhat is a great tool that lets you customize everything just the way you want.

2. Built-in Tasks

Hardhat is packed with some handy built-in tasks that really make your workflow smoother. Looking to deploy contracts or test out your dApp? It's super easy! You can do it all with just one simple command.
It really cuts down on the time you spend on things, so you can put your energy into the fun parts--like coding those amazing features you’ve been dreaming about!

3. Advanced Debugging

If you’ve ever run into bugs in your smart contracts (and let’s be honest, who hasn’t?), you’re really going to love what Hardhat has to offer with its awesome debugging features. With the Hardhat Network, you can actually debug right in your IDE. This makes it super simple to spot and fix any issues that pop up.

4. Solidity Coverage

If you're looking to make sure your code is getting the thorough testing it deserves, you should definitely check out Hardhat's Solidity coverage plugin. It’s a handy tool that tells you just how much of your code is covered by your tests. Pretty cool, right? This way, you can rest easy knowing that you’ve covered all your bases.

5. Easy to Integrate

No matter if you’re working with plugins or linking up with tools you already have, Hardhat gets along with a bunch of different setups really well. It fits right in with popular libraries like ethers.js and web3.js, which means you can keep working in the setup you’re already used to.

6. Community Support

As our community of developers keeps growing, there are tons of resources and support out there to help you out if you hit any snags. Don't worry, you've got this! You'll find loads of tutorials and helpful documentation out there that walk you through all sorts of features.

7. TypeScript Support

Hey there, TypeScript lovers! You’ll be happy to hear that Hardhat has got you covered with built-in support. This means you can easily write your smart contracts and scripts using TypeScript, which is awesome because it gives you all the perks of type safety.

Conclusion

When it comes down to it, Hardhat could be the go-to option for a lot of developers. It's just really got that default vibe that makes it stand out. If you're diving into your next Ethereum project, you should totally think about it. It's super flexible, comes with handy built-in tasks and debugging tools, plus there's a solid community backing it up. Sounds pretty promising, right? Hey, if you’re looking to get started, definitely take a look at the Hardhat documentation. It’s a great resource to help you dive right in!

So, if you’re diving into some TypeScript projects, you might notice that having a good set of end-to-end tests is really important. Plus, it’s super helpful to have a reliable plugin ecosystem at your fingertips. Think about things like linting, verification, coverage, gas reporting, and TypeChain. These tools can make your life a lot easier! On top of that, using declarative deployments with Ignition can really give your DevOps team a clearer picture of what’s happening. Take a look at it over at hardhat.org. You might find it pretty interesting!

Emerging Practice: Secure Your Plugin Supply Chain

In today’s digital world, making sure your plugin supply chain is secure is super important. As more plugins hit the scene, it's super important to keep security in mind to safeguard your apps from any potential threats that might pop up.

Why Secure Your Plugin Supply Chain?

Keeping your plugin supply chain secure is super important, and it benefits you in a bunch of ways:

• Risk Reduction: When you take the time to verify the plugins you're using, you really cut down on the risk of adding any vulnerabilities to your systems. It’s like giving your setup a little extra safety check!
• Trust: When you use plugins that come highly recommended and have been thoroughly checked out, it really helps to build trust with your team and your users.
• Compliance: A lot of industries have to follow some pretty strict security rules, and that means making sure any third-party components are also secure.

Steps to Secure Your Plugin Supply Chain

Here’s a simple way to boost your security game:

1. Check Out Plugin Sources: It's super important to pick plugins from trusted sources. You want to make sure you’re using reliable ones! Make sure to look at the reviews and ratings, and don’t forget to check out the developers’ reputation too! 2. Stay Updated: Make sure you keep your plugins updated regularly. It’s a simple way to safeguard yourself against any known vulnerabilities. A lot of developers like to roll out patches pretty frequently. 3. Keep Plugin Use in Check: Stick to using only the plugins that you really need for your project. It’ll help keep things simple and efficient! Having fewer plugins really cuts down on the chances of getting attacked. 4. Set Up a Review Process: Before you dive into using a new plugin, it's a good idea to have a system to check out its security and functionality. This way, you can make sure it fits well with what you're doing! 5. Keep an Eye Out for Vulnerabilities: Make sure you stay updated on any fresh vulnerabilities that pop up related to the plugins you're using. If you’re looking for some handy tools, check out WPScan! It can really come in clutch.

Conclusion

If you want to keep your digital products safe from security threats, it’s a good idea to take some proactive steps to secure your plugin supply chain. It's all about making smart choices and being mindful of what you're adding to your tech stack. Just keep in mind that a solid supply chain does more than just keep your stuff safe - it also builds trust with your users.

Hey! Just a quick reminder: it’s really important to pin the specific versions of your community plugins in your package.json. And don’t forget to check the advisories regularly to stay on top of any updates! So, back in November 2025, there was quite a stir when a package called “hardhat-toolbox-viem-extended,” which is based on ENS naming, got flagged for some pretty sketchy preinstall actions. It's definitely a good idea to avoid any unofficial forks of original packages. You never know what kind of issues might come up! Take a look at the details right here: GitLab Advisories.

---

Foundry 1.x, concretely (2025 state)

Foundry is a Rust-based toolchain that's designed for speed and specifically built for testing with Solidity in mind.

• forge: It's got a bunch of features like unit tests, fuzz tests, and invariant tests all bundled in. Plus, you’ll find an integrated gas report and coverage, not to mention an interactive debugger that works smoothly with CI tools. Pretty handy stuff! Check it out here!.
• anvil: If you're looking for a super speedy local EVM experience, this is your best bet! It has a bunch of cool features like RPC forking, impersonation, blob/KZG, beacon endpoints, and even lets you create custom JSON-RPC methods that work seamlessly with Hardhat. If you're looking for more details, just check this out here. It's got all the info you might need!
• Chisel: This cool Solidity REPL is perfect for testing out your code snippets without all the fuss of setting up an entire project! Why not give it a spin? Check it out here!
• Performance: The official benchmarks show some really impressive improvements across various builds and tests. According to Paradigm’s v1. Hey there! Just a quick heads up: we’ve got an announcement coming up, and the compilation might be around 2. Stay tuned! 1 to 5. It's about twice as fast as Hardhat in their library tests! Just remember to check it against your own codebase to confirm the results. If you want to dive deeper into the details, just hop over to this link. You'll find what you're looking for!

Example: A Simple Invariant Test for Random Sequences

When you're playing around with random sequences, it's super important to make sure that some key properties stay consistent. Here's a simple test you can try out to see if everything is consistent.

The Test

The plan is pretty simple: we’re going to go through the random sequences and check to make sure that a certain condition holds true all the time, regardless of what happens.

How to Implement

Here’s a little code snippet to help you kick things off:

import random

def invariant_test(sequence):
    # Check that the sum of the sequence is always greater than zero
    return sum(sequence) > 0

# Generate random sequences
for _ in range(10):
    random_sequence = [random.randint(-5, 5) for _ in range(10)]
    print(f"Sequence: {random_sequence}, Invariant holds: {invariant_test(random_sequence)}")

What to Look For

• The Condition: So, in this scenario, we're focusing on adding up the numbers in the sequence. If it’s not above zero, then something’s definitely not right.
• Running the Test: So, when you’re generating those sequences, just remember that the invariant needs to stay consistent throughout all of them. Stay on the lookout for any surprises that might pop up!

This test is a great way to kick things off when it comes to checking how stable properties are in random data. Happy coding!.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "forge-std/Test.sol";

contract Vault {
    mapping(address => uint256) public balance;
    function deposit() external payable { balance[msg.sender] += msg.value; }
    function withdraw(uint256 amount) external { require(balance[msg.sender] >= amount, "insufficient"); balance[msg.sender] -= amount; (bool ok,) = msg.sender.call{value: amount}(""); require(ok); }
}

contract VaultInvariants is Test {
    Vault vault;
    function setUp() public { vault = new Vault(); }

    // Handlers: forge will randomize callers and inputs on target contracts
    function invariant_totalConserved() public {
        // Sum of all balances must equal contract balance
        // (for brevity, we only check caller's view and contract balance here)
        assertEq(address(vault).balance, vault.balance(address(this)));
    }
}

Hey, it seems like you just typed "Run:". Hey there! Could you give me a little more detail on what you're curious about or what you want to add? That way, I can help you out more effectively!

forge test --mt invariant_ --ffi -vvv

To help you scale your campaigns, make sure to include [invariant] runs and depth in your foundry.toml file. Trust me, it’ll make a big difference! Focusing on invariants that highlight conservation or monotonic properties is definitely a solid approach. Foundry offers some solid configuration options for setting up invariants, and it even has the cool feature of fuzz shrinking. If you want to dive deeper, go ahead and take a look at the documentation right here. It’s got all the info you need!

Example: Gas Snapshots and Coverage You Can Gate in CI

When you're handling your smart contracts, it's really crucial to keep track of gas usage and make sure your code is top-notch. A really convenient way to go about this is by adding gas snapshots and coverage checks directly into your Continuous Integration (CI) workflow. It makes everything smoother and keeps everything in check!

Gas Snapshots

Gas snapshots give you a handy way to keep an eye on how much gas your contracts are using as time goes by. If you take snapshots every time there's a big change, you'll be able to easily catch any surprising spikes in gas costs. By taking this proactive approach, you not only save on gas fees but also keep your users feeling happy and satisfied!

If you want to set up gas snapshots in your CI, you’ll want to check out the hardhat-gas-reporter package. It makes the whole process a lot easier! Let me give you a quick overview of how to get it all set up:

1. First, install the package:.

npm install --save-dev hardhat-gas-reporter

2. Next up, you'll want to tweak your Hardhat configuration file, which you can usually find as hardhat.config.js:

require('hardhat-gas-reporter');

module.exports = {
  gasReporter: {
    enabled: true,
    currency: 'USD',
    gasPrice: 21,
  },
};

3. From now on, whenever you run your tests, you'll receive a detailed report on how much gas you're using.

Coverage

Besides keeping an eye on your gas usage, it’s really important to make sure your smart contracts are solid and thoroughly tested. And that’s where coverage really kicks in. With tools like solidity-coverage, you can quickly check which parts of your code have been tested and which ones might need some extra attention. It’s a great way to make sure you're not overlooking any important bits!

Alright, let’s dive into how you can add coverage to your CI setup!

1. Install the solidity-coverage package:.

npm install --save-dev solidity-coverage

2. Alright, let’s tweak your Hardhat configuration next!

require('solidity-coverage');

module.exports = {
  // Your existing configuration
};

3. Alright, now let’s go ahead and run the coverage command!

npx hardhat coverage

This will create a coverage report that shows how effective your tests are. You can set up your continuous integration (CI) system to fail builds if the code coverage falls below a certain level. This way, you can keep the quality of your code in check!

Conclusion

If you start adding gas snapshots and coverage checks to your CI workflow, you’ll be doing yourself a favor by keeping those costs down and making your smart contracts way more reliable. It's a win-win! It's really all about making your development process easier and more efficient!

# Produce and diff gas snapshots across PRs
forge snapshot --check --tolerance 1

# Coverage summary/LCOV for CI
forge coverage --report summary --report lcov

Snapshots give you a bit of wiggle room with PR budgets--about ±1%, which is super convenient! Plus, LCOV can easily hook up with CI dashboards, making the whole process a breeze. Take a look at this link: getfoundry.sh. You might find it really useful!

Example: Deterministic Mainnet-Fork Test with Impersonation

Let me give you a simple example of how to run a deterministic mainnet-fork test using impersonation. It's pretty straightforward! This is super useful if you want to see how things might go on the mainnet without actually messing with it.

1. Setting Up the Environment. First things first, double-check that you've got your environment all set up with the necessary libraries. If you haven't done this yet, you'll definitely want to go ahead and install the following: bash npm install --save-dev hardhat @nomiclabs/hardhat-ethers ethers

2. Creating the Test Script. Alright, the next step is to whip up a new test script in your test directory. Let’s call it mainnet-fork-test.js. Just pop that file in there! In this file, you’ll be putting together your test code. It could end up looking a bit like this: ```javascript const { ethers } = require("hardhat");

 describe("Mainnet Fork Test", function () {
     it("should impersonate an account on mainnet", async function () {
         // Specify the account address you want to impersonate
         const accountToImpersonate = "0x1234567890abcdef1234567890abcdef12345678";
         
         // Start the impersonation
         await network.provider.request({
             method: "hardhat_impersonateAccount",
             params: [accountToImpersonate],
         });

         const signer = await ethers.getSigner(accountToImpersonate);
         // Now you can interact with the blockchain as if you were that account!
         
         const balance = await signer.getBalance();
         console.log(`Balance of the impersonated account: ${ethers.utils.formatEther(balance)} ETH`);
         
         // Don't forget to stop impersonation afterwards
         await network.provider.request({
             method: "hardhat_stopImpersonatingAccount",
             params: [accountToImpersonate],
         });
     });
 });
 ```

1. Running the Test Alright, now it's time to give it a spin with Hardhat! Just go ahead and run the test.

   npx hardhat test

Once you have everything all set up and you've run the test, you should be able to see the balance of the account you're pretending to be displayed right there. It's a cool way to see how things would play out on the mainnet without any actual risks!

anvil --fork-url "$MAINNET_RPC" --fork-block-number 20800000 --auto-impersonate

So, when it’s time for you to take your test:

vm.startPrank(0x1234...abcd); // impersonate a whale
// ... exercise protocol paths ...
vm.stopPrank();

Anvil definitely borrows some ideas from Hardhat, especially with its impersonation features. They've even added some cool options, like the --auto-impersonate flag, which makes things a bit easier! Don't forget to pin the fork block so everything stays consistent! Hey, take a look at this! You can check it out over at getfoundry.sh. Let me know what you think!

When Foundry is the Better Default

Picking the right platform for your project can feel like solving a tricky puzzle. You know, sometimes Foundry really shines as the go-to option for a default setting. Let me share a few reasons why it could be worth your while to think about it.

1. Streamlined Development

Foundry gives you a more straightforward and user-friendly workspace, letting you concentrate on what truly counts--your code! With such a powerful set of tools, you’ll get:

• Fast compilation times
• Efficient testing frameworks
• Comprehensive debugging tools

If you want to really get into the nitty-gritty of its features, take a look at the Foundry documentation. It’s definitely worth a read!

2. Versatility with Programming Languages

One of the really awesome things about Foundry is that it works with a bunch of different programming languages. No matter if you're a fan of Solidity, Yul, or even some custom languages you’ve cooked up, Foundry has your back. It lets you play to your strengths and work in a way that feels right for you! This flexibility really lets you roll with the punches when it comes to what your project needs.

3. Community and Support

One of the great things about Foundry is the lively community that’s built around it. It really makes a difference! No matter if you're dealing with a particular problem or just hunting for some solid tips, there are tons of resources out there to help you out! Don't forget to connect with other developers on platforms like Discord or dive into the conversations happening over on GitHub. It's a great way to share ideas and learn from one another!

4. Compatibility and Integration

One more reason to consider Foundry is that it plays nice with other tools and platforms. It fits right into your current workflows, so there's no need to start from scratch. On top of that, it's got EVM support, which means your projects can easily connect and play nicely with other ones out there in the ecosystem.

5. Cost-effectiveness

Using Foundry can really help you save some money! Because it’s open-source, you can relax knowing there are no licensing fees or any sneaky hidden costs to deal with. This is a great budget-friendly choice, especially for startups and indie developers who are just trying to get their footing.

Conclusion

To put it simply, Foundry could totally transform the way you work on your projects. If you're after a platform that's efficient, flexible, and has your back, this might just be what you're looking for. With all its cool features and the awesome support from the community, trying it out as your go-to option might just kickstart some really exciting projects for you!

So, you're really into keeping those test cycles short, right? You like the idea of native fuzz testing or maybe trying out invariant testing too. Plus, it sounds like auditor-style workflows that focus on Solidity tests are right up your alley! And let’s be real--you totally enjoy using those cheat codes like vm.prank, vm.warp, vm.roll, vm.deal, and vm.mockCall. Plus, you get to skip all the annoying Node.js overhead. How awesome is that? If you want to dive deeper into the details, just click here! You'll find all the info you need over there.

---

“Ape,” Brownie, and other frameworks you’ll be asked about

• Ape (Python): This tool is a really cool and modern command-line interface that lets you use plugins and manage multiple network sessions all at once. Whether you're messing around locally, testing things on testnet, or diving into the mainnet, Ape has got you covered! It's packed with some really useful features, like tracing and gas reporting, and it even works seamlessly with Jupyter. If you're part of a Python quant team or working with data science notebooks, this is definitely a great pick! Take a look at this cool site: apeworx.io. You might find something interesting there!
• Brownie: Just a quick note--it's still around in some older systems, but fair warning: it's not actively maintained anymore. If you're on the hunt for a Python solution right now, I’d suggest checking out Ape. Another option is to run Foundry or Hardhat with some Python scripts. Both could do the trick! If you’re looking for more details, just hop over to pypi.org.

---

Security testing stack: beyond unit tests

High-assurance teams mix their framework with three different kinds of security tools:

1. Static analysis is a great way to do quick checks without breaking the bank, especially when you're integrating it into your continuous integration (CI) process.

• Slither: This tool is pretty awesome! It comes with some cool modern detectors, works smoothly with GitHub Actions, and even gives you SARIF output to help you scan your code. On top of that, you can use your own custom plugins and even set up fail-on severity thresholds! Make sure to include this in your workflow--it’s a game changer you won’t want to skip! Take a look at this link: github.com. You might find it interesting!

2) Property-based fuzzing (catch those logic bugs early)

• Foundry: This handy tool has built-in features for fuzzing and invariant testing, so you can tackle both unit tests and stateful tests with ease. You can use invariants for a bunch of different things! They come in handy for stuff like making sure supply is conserved, working with AMM invariants, setting up permission models, and keeping track of escrow accounting. Check it out here.
• Echidna (Trail of Bits): So, Echidna is this awesome standalone property fuzzer that plays really nicely with GitHub Actions. Plus, it comes with a cool shrinking feature that helps streamline your testing process! It’s really helpful for making sure the invariants you set up in Foundry are all in order. Check out its GitHub page when you get a chance!

3) Symbolic/Concolic Analysis (more in-depth but pricier)

Hey, you should definitely take a look at Manticore by Trail of Bits and Mythril from ConsenSys Diligence. They're both pretty cool tools! These tools really get into the nitty-gritty of the code by checking out different paths in a symbolic way. They really come in handy when you're grappling with tricky stuff like complex authorization, pauses, or upgrades. You know, those moments when fuzzing just seems to hit a dead end. You can check out Manticore right here.

Example: Minimal CI Matrix (GitHub Actions)

If you're jumping into Continuous Integration (CI) with GitHub Actions, creating a simple CI matrix is a fantastic way to kick things off! Alright, let's dive into a simple example that you can tweak and make your own for your projects. It’s really straightforward!

Setting Up the Workflow

To get started, go ahead and create a new YAML file in your directory. github/workflowsdirectory. How about calling it something likeci.yml`? Check out this simple template for a minimal Continuous Integration (CI) matrix that tests your code across different versions of Node.js:

name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [12, 14, 16]

    steps:
    - uses: actions/checkout@v2
    - name: Set up Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v2
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm install
    - run: npm test

Breakdown of the Workflow

• name: This is where you can label your workflow. Just pick a name that makes sense to you! Around here, we like to refer to it as "CI." ".
• on: This part lets you know what kicks off the workflow. Here, we're talking about things like pushes and pull requests.
• jobs: This is where you’ll lay out all the tasks that need to get done.
• build: This is the name for your job, and you can choose whatever you like!
• runs-on: This is where you let GitHub Actions know to go ahead and use the latest version of Ubuntu for the setup.
• strategy.matrix:
• node-version: Here’s where we list the Node.js versions we’re going to test with--specifically 12, 14, and 16.
• Steps: Alright, let’s break down what goes on in each step:
• checkout: We grab the code from the repository.
• setup-node: This step is all about getting the right version of Node.js up and running.
• npm install: This command will set up all the necessary dependencies for you.
• npm test: This command will kick off your tests.

Customization

Go ahead and adjust the node-version array to include the versions that are most relevant for your project. If you have any extra checks or build processes to run, don’t hesitate to throw in some more steps!

Next Steps

After you’ve got everything set up, just push your changes or create a pull request and let the Action work its magic! If something goes wrong, you'll get feedback right in your pull request, which makes it really easy to tackle any issues right away.

Go ahead and give it a shot! Happy coding!

name: ci
on: [push, pull_request]
jobs:
  slither:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: crytic/slither-action@v0.4.1
        with:
          fail-on: medium
  foundry:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: curl -L https://foundry.paradigm.xyz | bash
      - run: foundryup
      - run: forge build
      - run: forge test --gas-report
      - run: forge coverage --report summary
  hardhat:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx hardhat test --coverage

With Slither, you’ll have access to static gates, which is pretty neat. You can also run quick fuzz and unit checks using Foundry. And if you’re into TypeScript, you’ll love how it integrates with Hardhat, plus you’ll get those nice coverage checks too! Feel free to tweak the fail-on severities and adjust your gas or coverage thresholds for every repository. Take a peek at this: (github.com).

---

Hardhat vs. Foundry head‑to‑head: what matters in practice

• Speed When it comes to compiling and testing, Foundry often takes the lead. With Rust and its awesome built-in tools, you can look forward to compile times that are roughly 2 to 5 times faster, especially in projects that rely heavily on libraries. It's pretty impressive how much time you can save! Absolutely! Just keep in mind that the results might differ depending on your specific codebase and how you're handling caching. So, it’s definitely worth running some tests with your own CI runners to see how it all shakes out! (paradigm.xyz).
• Test Depth Foundry really stands out with its awesome built-in fuzzing and invariant testing tools. Plus, those cheat codes are super helpful for really digging into property tests! Hardhat can definitely get pretty deep, but you'll need to lean on some plugins or other outside tools to make that happen. (getfoundry.sh).
• Ecosystem Integration So, you know Hardhat's toolbox model? It's pretty awesome! It comes packed with cool tools like Viem/Ethers, TypeChain, a gas reporter, and verification. All of these really click with TypeScript stacks and make setting up infrastructure pipelines a breeze. This really makes things easy, whether you're setting up with Ignition or just connecting different tools together. (hardhat.org).
• Debuggability When it comes to debugging, Hardhat really shines with its Solidity console.log feature and stack traces. They provide a down-to-earth way to tackle issues. But Foundry definitely holds its own! It comes with some cool features like tracing, an interactive debugger, and Chisel, which lets you run REPL experiments on the spot. This makes troubleshooting a breeze! (hardhat.org).
• Fork Testing So, both Foundry and Hardhat let you fork and impersonate users, which is pretty cool. But Anvil really steps it up with some extra flags that make things even easier! In the meantime, Hardhat has rolled out some cool features in v3, like ergonomic Network Helpers and the Network Manager API. These additions really simplify the process of pinning block numbers, which is super handy for keeping your CI predictable and reproducible. (getfoundry.sh).

---

Practical patterns you can adopt this quarter

1) Hybrid Repo Layout for Speed and Ergonomics

If you're looking to set up your repositories, going for a hybrid layout can really make things faster and simpler for you. It's really about striking the right balance between getting great performance and making the developer experience as smooth as possible. Let’s dive into why a hybrid repository could be the perfect choice for you!

What is a Hybrid Repo?

A hybrid repo is basically a mix of both mono-repositories and multi-repositories. It takes the best of both worlds! So, you really get the best of both worlds here! You can enjoy easy management while still having the freedom that comes with keeping your codebases separate. It's like hitting the sweet spot!

Benefits of a Hybrid Layout

• Speedier Builds: If you set up your code smartly, you can really cut down on those build times. It's all about that clever organization!
• Smoother Navigation: Developers can easily track down what they’re looking for without having to sift through a bunch of unrelated code.
• Easier Teamwork: Team members can dive into their own sections of the project without getting in each other’s way.

How to Set It Up

Getting a hybrid repo up and running isn’t all that tricky. Here's a handy little guide to help you kick things off:

1. Identify Modules: Start by breaking your project into bite-sized pieces. This way, you'll have smaller, more manageable modules to work with. 2. Pick a Structure: Figure out what parts should go in a mono-repo and which ones can stand alone in their own separate repos. 3. Set Up CI/CD: Let’s get those continuous integration and delivery pipelines in place, customized just for your hybrid setup.

Real-World Examples

A lot of well-known tech companies are jumping on the hybrid repo bandwagon to help them grow their operations. Companies like Google and Facebook have really hit the nail on the head by adapting their repo strategies to suit their specific needs. They’ve been mixing and matching their approaches, and it’s definitely paying off for them!

So, to wrap it up, if you’re looking to boost your speed and make your workflow more user-friendly, definitely give a hybrid repo layout a go! It could really change the game for how your team operates.

• Keep a Foundry project right at the top level for all your Solidity tests, fuzzing, invariants, gas snapshots, and coverage. It just makes everything easier! Alright, let’s get started by setting up a Hardhat subproject for your TypeScript integration tests. You’ll also want to include some plugin-based checks like linters and gas reporters, along with verification processes and Ignition deployment modules. Trust me, this will make your workflow a lot smoother!

Directory Sketch:

Let me give you a fast overview of what our directory is going to look like.

Structure

• Root Directory: Think of this as the starting point for everything.
  It includes all the key folders.
• Images: Here’s where all our photos are stored.
• Logo: You’ll find our branding icons in this folder.
• Screenshots: Here’s the spot for all our screenshots!
• Documents: This is where all the important documents are stored.
• Reports: You can find all of our past and current reports right here.
• Forms: Just a quick reminder to peek into this folder for any forms we might need. Thanks!
• Code: Our codebase is hanging out right here.
• Frontend: This is where all the magic happens for the user interface! Everything that users interact with is stored right here.
• Backend: This folder contains all the server-side stuff you'd need.
• Assets: These are the extra goodies you get!
• Fonts: Check out this folder for any special fonts we’re using!
• Videos: This is where you’ll find all the video content.

Quick Links

• GitHub Repository
• Shared Drive
• Project Tracker

Notes

• Just a quick reminder to keep the directory neat and tidy! Make sure to keep your documents and code up to date with any changes regularly. Hey, just a friendly reminder to back up all your stuff before the month wraps up! It's always good to have everything safe and sound.

/contracts
/foundry.toml
/test (Foundry .t.sol)
/script (Foundry deploy/scripts)
/hardhat
  hardhat.config.ts
  ignition/modules/*.ts
  test/**/*.test.ts

If you're looking to reuse your node_modules, you can easily do that by using Foundry’s --hardhat layout flag. It's super straightforward! If you want to dive deeper into the details, check it out here. You'll find all the info you need!

2) CI Thresholds That Actually Fail When They Should

When you're diving into Continuous Integration (CI) systems, you know that things can get a bit tricky sometimes. You might find yourself dealing with some really frustrating situations along the way. One situation that really gets to me is when your CI thresholds go haywire for reasons that just don't make any sense. Here are a few important things to keep in mind:

• The Thresholds Can Be Too Strict: You know, sometimes the thresholds for your CI are just way too sensitive. It can get a bit frustrating, right? If they're calibrated too tightly, even minor problems can cause a failure. It's kind of like getting called out for a little slip-up that doesn’t really matter in the grand scheme of things.
• Inconsistent Results: You might notice that the results can vary quite a bit from one build to another, and that’s totally normal! It's crazy how what works perfectly one day can totally flop the next. It’s super frustrating for developers who are just trying to keep everything on track!
• False Positives: Sometimes, you might run into situations where the CI doesn’t quite work because of minor issues--almost like those annoying "false alarms." "These issues can end up wasting a lot of time because your team might be rushing to fix something that isn’t really broken at all."
• Lack of Clarity: When those error messages roll in and they're just vague or confusing, it’s like trying to navigate through a foggy ocean without a map. You just feel adrift, unsure of what to do next. Getting clear and straightforward messages is super important. They help us pinpoint exactly where the issue is and what we need to do to sort it out.
• Time for a Check-Up: It's a good idea to regularly take a look at the CI thresholds and tweak them as needed. With the codebase evolving and the team's input coming in, keeping things updated will help everyone out. We can’t really take a one-size-fits-all approach with this.

If you're feeling like your CI process is more of a roadblock than a smooth ride, it might be a good idea to take a step back and reevaluate those thresholds.
Just a few small adjustments can really help cut down on those annoying setbacks and keep your development process running smoothly.

• Foundry: Run forge snapshot --check --tolerance 1 to catch those sneaky gas regressions that can creep in without a heads-up. It's a handy little trick to keep things in check! To check your coverage, just run forge coverage --report summary. Don't forget to keep an eye on your minimum line and branch targets while you do!
• Hardhat: If you want to check how much of your code is covered by tests, just run npx hardhat test --coverage. It's super easy! It's definitely smart to establish some minimum coverage requirements in your linter and PR checks. It helps keep everything consistent and ensures that your code meets a decent standard before it gets merged! And hey, make sure to take advantage of the gas-reporter with the Etherscan API v2! It’s super handy for keeping an eye on L1 and L2 costs while you’re working through your PRs. Trust me, it’ll save you a lot of headaches down the line! (getfoundry.sh).

3) Deterministic Fork Harnesses

Deterministic fork harnesses are super important for managing those different branches in your code. They really help keep your testing environment consistent, and that’s crucial for getting reliable results. Let me break it down for you--here's the scoop on what they are and why they might come in handy!

What Are Deterministic Fork Harnesses?

So, let’s break down what deterministic fork harnesses are. Essentially, these are specialized setups designed to handle forks in processes or workflows--think of them as the safety nets that keep everything running smoothly. When you encounter a fork (which is just a point where a process can go in different directions), a deterministic fork harness helps ensure that no matter which way things go, the outcomes are predictable and reliable.

It's kind of like having a well-organized plan in place when you hit a crossroads; you know that regardless of the path you take, you’ll still reach your end goal without any surprises. It’s a nifty way to manage complexity and keep things on track, especially when you’re dealing with loads of data or intricate systems. Hope that clears things up a bit!

Basically, a deterministic fork harness lets you run experiments or tests in a really organized manner. It guarantees that every time you run your tests, you'll consistently get the same result, no matter how many times you do it. This is super important when you're working with branches in your codebase.

Why Go for Deterministic Fork Harnesses?

So, let’s dive into why you might want to consider using deterministic fork harnesses. First off, they provide a reliable way to handle the complexities that come with forking, making your life a whole lot easier. You get consistent outputs every time, which is super important when you’re working on projects that require precision.

Plus, they’re all about reducing errors. By having a solid framework in place, you can minimize the chances of unexpected issues cropping up later on. And we all know how frustrating it can be to deal with those last-minute surprises!

Another big perk is that they help streamline your workflow. With everything arranged neatly, you can focus more on the fun parts of your project instead of getting bogged down by technical hiccups.

In a nutshell, if you're looking to simplify your development process while boosting reliability and efficiency, deterministic fork harnesses might just be the way to go!

• Consistency: When you use deterministic harnesses, it makes it super easy to get the same results every time. This is really important in software development!
• Debugging: You know, it really makes debugging a whole lot simpler when you can count on the environment being consistent each time. So, this basically lets you zero in on solving problems without getting bogged down by inconsistencies.
• Collaboration: When you're part of a team, it's super important that all your tests yield the same results. Consistency is key! Deterministic harnesses really help keep everyone aligned and in sync.

A Guide to Setting Up Deterministic Fork Harnesses

So, you want to dive into implementing deterministic fork harnesses? Awesome! Let’s break it down step by step to make it easier for you.

First off, it’s important to know what a deterministic fork harness is. Basically, it’s a setup that helps ensure your system behaves consistently, even when things get a bit chaotic. This can be super handy in testing and development.

To get started, you’ll want to gather your tools and environment. Make sure that you have all the software and dependencies you need ready to go. This might seem like a drag, but trust me, having everything lined up makes the process way smoother.

Next, you’ll need to set up your harness. Start by configuring the parameters that determine how your system will fork and handle branches. Take your time here; getting this right is key to ensuring that everything runs as it should.

Once that’s done, you can begin to implement your tests. Run through different scenarios to see how well your harness holds up when faced with various conditions. This is your chance to catch any potential issues before they become a headache down the line.

Finally, don’t forget to document everything! Keeping a record of your setup and the tests you performed will save you a ton of time later on. Plus, it’ll help anyone else who might work with your harness in the future.

And there you go! With these steps, you’re well on your way to implementing deterministic fork harnesses like a pro. Good luck, and have fun with it!

Let me give you a quick rundown on how to set up these harnesses. It’s pretty straightforward!

1. Outline your test cases: Make sure to clearly specify what you're aiming to test and the conditions for each. 2. Set your environment variables: Make sure all the variables that impact your code are the same during your tests. This consistency is key! 3. Stick to the same data: Make sure to use the same datasets throughout your testing. This way, you can keep things consistent and minimize any differences in your results. 4. Keep a record of everything: Make sure you take detailed notes on your frameworks and test cases. This way, it'll be a breeze for others to follow in your footsteps and get the same results you did.

Example

Alright, here's a quick little code snippet to help you set up a straightforward deterministic fork harness:

import random

# A simple function that generates a random number
def generate_random_number():
    return random.randint(1, 100)

# Using a seed to make the random number generation deterministic
random.seed(42)
num1 = generate_random_number()
random.seed(42)
num2 = generate_random_number()

print(num1, num2)  # This will always print the same numbers

So, when you use random.seed(42) in this example, you're basically setting things up so that you get the exact same random number every time you run that code. It's like you're giving your code a little nudge to keep things consistent!

Conclusion

Deterministic fork harnesses are a total game changer when it comes to testing during development. They really offer the stability and consistency you need, making debugging and working together way simpler and more enjoyable. If you work these into your routine, you'll definitely save yourself some time and avoid a lot of headaches later on.

Choose one RPC provider and lock down those block numbers. Don't forget to get familiar with the contract addresses you rely on--like those big token holders, oracles, and timelocks. It's all about warming them up! Both Anvil and Hardhat Network give you the ability to impersonate accounts and tweak the state, which is pretty handy! To keep your tests organized and focused, it’s smart to wrap these actions in some helper functions. This will help prevent your tests from going off the rails. Hey, if you're looking for more info, definitely swing by getfoundry.sh! It’s packed with useful stuff!

4) Defense-in-depth testing

Defense-in-depth testing is basically about stacking up your security measures to build a tougher barrier against any potential threats out there. It's like putting on multiple layers of clothing to stay warm--you just feel a lot safer that way! Rather than putting all your eggs in one basket, it's smarter to build up a bunch of layers to keep your systems and data safe.

So, here’s the deal:

1. Multiple Security Layers: Picture it like an onion--though honestly, an ogre is a more fun comparison! Just like how an ogre has all those layers, good security has multiple layers too. Think of it like an onion--you’ve got these different layers that you can peel back, and each one serves as a barrier protecting you from potential threats. This could cover a bunch of things like firewalls, intrusion detection systems, anti-virus software, and a whole lot more.

2. Redundancy: If one layer goes down, no need to stress! The next one's got your back and will stop any intruders in their tracks. Having this redundancy is super important because it really makes it difficult for attackers to break in.

3. Regular Testing: Think of it like checking your smoke detectors at home. You’ve got to regularly test each layer to make sure everything’s running smoothly and doing its job. Go ahead and set up those tests, and make sure to run them thoroughly!

4. Incident Response Planning: So, no matter how many security measures we put in place, breaches can still happen. That’s why it’s super important to have a good incident response plan in place! Make sure your team is totally clear on what to do if anything goes sideways.

5. Continuous Improvement: You know, security isn’t just a one-and-done deal. It’s something we need to keep working on all the time. Make sure you’re always in the loop with the latest threats and keep tweaking your defenses as needed.

Adding defense-in-depth testing to your security strategy can really boost your shield against cyber threats. It’s like layering up for winter - the more layers you have, the warmer (and safer) you stay! If you're looking to boost your security game, definitely take a look at this awesome resource. It's packed with helpful tips!

Hey there! Just a quick reminder - when you’re diving into those critical contracts, don’t forget to write down at least three invariants for each one. You’ll want to cover conservation, authorization, and bounds (like slippage or price limits). Trust me, it’ll save you some headaches later on! You might want to run these invariants through Foundry and Echidna. It’s a smart way to catch any potential biases in your generator. Let’s definitely make Slither a must-have CI gate too! If you're dealing with Mythril or Manticore, it’s a good idea to use them selectively--especially when you're working with upgradeable proxies, automated market makers (AMMs), or any of your unique calculations. Just a little heads up! If you're curious to learn more about it, just click here! There's a ton of info waiting for you. Happy reading!

5) Supply Chain Hygiene

Keeping the supply chain in good shape is super important for making sure everything flows well and stays safe at every stage. Alright, let’s break it down! Here are the key things you should keep your eye on:

• Regular Audits: Try to get into the routine of doing regular check-ups on your supply chain partners. It’s a great way to keep everything running smoothly! This can help you catch any issues before they turn into big headaches!
• Keep the Conversation Going: Make sure you’re chatting regularly with all your suppliers. Open communication is key! By doing it this way, everyone knows what to expect, and any bumps in the road can be tackled right away.
• Training and Education: Make sure to dedicate some time to train your team on the best hygiene and safety practices. It's super important to keep everyone informed! Having a knowledgeable team is your strongest shield against any hiccups in the supply chain.
• Data Monitoring: Use some handy tools and software to keep tabs on what's happening in your supply chain. This really helps to spot any patterns or unusual behavior that might indicate something's not quite right.
• Feedback Loop: Set up a way to share your thoughts with your suppliers. It’s super important to keep that communication flowing! Giving constructive criticism can really help everyone grow and improve. It’s all about making things better together!

If you keep these tips in mind, you’ll be on your way to maintaining a clean and efficient supply chain.

Hey, don’t forget to allowlist the official @nomicfoundation plugins! It's also a good idea to lock in the specific versions you’re using. And take a moment to check out any extended toolboxes, too. You know, just to be thorough! Get ready for "Shai-Hulud 2" coming out in November 2025! The 0” npm campaign really drives home the importance of checking where our packages come from, especially the ones tied to the Viem ecosystem. It’s a good reminder to be a bit more cautious! If you're interested, you can check out more details here.

---

Brief, in‑depth notes on emerging details

Hey there! If you’re using the Viem toolbox, you’re in for a treat. Hardhat coverage has become a breeze to work with, especially when you're running Solidity tests and using Node's test runner for TypeScript. It really simplifies the process! Say goodbye to juggling all that third-party coverage for the essentials! This really streamlines things, making it way easier for teams to stay aligned and on the same wavelength. (hardhat.org).

Ignition's deployment journals (you'll find them in journal.jsonl) are super handy for picking up your deployments without a hitch, even if the RPCs are acting a bit wonky. Plus, you can easily keep an eye on contract addresses for each network right in ignition/deployments. It’s way simpler than messing around with custom scripts! Hey, if you want to adjust the fee bumping or change the confirmation thresholds, you can totally customize that for each network! Just check out this link: v2.hardhat.org. It's pretty straightforward!

Foundry has seriously upped its game when it comes to coverage and gas tools! With the forge coverage, you can now get LCOV output, which is super handy. Plus, those gas snapshots are working really well with PR diffs, making your life a lot easier. And let's not forget about the flamegraphs and charts--they’re fantastic for pinpointing those hot spots when you're trying to optimize things.
Pretty sweet, right? (getfoundry.sh).

Anvil is here to give you some really useful RPC extensions that are totally compatible with Hardhat. Plus, it adds those awesome blob/KZG and beacon endpoints that can make your post-Dencun testing a breeze. Plus, it comes with this awesome feature that automatically handles impersonation for forked tests, which definitely makes things a whole lot simpler for you! (getfoundry.sh).

• When you're training your team, you’ll find that developers who have a background in web development or TypeScript usually adapt to Hardhat pretty fast. On the other hand, auditors and teams that focus more on Solidity often prefer Foundry. Hey, so check this out! The 2024 Solidity survey reveals that Foundry has officially taken the lead over Hardhat in terms of usage among the folks surveyed. Can you believe it? They've got a solid 51% of respondents using Foundry! Pretty impressive, right? 1% vs. 32. 9%). Keep in mind that the right choice really hinges on what tech stack your team is using and what your hiring plans look like. (soliditylang.org).

---

Migration guidance (Truffle/Ganache, Brownie)

Hey there! If you've been using Truffle or Ganache, it's probably a good idea to make the switch to Hardhat--just think about those Ignition deploys and handy Toolboxes. Or you might want to check out Foundry, especially with its cool forge scripts and broadcasting features. It could really streamline your workflow! Don't forget to take the time to rebuild your coverage, gas pipelines, and mainnet-fork tests. It’s really important to avoid just slapping those fragile scripts over without making any updates. A little extra effort now can save you a lot of headaches later! (consensys.io).

If you're planning to stay with Brownie, just keep in mind that it's currently in maintenance mode. If you're set on sticking with Python, think about switching over to Ape. But if you’re open to other options, it could be smarter to streamline things with Foundry or Hardhat. You can always expose just the essentials of Python shims to cover your data science needs. (pypi.org).

---

Decision checklist

If you're rolling with a product team that's all about TypeScript, definitely give Hardhat 3 a shot! It's got those super user-friendly Ignition deployment features that make life easier. Plus, you'll love having built-in coverage and tapping into a huge variety of plugins. It really covers all the bases! Take a look at this: hardhat.org. You won’t want to miss it!

If you’re looking for quick feedback, Foundry is the way to go! It comes with built-in fuzzing and invariants, plus a solid focus on Solidity that really simplifies the auditing process and boosts the reliability of your protocols. It’s a great choice if you want everything to run smoothly! (learnblockchain.cn).

Choose a hybrid if:

So, you're looking for the fast performance and depth that Foundry provides, but you also want the ecosystem and infrastructure integrations that come with Hardhat, right? It looks like this combo is going to be the top choice for businesses come 2025. (getfoundry.sh).

---

What we recommend at 7Block Labs

Consider using a hybrid stack for your projects. It’s a good idea to take advantage of Foundry for your unit, fuzz, and invariant testing while also establishing your gas and coverage baselines. It’ll make your life a lot easier in the long run! When you’re working on your TypeScript tests, doing some verification, or handling Ignition deployments, make sure to go with Hardhat 3 along with the Viem toolbox. It’s a solid combo! If you're diving into end-to-end testing, you'll find that both Tenderly and Anvil forks do a fantastic job. They're definitely worth considering! Hey, just a quick reminder: when you're working on those PRs, be sure to run them through Slither, especially if they're medium or higher. Also, double-check that the coverage is hitting the minimum requirements. And keep an eye out for any gas drift--try to keep it within ±1%. Thanks! (hardhat.org).

• Focus on making reproducibility a top priority: Be sure to note down your fork block numbers, solc versions, and plugin versions. In your CI pipeline, make sure to whip up those LCOV and gas snapshots. Oh, and remember to stash the Ignition journals in your artifacts storage too! (v2.hardhat.org).

Make it a habit to do a tool audit every three months. This way, you’ll always be up to date with the latest versions of Hardhat and Foundry. Don’t forget to refresh your Etherscan API config for gas-reporter v2, and take a little time to check your dependency trees for any advisories. It’ll keep everything running smoothly! (github.com).

Hey there! If you’re eager to dive in and get some real-world experience, we can hook you up with a two-week “Testing Modernization Sprint.” "During this period, we'll focus on those high-risk contracts that need our attention. We'll set up CI gates and make sure your team has a tailored playbook that works seamlessly with your tech tools."

---

Appendix: quick references

Hey! Make sure to take a look at the Hardhat 3 coverage and the Viem toolbox in the official docs. They’ve got some great info! You can check it out right here. Hey, make sure you check out the Ignition guides along with the artifacts. They're definitely worth your time! You can check out all the details right here. It's all laid out for you! Hey there! Looking for a good reference for the Hardhat Network? Check out this link where you can dive into forking, impersonation, and state edits: Hardhat Network Reference. It’s super helpful! If you’re looking for some awesome tools related to coverage, gas snapshots, and handy cheat codes, you should definitely check out Foundry’s references here. You’ll find lots of useful stuff!

• So, you should definitely get familiar with Slither, Echidna, Manticore, and Mythril. They’re all super valuable tools that can come in handy! Find them on GitHub.
• And hey, there’s some pretty big news lately! Truffle and Ganache are officially winding down, which is a pretty big deal. Plus, we should also talk about Brownie and its current maintenance status. If you're curious to learn more, check out the details on ConsenSys. They’ve got all the scoop for you!

---

7Block Labs

At 7Block Labs, we’re all about helping both startups and big companies tackle everything related to blockchain software. Whether you need design, development, or security, we’ve got your back! If this guide has helped you out at all, we’d really like to check out your repository. We can work together to create a straightforward migration plan that works with your timeline and comfort level regarding risks.