惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Jina AI
Jina AI
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
B
Blog
T
The Blog of Author Tim Ferriss
量子位
Microsoft Azure Blog
Microsoft Azure Blog
博客园 - Franky
小众软件
小众软件
Recent Announcements
Recent Announcements
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
I
InfoQ
美团技术团队
G
Google Developers Blog
Engineering at Meta
Engineering at Meta
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
V
Visual Studio Blog
云风的 BLOG
云风的 BLOG
博客园 - 【当耐特】
IT之家
IT之家
Microsoft Security Blog
Microsoft Security Blog
博客园 - 聂微东
Last Week in AI
Last Week in AI
H
Hackread – Cybersecurity News, Data Breaches, AI and More
H
Help Net Security

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Foundry vs Hardhat in 2026: Which Solidity Toolchain Wins?
Pavel Espiti · 2026-05-11 · via DEV Community

Pavel Espitia

Foundry vs Hardhat in 2026: Which Solidity Toolchain Wins?

Two toolchains. Same goal: write, test, and deploy Solidity. Different design philosophies, very different best-fits in 2026.

I've used both in production across smart-contract audits and protocol work over the last two years. Here's an honest comparison so you don't waste a week picking the wrong default for your team.

TL;DR

  • Foundry — best for security work, audits, protocol engineering, and anyone who values speed and Solidity-native tests. The default for serious DeFi.
  • Hardhat 3 — best when your contracts are tightly coupled to a TypeScript frontend or backend, when your team already lives in Node.js, or when you depend on plugins that haven't migrated.
  • Both at once — legitimate, common, not a smell. Many teams write tests in Foundry and deployments in Hardhat.

If you're starting a new protocol from scratch in 2026, default to Foundry. The rest of this post explains when the others are correct.

Installation and first impressions

Foundry

curl -L https://foundry.paradigm.xyz | bash
foundryup
forge init my-project

Enter fullscreen mode Exit fullscreen mode

Three commands. Sub-30 seconds. You get forge (compiler / test runner), cast (CLI for chain interaction), and anvil (local node). All written in Rust. All single binaries. No package.json, no node_modules.

Hardhat 3

mkdir my-project && cd my-project
pnpm init
pnpm add -D hardhat
npx hardhat --init

Enter fullscreen mode Exit fullscreen mode

Hardhat 3 (released late 2025) is a substantial rewrite. The new toolchain runs on a Rust-based execution layer (effectively REVM), bringing the test speed within striking distance of Foundry. It also natively supports Solidity tests, which were exclusive to Foundry until last year.

This matters: most "Foundry vs Hardhat" comparisons online are pre-Hardhat-3 and outdated.

Test speed (the headline metric)

Same Uniswap-V2-style contract, 80 unit tests, on an M2 MacBook:

Toolchain Cold run Warm run Memory
Foundry 1.3 s 0.4 s 220 MB
Hardhat 3 (Solidity tests) 2.1 s 0.7 s 480 MB
Hardhat 2 (TypeScript tests via ethers) 18 s 9 s 1.2 GB

Hardhat 3 closed the gap. It's now within 2x of Foundry on equivalent test suites — versus the 10-20x penalty Hardhat 2 incurred. If your only reason for picking Foundry was speed, that argument is weaker in 2026.

Test ergonomics

Foundry — Solidity tests

// test/Counter.t.sol
pragma solidity ^0.8.20;
import "forge-std/Test.sol";
import "../src/Counter.sol";

contract CounterTest is Test {
    Counter c;

    function setUp() public {
        c = new Counter();
    }

    function test_increment() public {
        c.increment();
        assertEq(c.count(), 1);
    }

    function testFuzz_setNumber(uint256 x) public {
        c.setNumber(x);
        assertEq(c.count(), x);
    }
}

Enter fullscreen mode Exit fullscreen mode

Tests live in the same language as the contracts. No type marshaling. No JS context switch. Fuzzing is a built-in keyword (testFuzz_) — no extra config.

Hardhat 3 — same test, two flavours

// test/Counter.t.sol — Solidity test
import "forge-std/Test.sol";
import "../src/Counter.sol";

