[samlaf]

The genesis binary defined its own GenesisConfig — a partial copy of summit_types::Genesis that predated the staking fields. With no deny_unknown_fields, deserializing the template into it silently dropped validator_minimum_stake / validator_maximum_stake, so the emitted genesis.toml was missing fields the node's runtime loader requires and summit run panicked at startup ("missing field validator_minimum_stake").

Load and serialize the template as summit_types::Genesis directly and drop the local struct, so there is a single genesis schema the binary can't drift from.

Context: this surfaced in the Seismic deploy flow, whose operator CLI shells out to this genesis binary to build a network's genesis. A few rough edges there: it has to be built and installed via cargo; it's named just genesis, which collides easily on PATH and doesn't read as part of summit; and (as above) it's a separately-built, independently-versioned copy of the node's genesis logic, with nothing guaranteeing it matches the summit running on the node.

Proposed alternative designs

• Move assembly into the node: have sendGenesis take the template + validator set rather than a pre-built genesis.toml, and let each node build its own genesis with its own Genesis type and sort — e.g. a shared assemble_genesis(template, validators) backing both this binary and the RPC handler. The node could also fill eth_genesis_hash from its own reth, which would remove the external binary and the version-skew question altogether.
• Or, if a standalone tool is preferred, fold this into the summit binary as a summit genesis subcommand (alongside run/keys), so it shares the genesis types and isn't a stray genesis on PATH.