Skip to content

feat(evm): warn when an explicit network mismatches a fork - #18037

Merged
figtracer merged 6 commits into
masterfrom
feat/warn-explicit-network-fork-mismatch
Nov 2, 2026
Merged

figtracer merged 6 commits into
masterfrom
feat/warn-explicit-network-fork-mismatch

Conversation

@figtracer

@figtracer figtracer commented Nov 2, 2026 •

Copy link
Copy Markdown
Member

When the network is selected explicitly (--network, -n, or network in foundry.toml), create_fork skips the family check that fails an inferred network, which is intended since one EVM runs per process. The result was that -n monad with a fork of an Ethereum chain, or -n ethereum with a Monad fork, ran the fork under the selected EVM's rules with no message at all. Forge test and script fork creation, from the CLI or cheatcodes, now prints a warning such as fork of chain 31337 belongs to `ethereum`, but the selected network is `monad`, so the fork runs with `monad` rules whenever the selected EVM cannot serve the fork's family. Anvil endpoints report their own family; any other endpoint belongs to the family of its recognized chain ID, since it would otherwise inherit the selected network. The check uses the same supports_fork_source rule as the inferred-network error, so pairs that are supported by design (Ethereum or Tempo execution over OP Stack state) stay quiet. The warning names the chain ID rather than the endpoint, because RPC URLs often carry API keys, and is printed once per source chain and family pair so a suite that calls vm.createSelectFork in every test does not repeat it.

The book line in config/networks.mdx that says the selected profile must be compatible with the fork source still needs the qualification the issue asks for; that change belongs in foundry-rs/book.

Closes #17994.

An explicitly selected network skips the fork family check, so forking
a chain of another family ran it under the selected EVM's rules without
any message. Fork creation now warns once per source chain, naming the
fork's family and the selected one. An inferred network still fails on
the mismatch.

Closes #17994.

Amp-Thread-ID: https://ampcode.com/threads/T-bf11c0cd-86c4-4af5-8630-39d2c08bb15c
Co-authored-by: Gustavo Figueiredo <me@figtracer.com>
mattsse
mattsse previously approved these changes Nov 2, 2026

@mattsse mattsse left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

An endpoint without Anvil metadata takes an explicitly selected network as
its profile, so the warning compared the selection with itself and never
fired for ordinary RPCs. Such endpoints now belong to the family of their
recognized chain ID. Warnings are deduplicated per chain and family pair
instead of per chain, and messages name the full execution profile, so
Celo is no longer reported as ethereum.

Amp-Thread-ID: https://ampcode.com/threads/T-01a19b5e-2472-7381-b12e-4dcf9808d2d4
Co-authored-by: Mablr <59505383+mablr@users.noreply.github.com>

@mattsse mattsse left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One regression in the new chain-ID fallback; details inline.

Comment thread crates/evm/core/src/fork/multi.rs Resolved
Amp-Thread-ID: https://ampcode.com/threads/T-01a19b5e-2472-7381-b12e-4dcf9808d2d4
Co-authored-by: Mablr <59505383+mablr@users.noreply.github.com>
mattsse
mattsse previously requested changes Nov 2, 2026

@mattsse mattsse left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reported endpoint-family regression remains reproducible on this head.

ampagent and others added 2 commits November 2, 2026 15:52
Chain-ID inference was gated on a missing Anvil instance ID, but
`instance_id` is also absent when `anvil_nodeInfo` answers and only
`anvil_metadata` is unavailable. An Anvil serving Monad on chain 1 behind
such a proxy was then treated as Ethereum, failing an inferred fork and
warning falsely under an explicit `--network monad`. Fork contexts require
a recognized hardfork, so gate the inference on the reported hardfork,
which is present exactly when node info answered.

Amp-Thread-ID: https://ampcode.com/threads/T-01a19cae-ed5a-734d-8257-843655c9235a
Co-authored-by: Mablr <59505383+mablr@users.noreply.github.com>

@mattsse mattsse left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@figtracer
figtracer merged commit e1c4ab9 into master Nov 2, 2026
25 checks passed
@figtracer
figtracer deleted the feat/warn-explicit-network-fork-mismatch branch November 2, 2026 16:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat(evm): warn when an explicit --network does not match a fork

4 participants