Mablr mablr

Network dispatching consistency after Monad support introduction

Context

This audit follows the introduction of first-class Monad support in Foundry and a sequence of focused follow-up PRs intended to tighten network dispatch, isolate Monad-specific state and behavior, and reduce its footprint in generic EVM infrastructure:

#15343 — Monad Foundry — Introduced first-class Monad support across Forge, Cast, Anvil, Chisel, tracing, cheatcodes, and shared EVM infrastructure.
#16150 — fix(evm): honor explicit fork network — Preserved an explicitly selected execution network instead of allowing fork inference to override it.
#16151 — fix(anvil): preserve fork endpoint identity — Kept authoritative endpoint identity across fork URL replacement and reset validation.
[#16157 — refactor(ci): group Monad checks](https://github.com/foundry-rs/foundry/pu

Foundry v1.8.0

Foundry v1.8.0 is a testing-heavy release. It ships native symbolic testing, mutation testing, and major fuzzing and invariant improvements, while making isolate mode the default after a series of compatibility fixes. This release also ships the Rust foundryup, expands forge lint with a large set of security and gas detectors, and continues the structured CLI output work across Forge and Cast.

Highlights

Testing, Fuzzing, and Symbolic Execution

Testing is the main theme of v1.8.0. The release expands the ways Forge can find failures, make them reproducible, and turn them into smaller actionable counterexamples.

Decofe Perf PR Benchmark Plan

Static diff triage for deciding which PRs to combine and run through scfuzzbench. The goal is to avoid benchmarking dozens of tiny AI PRs one-by-one.

Run These scfuzzbench Branches

These are the concrete grouped benchmark candidates, in priority order.

1. Invariant campaign steady-state overhead

Foundry PR #15070 follow-up — real invariant campaign

Real forge invariant project used to measure end-to-end wall-clock and peak RSS of the corpus-seed worker fan-out (companion to the micro-benchmark harness at https://gist.github.com/mablr/b87b9d75f3723b3de8b5796c72331ae2).

Target.sol exposes a large branch surface (1600 independent branch targets, ~3200 EVM edges, split across 8 functions to stay within solc's parser recursion limit) so coverage-guided invariant fuzzing accumulates a sizeable persisted corpus (~370 entries, depth-2000 sequences).

Foundry Benchmark Results

Date: 2026-04-24 23:10:24

Repositories Tested

Foundry Benchmark Results

Date: 2026-04-24 23:10:24

Repositories Tested

Some Alloy2.0 Improvements

Alloy v2.0 includes several targeted improvements to the Network trait that make it significantly more ergonomic and versatile. These changes were driven in large part by Foundry's ongoing refactor towards fully generic Network and Evm abstractions, work motivated by Tempo support, which surfaced a some rough edges on workflows fully generic over Network.

Generic Signature Flow

NetworkWallet<N> is now generic over the Network trait, meaning EthereumWallet can be used seamlessly with custom network implementations without requiring a separate wallet type. The required bounds — N::TxEnvelope: From<Signed<N::UnsignedTx>> and N::UnsignedTx: SignableTransaction<Signature>, are placed on the impl rather than on Network itself, so existing custom network implementations are unaffected.

Non-signable transactions (such as Optimism deposit transactions) now return sealed envelopes rather than errors, removing a common source of boilerplate in OP Stack integrat

EVM & Cheatcode Instrumentation: Network-Generic Architecture

One of the most significant internal refactors in Foundry 2.0 is the introduction of FoundryEvmNetwork, a supertrait that makes Foundry's entire EVM execution stack generic.

This refactor was originally driven by the need to bring Tempo support upstream into Foundry itself. But the architecture that emerged is intentionally general: any custom chain can plug into Foundry's full execution and testing infrastructure, cheatcodes, forking, fuzzing, coverage, gas snapshots, as long as it implements FoundryEvmNetwork, Alloy's Network, and FoundryEvmFactory. The pattern is deliberately similar to Reth's SDK model, where the node itself becomes an extension point rather than a monolith. In Foundry 2.0, the same philosophy applies to its evm crate: it is an SDK, not a fixed implementation.

The Problem

Foundry's executor, database backend, and cheatcode inspector were historically written against Ethereum-specific types. As the ecosystem

	use std::{env, hint::black_box};

	#[derive(Clone)]
	struct CorpusEntry {
	tx_seq: Vec<u8>,
	cmp_seq: Vec<u8>,
	is_favored: bool,
	}

	#[derive(Clone, Default)]

	use alloy_network::{AnyNetwork, Network};
	use foundry_common_fmt::{UIfmt, UIfmtHeaderExt, UIfmtReceiptExt, UIfmtSignatureExt};
	use foundry_primitives::FoundryTransactionBuilder;
	use revm::context::TxEnv;

	pub trait Foundry {
	type Network: Network<
	TxEnvelope: UIfmt + UIfmtSignatureExt + Clone,
	TransactionRequest: FoundryTransactionBuilder<Self::Network>,
	ReceiptResponse: UIfmt + UIfmtReceiptExt,