[Bug] AnyHeader fails to deserialize baseFeePerGas values exceeding u64::MAX

[incrypto32]

Component

consensus, eips, genesis

What version of Alloy are you on?

No response

Operating System

macOS (Apple Silicon)

Describe the bug

AnyHeader::base_fee_per_gas is typed as Option<u64>, which causes deserialization failures on chains where baseFeePerGas exceeds u64::MAX.

We encountered this on a live EVM-compatible chain (Stable, chain ID 988) that returns baseFeePerGas: "0x3635c9adc5dea00000" (10^21) for a range of historical blocks. Deserializing the RPC response fails with:

invalid type: integer `1000000000000000000000`, expected u64

Spec vs implementation

The Ethereum execution spec defines base_fee_per_gas as Uint (arbitrary-precision), while explicitly choosing U64 for blob_gas_used and excess_blob_gas. This distinction appears intentional.

In alloy, AnyHeader uses Option<u64> for base_fee_per_gas, and the BlockHeader trait constrains the return type to Option<u64>.

Suggestion

Change AnyHeader::base_fee_per_gas from Option<u64> to Option<U256> (or Option<u128>). This would be consistent with AnyHeader's documented purpose of accounting for "possible differences in network implementations". Ideally the BlockHeader trait method would also be widened, but even just changing AnyHeader would eliminate the deserialization failure.

The same consideration may apply to gas_limit and gas_used, which the spec also defines as Uint.

[mattsse]

yeah maybe they shouldnt use a value > u64::max for a field that is supposed to be u64

[incrypto32]

Whether the value is "reasonable" isn't really the point; the spec says Uint and AnyHeader exists for non-standard chains. I'd expect AnyHeader to follow the spec here is there a reason for not doing so?

[mattsse]

the "spec" says a lot of things

I'd expect chains not do to hacks like this.

I assume this was done to prevent any txs to land in earlier blocks.

would simply saturating this on deserde be an option? this could also lead to some issues but I'm hesitant to change the types here

[incrypto32]

Saturating on deser would fix the deserialization failure, which is the main blocker. For our use case we'd still need the full value because expose baseFeePerGas to subgraph wasm mappings as BigInt, and it needs to be determinisitc across versions. The previous web3 crate used U256, so we'd need to preserve that to avoid a determinism break. I guess we'll need to use a custom header type on our end for this to keep supporting the chain. But saturating in AnyHeader would at least unblock other consumers hitting this.