Embedded canonical defaults for fresh chains — strategy needed

[bdchatham]

Problem

sei-config today embeds full per-chain genesis files for pacific-1, atlantic-2, and arctic-1 (chains/<id>/genesis.json via go:embed) plus a KnownChain() accessor. There is no canonical "default" for a new chain — i.e., what consensus_params and app_state.evm.params should a fresh ephemeral chain inherit so it emulates the production shape consumers (test harnesses, ops tooling) assume?

Today the gap surfaces operationally:

• The release-test harness's qa-testing chainParams map (sei-protocol/qa-testing#105) hardcodes per-chain operational values for pacific-1/atlantic-2/arctic-1 plus a separate entry for "ephemeral harness chains" using sei-tendermint's DefaultBlockParams (MaxGas: 100M). This works but every test-side consumer has to re-derive the same per-chain table.
• The seictl orchestrator's genesis-chain preset → controller → sidecar pipeline does not inject pacific-1-aligned consensus_params at fresh-chain init. The chain runs sei-tendermint defaults (100M max_gas, vs production 12.5M) — 8× more permissive than mainnet by accident.
• Governance has drifted the live operational state of all three chains away from their launch-time genesis (e.g., pacific-1 launch block.max_gas: 10000000 → operational 12500000). The launch-time genesis files embedded in this repo are correct but no longer reflect operational reality.

Why this needs strategy

The "what should a fresh chain look like?" question has at least three competing answers:

1. Launch shape — fresh chains inherit the same consensus_params that pacific-1 was launched with (10M max_gas, etc.). Stable across time; doesn't track governance drift.
2. Current operational shape — fresh chains inherit pacific-1's current consensus_params (12.5M max_gas). Drifts as governance moves; needs refresh policy.
3. Per-chain parametric template — sei-config holds operational params separately from launch genesis (e.g., chains/<id>/operational-params.json), refreshed deliberately; fresh chains pick a reference chain to emulate.

The downstream consumer shape also forks:

• Sidecar overlay (a): sei-k8s-controller's seictl sidecar overlays sei-config's defaults onto the in-progress genesis after the validator initContainer's seid init, before gentx generation. The CRD's spec.genesis.overrides plumbing reaches the sidecar (generate_gentx.go:54 GenesisParams field) but is documented as "reserved for future genesis customization" — i.e., unimplemented.
• CLI flag (b): seictl's --preset genesis-chain accepts a --default-shape pacific-1|atlantic-2|... flag, looked up against sei-config's exports.
• Implicit (c): sei-config exports a Go function like DefaultGenesisTemplate() ([]byte, error) returning a structural skeleton, and consumers are expected to apply it themselves.

These are not mutually exclusive — (a) could read from (c), for instance — but the team needs a position before code is written so we don't end up with three half-implementations.

Concrete asks

Pick a strategy for:

• Shape: What does sei-config export to convey "this is what a fresh chain should look like"? (Full genesis template, partial consensus_params overlay, typed Go struct, per-chain operational-params file, …)
• Source-of-truth policy: Launch shape vs current operational shape vs versioned operational snapshots. Who's responsible for refreshing if operational?
• Consumer wiring: Sidecar overlay vs CLI flag vs caller-implicit. Where does the merge happen, and how do user-supplied spec.genesis.overrides compose with the defaults?
• Coverage: Just consensus_params, or also app_state.evm.params, app_state.params.fees_params, etc.? sei-network-specialist flagged additional drift in abci.recheck_tx, synchrony.*, timeout.*, version.app_version.

What's blocked / unblocked by this

Unblocked today: the release-test harness (PR sei-protocol/qa-testing#105) uses a test-side per-chain map and runs against any chain shape regardless of this question.

Blocked on this: durable "fresh chain emulates pacific-1" behavior, which would let the test-side map collapse and prevent future consumers from re-paying the same drift discovery cost. Brandon's stated direction:

"We want sei-config to hold embedded canonical genesis configuration. That said, parameters updated through on-chain voting causes drift which is the issue we're seeing here. […] I was thinking we would configure sei-config to embed the default for a new chain so it matches pacific-1. For other networks, I think we should file an issue in sei-chain to follow-up on this."

"For this workstream, it's most important that the chain we are calling has the parameters we are using in the qa tests."

Workstream resolved with the map workaround; this issue tracks the durable fix.

Un-defer triggers (when to pick this up)

• Per-chain map in qa-testing/shared/chainParams.ts grows past ~3 entries (signal the workaround is becoming the system).
• A qa-testing failure surfaces that the map can't paper over (e.g., a non-deterministic-per-run value).
• A non-qa consumer (new chain bring-up, third-party tooling) hits the same drift.
• An imminent new-chain bring-up where "matches pacific-1" matters.

References

• sei-protocol/qa-testing#105 — test-side per-chain params map (the workaround).
• x/evm + consensus_params: module defaults diverge from pacific-1 operational state sei-chain#3421 — informational follow-up on x/evm module defaults vs production operational state.
• sei-protocol/sei-k8s-controller internal/task/bootstrap_resources.go:234 — where seid init actually runs (initContainer, not sidecar task).
• sei-protocol/seictl sidecar/tasks/generate_gentx.go:54 — the unimplemented GenesisParams plumbing channel.
• sei-protocol/sei-k8s-controller api/v1alpha1/seinodedeployment_types.go:108 — GenesisCeremonyConfig.Overrides map[string]string (the user-supplied side of the eventual layering).

[github-actions]

Thank you for opening this issue and taking the time to share your thoughts.
We’d love to keep moving this forward, but we need a bit more information from you.
Please add any additional details within the next 2 day(s) so we can continue collaborating on a solution together.
If we don’t hear back, the issue will close automatically — but you’re always welcome to reopen it when you’re ready.

[github-actions]

We’re closing this issue for now as we haven’t received additional input.
Please know that your effort is appreciated — and when you’re ready to revisit this, we’ll be here to pick it up again.
Thank you for contributing and helping us improve Sei.

[bdchatham]

Superseded — see #20 for the existing-chain sync angle.

#20 is scoped to keeping sei-config's embedded genesis for chains we already support (pacific-1, arctic-1, atlantic-2) in sync with sei-protocol/chain-configs via build-time fetch or submodule + a CI drift check. That's a distinct concern from this issue's original framing of "what shape should fresh / ephemeral chains inherit" — but it's the half of the embedded-canonical-defaults question that bit prod yesterday (arctic-1/atlantic-2 archive bootstrap panicked on whitelisted_codehashes_bank_send — drift between embedded genesis and what the seid binary expected).

Leaving this one closed; #20 is the active follow-up.