contract CounterTest is Test {
    Counter c;
    function setUp() public { c = new Counter(); }
    function test_increment() public { c.increment(); assertEq(c.count(), 1); }
}

Enter fullscreen mode Exit fullscreen mode

Hardhat 3 runs Foundry-compatible tests. Identical syntax. Either toolchain executes them.

// test/Counter.ts — TypeScript test (still supported)
import { expect } from "chai";
import { ethers } from "hardhat";

describe("Counter", () => {
  it("increments", async () => {
    const Counter = await ethers.getContractFactory("Counter");
    const c = await Counter.deploy();
    await c.increment();
    expect(await c.count()).to.equal(1);
  });
});

Enter fullscreen mode Exit fullscreen mode

The TS path is for teams that want to integrate tests with frontend assertions or backend test suites. Slower to run, but the unified language can pay off in a full-stack codebase.

Plugin and ecosystem

Foundry Hardhat
Coverage forge coverage (built-in) solidity-coverage plugin
Verification forge verify-contract hardhat-verify plugin
Local node anvil (built-in) hardhat-node (built-in)
Mainnet forking forge --fork-url (built-in) hardhat-network --fork (built-in)
Contract upgrades Manual proxies @openzeppelin/hardhat-upgrades
Gas reports forge test --gas-report hardhat-gas-reporter plugin
Defender / monitoring Manual scripting defender-cli integration
Frontend type generation None native (use wagmi-cli separately) typechain (mature plugin)

Hardhat's plugin ecosystem is wider and more mature — particularly for OpenZeppelin upgrades and frontend integration. Foundry trades plugin breadth for built-in primitives that cover 80% of needs without extension.

Where each one wins

Use Foundry if

  • You're building a DeFi protocol, lending market, AMM, vault, or anything where a missed bug equals a wallet drain.
  • Your team's primary language is Solidity, not TypeScript.
  • You need fast invariant testing or stateful fuzzing as part of CI.
  • You write audits or work in security-adjacent roles. Auditors expect Foundry projects.
  • You don't want a node_modules graph.

Use Hardhat 3 if

  • Your contracts are part of a full-stack TypeScript app and your team lives in pnpm workspaces.
  • You depend on OpenZeppelin's upgrade plugin or other Hardhat-only tooling.
  • Your team has invested in TypeScript test patterns and the migration cost is high.
  • You ship to many networks with environment-specific deployment scripts and want the JS flexibility.

Use both (the senior move)

The pattern many serious teams adopt:

  • Tests in Foundry. Speed, fuzzing, invariant testing, Solidity-native ergonomics.
  • Deployments in Hardhat. Network-specific configs, OpenZeppelin upgrade plugin, TypeScript scripting.

This is supported by Hardhat 3 out of the box — it can read Foundry's foundry.toml, share build artifacts, and run mixed test suites. The boundaries between the two have softened significantly.

What changed in 2026

If you read a "Foundry vs Hardhat" post from 2024, it's probably out of date in three places:

  1. Hardhat 3's Rust execution layer closed most of the speed gap.
  2. Solidity tests in Hardhat removed the "Foundry is the only Solidity-native option" advantage.
  3. Cross-tool interopfoundry.toml parsed by Hardhat, shared artifacts — turned the "pick one" decision into "pick which side of the workflow each tool handles."

The decision is no longer binary. It's about workflow phase.

My recommendation

Start with Foundry. It's the right default for the security-sensitive work that pays $10K+ a month. If your project grows into a full-stack codebase that needs Hardhat's plugin ecosystem, layer Hardhat 3 on top — they coexist cleanly.

The wrong move is picking Hardhat in 2026 because that's what 2022 tutorials taught, and then six months later trying to retrofit Foundry-level test speed into a deeply Hardhat-coupled codebase.

Pick the tool that matches the work you'll be doing in twelve months. For most protocol engineers in 2026, that's Foundry first.

Next post in the series: how to set up a CI pipeline for a Foundry project that runs invariant tests, gas reports, and coverage — under 50 lines of YAML.