Modern Development Tools

The Solidity Stack in 2026: What Killed Truffle and Ganache

Truffle and Ganache are dead. Here's the Solidity stack that replaced them in 2026 and why Foundry became the default for serious teams.

The Solidity Stack in 2026: What Killed Truffle and Ganache

Four years ago I wrote a tutorial on deploying smart contracts with Truffle and Ganache. It was a good article for its moment. That moment is over.

Both tools are dead. Not deprecated, not "still works but you should look at alternatives." Dead. ConsenSys announced the sunset of Truffle and Ganache in December 2023, gave everyone about 90 days, and archived the repositories. If you clone that old tutorial today and follow it line by line, you are learning a workflow that no active team runs anymore.

Loop Engineering: Agents That Run While You Sleep

Loop Engineering: Agents That Run While You Sleep

Closed loops that discover work, verify results, and schedule their own next run — battle-tested patterns for Claude, OpenAI, and MCP. No toy demos.

Buy the Book!

I went back to see what replaced it, because that is the honest thing to do when your own content rots. This is the report.

Why the old stack lost

Truffle and Ganache were not bad tools. They were the tools that taught a generation of developers what a migration script was and what a local chain felt like. The problem is that they were built in JavaScript, for a JavaScript mental model, at a time when nobody had proposed anything faster.

Then Foundry showed up and reset expectations.

The pitch was simple and brutal: write your tests in Solidity instead of JavaScript, run them in a Rust EVM with no JavaScript bridge in the middle, and watch a suite that took minutes finish in seconds. Once developers felt that speed, the JavaScript-first frameworks had a problem they could not patch their way out of. You cannot bolt a native runtime onto an architecture that assumed a Node.js process in the hot path.

Ganache had a narrower problem. Its entire job was "be a local Ethereum node you can throw away." Hardhat Network already did that inside the framework you were using, and Foundry's Anvil did it faster from the command line. When your local chain is a free built-in feature of two different toolchains, a separate app that does only that has nowhere to stand.

So the sunset was not a surprise. It was the market finishing a decision it had already made.

The 2026 landscape, honestly

There are two frameworks that matter now, and a supporting cast.

Foundry is the one serious teams reach for first. It is a Rust toolchain with a few sharp pieces:

  • forge builds and tests your contracts.
  • anvil is the local node, the true Ganache replacement.
  • cast is the command-line Swiss Army knife for poking at chains and contracts.

Tests are written in Solidity, which sounds like a small detail and is actually the whole thing. You stop context-switching between the language your contract is in and the language your tests are in. Fuzzing and invariant testing are first-class, not plugins. This is why Foundry became the default for audits, security work, and DeFi protocol engineering, the corners of this space where being wrong costs real money.

Hardhat did not roll over. Hardhat 3 is a genuine reset: a Rust-based runtime under the hood, native Solidity tests that are compatible with Foundry's style, and the ability to simulate more than just Ethereum mainnet, including multiple simulated chains in one config. If your contracts are welded to a TypeScript frontend or backend, or your team already lives in Node, Hardhat 3 is the pragmatic home. It also reads Foundry's foundry.toml, so the two are no longer rivals you have to pick between at gunpoint.

The rest of the cast: viem and ethers on the library side for talking to chains from your app, and forked-network tools for end-to-end checks against real mainnet state.

My take: start with Foundry

If you are standing up a new Solidity project in 2026 and you do not already have a reason to be somewhere else, start with Foundry.

The reasoning is not fashion. It is that Foundry optimizes for the thing that actually matters in smart contract work, which is confidence that your code does what you think under adversarial conditions. Fast tests mean you run them constantly. Native fuzzing means you find the input you did not think of. Solidity tests mean the gap between "what the contract does" and "what the test asserts" is as small as the language allows.

A new project is three commands away:

# install foundry
curl -L https://foundry.paradigm.xyz | bash
foundryup

# scaffold a project
forge init my-protocol
cd my-protocol

That gives you a working contract, a Solidity test, and a config. Run the suite:

forge test

Spin up a local chain when you need one, which is the line that would have said "ganache" in my old article:

anvil

And a test written in the same language as the contract looks like this, which is the part that still makes me happy every time:

// test/Counter.t.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "forge-std/Test.sol";
import "../src/Counter.sol";

contract CounterTest is Test {
    Counter internal counter;

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

    // a normal unit test
    function test_Increment() public {
        counter.increment();
        assertEq(counter.number(), 1);
    }

    // a fuzz test: Foundry throws many random values at x for free
    function testFuzz_SetNumber(uint256 x) public {
        counter.setNumber(x);
        assertEq(counter.number(), x);
    }
}

The second function is the whole argument in one screen. You did not write a loop, you did not wire up a random generator, you did not leave JavaScript. You declared an argument and Foundry hammered it with values you would never have picked by hand. That is the kind of testing smart contracts actually need, and it used to be a research project.

Reach for Hardhat 3 when reality pulls you there: a heavy TypeScript app around the contracts, a plugin you depend on, a team that will revolt if you take away Node. That is a real reason, not a fashion statement, and Hardhat 3 is good enough now that it is not a compromise. Plenty of teams run both, Foundry for the tests and invariants, Hardhat for the deploy scripting and the TypeScript glue, and that hybrid is a legitimate answer rather than indecision.

The actual lesson

The tooling is the surface story. The real one is that a well-written technical tutorial has a shelf life, and in fast-moving corners like this one, four years is past the expiration date.

I am not going to pretend I saw the Truffle sunset coming. I did not. What I can do is treat my own back catalog like code that needs maintenance, notice when an article is teaching a dead stack, and rewrite it instead of letting it quietly mislead someone who found it on a search result in 2026.

If you learned smart contracts on Truffle and Ganache, none of that knowledge was wasted. Migrations, local chains, deployment scripts, the concepts all carried forward. Only the tools changed. Download Foundry, run forge init, and you will feel at home in about ten minutes. The ideas were always the durable part.