x/evm + consensus_params: module defaults diverge from pacific-1 operational state

[bdchatham]

Problem

x/evm/types/params.go defaults and CometBFT consensus_params.block.max_gas defaults are baked-in values that do not reflect the operational state of any currently-running Sei chain. Downstream tooling that builds against module defaults (test harnesses, fresh-chain bootstrap, ephemeral CI environments) ends up with a chain that behaves differently from production.

Concrete divergence

Parameter	sei-chain default	pacific-1 (operational)	atlantic-2 (operational)	arctic-1 (operational)
consensus_params.block.max_gas	-1 (seid init unlimited)	12_500_000 (governance)	12_500_000 (governance)	35_000_000 (genesis)
evm.params.MinimumFeePerGas	1_000_000_000 (1 gwei)	matches	matches	matches
evm.params.MaxDynamicBaseFeeUpwardAdjustment	0.0189	matches	matches	matches
evm.params.MaxDynamicBaseFeeDownwardAdjustment	0.0039	matches	matches	matches
evm.params.TargetGasUsedPerBlock	250_000	matches	matches	matches

4 of 5 EVM params match all three production chains. The outlier is consensus_params.block.max_gas, which is 8× more permissive as a fresh-chain default (or unlimited via -1) than what production runs (12.5M).

This came up in the sei-protocol/qa-testing release-test harness burndown:

• Tests hardcoded a blockGasLimit = 5_000_000_000 constant — accidentally matching atlantic-2's pre-relaunch genesis snapshot, but matching no live chain.
• Ephemeral chains the harness provisions (via seictl + sei-k8s-controller) inherit the sei-chain default — 8× more permissive than pacific-1.
• Result: EIP-1559 base-fee directional tests fail because the test-side and chain-side blockGasLimit disagree.

Why this matters

1. Test harnesses can't write portable assertions when "default chain" and "production chain" differ in load-bearing consensus params.
2. Fresh CI chains don't emulate production by default — every ephemeral chain needs an explicit override to behave like pacific-1.
3. Governance drift is invisible to consumers that build off module defaults — a tooling change can ship correctly against pacific-1 but break against atlantic-2 (or vice versa) without a tracked signal.

Proposed direction

Two possible shapes, not pre-decided:

A. Update sei-chain module defaults to match pacific-1's operational state.

• DefaultMaxGas (consensus_params) becomes 12_500_000.
• All x/evm/types/params.go defaults stay (they already match).
• Pros: fresh chains emulate pacific-1 by construction.
• Cons: governance drift on pacific-1 doesn't propagate back; arctic-1's 35M is a separate value not covered by the default.

B. Don't change sei-chain defaults; track operational params in sei-config.

• Add GenesisDefaults() in sei-config holding pacific-1-aligned values.
• Sidecar (or any chain-init tooling) consumes it during fresh-chain genesis assembly.
• Pros: sei-config is the right home for chain operational state; multiple chains can be templated.
• Cons: sei-chain defaults remain misleading for any consumer that doesn't go through sei-config.

The qa-testing burndown is proceeding with the workaround that the test harness pins its own per-chain operational params (PR sei-protocol/qa-testing#105). This issue tracks the upstream question of where the canonical defaults should live.

Out of scope

• Updating sei-config or seictl to consume new defaults (separate change, sei-config / sei-k8s-controller-side).
• Migration of existing chains (pacific-1, atlantic-2, arctic-1) — they're already operating at governance-tuned values; this issue is about defaults for new chains.

References

• sei-protocol/qa-testing#105 — test-side per-chain params map
• sei-protocol/platform#482 — release-test deadline bump (operational, unrelated)
• Cross-environment leakage pattern documented in docs/bugbash/release-test-harness.md