feat(execution): Big EVM Merge

[refcell]

Summary

Merges base-execution-evm into base-revm and base-alloy-evm behind an execution feature flag, eliminating the redundant crate entirely. The split between the two crates was required to avoid a base-revm ↔ base-alloy-evm dependency cycle: lower-level execution types (error, l1_reth, next_block) live in base-revm[execution] while the EVM config, block assembler, and receipt builder live in base-alloy-evm[execution]. All consumers previously depending on base-execution-evm have been updated to depend on the appropriate crate with the execution feature enabled.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
base	Ignored	Preview	Apr 6, 2026 5:11pm

Approved review 4023502920 from danyalprout is now dismissed due to new commit. Re-request for approval.

Approved review 4055626350 from 0x00101010 is now dismissed due to new commit. Re-request for approval.

[github-actions]

Review Summary

The merge of base-execution-evm, base-revm, and base-alloy-evm into the unified base-evm crate is well-structured. The feature-gated split (alloy, reth, rpc) is clean, and the consumer migrations are consistent. Two issues need attention before merge:

Bug: GRANITE missing from RollupConfig::spec_id() (critical)

crates/consensus/genesis/src/rollup.rs:124-144 — The newly added spec_id() method skips the GRANITE hardfork in its cascade. It goes from is_holocene_active directly to is_fjord_active. Because is_fjord_active() chains to is_granite_active() (which chains to is_holocene_active()), any timestamp in the GRANITE range will match is_fjord_active() and incorrectly return OpSpecId::FJORD instead of OpSpecId::GRANITE.

The test_spec_id test also skips GRANITE (jumps from FJORD at timestamp 40 to HOLOCENE at timestamp 50 without setting granite_time), so it doesn't catch this bug. Compare with the correct implementation in crates/execution/evm/src/spec_id.rs:spec_by_timestamp_after_bedrock which includes GRANITE. (Inline comment already posted on this file.)

Intra-crate duplication: op_spec_id vs spec_by_timestamp_after_bedrock

crates/execution/evm/src/l1_reth.rs:284-306 contains a private op_spec_id() function that is identical to the public spec_by_timestamp_after_bedrock() in crates/execution/evm/src/spec_id.rs:20-36. Both are now in the same crate (base-evm), and reth implies alloy, so l1_reth.rs can simply call crate::spec_by_timestamp_after_bedrock(). If a new hardfork is added, forgetting to update both copies would cause a spec mismatch between L1 fee calculation and execution — the GRANITE bug above demonstrates this risk.

Minor: UnknownOpHardfork missing Display/Error

crates/common/chains/src/spec.rs:9-10 — UnknownOpHardfork only derives Debug/Clone/PartialEq/Eq. Without Display and Error impls, it can't be used with ? in contexts requiring std::error::Error. The type it replaces (revm::primitives::hardfork::UnknownHardfork) implemented both. (Inline comment already posted.)

Note: base-txpool metrics no longer default-on

The [features] section in crates/txpool/Cargo.toml had default = ["metrics"] which was removed. None of the workspace consumers explicitly enable metrics, so txpool metrics collection will be silently disabled. If this is intentional, no action needed — just flagging the behavioral change.