feat: Base Foundry

[lukasrosario]

Motivation

Add support for Base precompiles + EVM following the precedent set by Monad support (#15343), building on shared native-network abstractions that landed with it.

Solution

Adds a non-default base feature providing BaseEvmNetwork and BaseEvmFactory on top of Base's own base-common-evm and BasePrecompiles, so execution semantics come from Base rather than a reimplementation in Foundry, and routes Base through Forge, Cast, Script, Chisel, Verify, and Anvil without any Ethereum or generic OP fallback.

Highlights:

• Upgrade-gated precompiles. Azul excludes Beryl's set; Beryl installs the activation registry, B-20 factory, and policy registry with a chain-resolved activation admin; Cobalt adds the EIP-8130 nonce manager and transaction context. Tests assert the upgrades are behaviorally distinguishable rather than merely configured.
• Anvil. Base-native execution with the complete post-Cobalt EIP-8130 surface: RPC, receipts carrying payer, metadata, and phaseStatuses, txpool lane replacement, expiry, payer reservations and replay protection, tracing, and lifecycle operations.
• Deterministic replay. Fixtures captured once from Base mainnet across Jovian, Azul, and Beryl re-execute locally and compare status, gas, logs, L1 fee accounting, and touched-account deltas against node-reported values. No RPC at test time.
• Trace decoding. The five fixed precompiles register labels and ABIs per address, gated on the upgrade that installs each. The B-20 token surface is registered globally by selector, as Tempo does for TIP20, since tokens live at factory-derived addresses. It deliberately omits the ERC-20, EIP-2612, and AccessControl members: the global map is not network-scoped, so competing candidates for transfer or balanceOf could change how ordinary token traces decode on other networks. A test pins that exclusion.
• Code sentinel on state-holding precompiles. Solidity guards high-level calls to functions returning no data with an extcodesize check, which a code-less precompile fails in the caller. Base's 0xEF EIP-3541 sentinel is planted on the installed precompiles in both Anvil genesis and the executor, matching what Base's own tests expect a harness to do.
• CI. A reusable base.yml mirroring monad.yml, wired into ci.yml as a required check, plus a Base+Optimism build and an explicit base_replay run because --lib skips that target.

Changes beyond the base feature

Four parts of this PR affect builds that don't enable base:

• --hardfork on EvmArgs (crates/cli/src/opts/evm.rs) is a new shared flag for forge, cast, chisel, and script. It surfaces the existing Config::hardfork key, which previously could only be set in foundry.toml. Namespaced values such as base:Beryl or monad:MonadNine go through the existing FoundryHardfork parser.
• Network inference in cast tx and cast block --raw. Both now resolve the network family rather than requiring an explicit --network, so Base deposit and EIP-8130 transactions decode by default. When neither --network nor a configured chain identifies the network, this costs one eth_chainId request; previously both defaulted to Ethereum with no round trip. Resolution now also reports a family that isn't compiled into the binary as an error, so these commands agree with cast call.
• Monad in Cast's network dispatch. Making that dispatch exhaustive removed the _ catch-all Monad relied on, so both sites carry explicit NetworkVariant::Monad arms that use the Ethereum-typed provider. Behavior for Monad is unchanged.
• Release binaries build with the base feature (.github/workflows/release.yml), matching how monad and optimism ship.

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[github-actions]

✅ Changelog found

The deterministic check will validate the changed entry.

[mablr]

Hi @lukasrosario 👋

It already looks pretty good overall.

We are currently doing some post Monad clean-ups to fix several design footguns, ideally by the end of the week, only after we will able to start deep reviewing process.

The 2 main requirements we want to strongly enforce for external chains:

• complete/robust feature gating, no logic, structure, or anything else should leak
• FoundryEvmNetwork/FoundryEvmFactory/NestedEvm surface must stay as pre-#15343, no chain-specific methods or types will be accepted except if very very well justified/documented and contained. Specific custom evm logic must go behind FoundryContextExt.

Some merge conflicts may appear due to clean-ups, I'll notice you when stabilized. In the meantime please check the 2 requirements above are properly enforced.

[lukasrosario]

thanks @mablr ! did another pass & pushed up a few changes, should be abiding by both requirements now. lmk when cleanup is done & will rebase

[mablr]

Nice!

After internal discussion, we will certainly ship this integration in several steps by cherry-pick from current PR. This will reduce round-trips.

[lukasrosario]

@mablr sounds good let me know if you need me to assist with anything. will leave the PR as is for now

[figtracer]

@mablr sounds good let me know if you need me to assist with anything. will leave the PR as is for now

we'll come back to this next week

[stevencartavia]

@lukasrosario, several shared changes that this implementation can build on have now landed: #16406, #16407, #16415, #16417, #16419, #16420, #16438, #16443, #16448, #16449, #16450, and #16458.

[lukasrosario]

@stevencartavia thank you, i'll rebase now

[lukasrosario]

@stevencartavia @figtracer @mablr just rebased, should be good now. lmk anything else

[lukasrosario]

looks like some new conflicts, rebasing again now

[lukasrosario]

hey @figtracer @stevencartavia @mablr , any update i can take back to our team? i've been keeping the PR up to date, hoping to bring back an estimate of when we can expect this to get in 🙏

[mablr]

Hi @lukasrosario,

I need to spend a bit more time than expected on the post-Monad integration clean-up. Thanks for updates you've made so far, no need more work for now as new conflicts may appear anyway, I'll get back to you with updates ASAP.

[lukasrosario]

thank you