tempo-xtask create-zone generates genesis.json without Tempo fork activation fields

[0xrouss]

Describe the bug

tempo-xtask create-zone generates a zone genesis.json that omits the Tempo fork activation fields (t0Time through t4Time).

Because of that, a freshly created zone can boot with older protocol behavior unless the generated genesis is patched manually before the zone node is started.

This is easy to misdiagnose because zone creation itself succeeds, and the problem only shows up later as runtime/protocol behavior mismatches. In our case, the zone behaved as pre-T1C / pre-T3, which caused access-
key/keychain flows to fail in ways that initially looked like wallet or frontend issues.

Steps to reproduce

Steps to reproduce

1. Run tempo-xtask create-zone to generate a new zone.
2. Inspect the generated genesis.json.
3. Check .config and verify that Tempo fork activation fields such as t1cTime and t3Time are absent.
4. Start the zone from that generated genesis.
5. Exercise behavior that depends on post-fork Tempo keychain/access-key semantics.
6. Observe that the zone is running older protocol behavior unless the genesis is manually patched.

A minimal example of the workaround we had to apply was:

jq '.config += {
  t0Time: 0,
  t1Time: 0,
  t1aTime: 0,
  t1bTime: 0,
  t1cTime: 0,
  t2Time: 0,
  t3Time: 0,
  t4Time: 0
}' genesis.json

After adding those fields, the zone behavior matched the expected post-fork behavior.

Logs

Platform(s)

Linux (x86)

Container Type

Not running in a container

What version/commit are you on?

Built from source in a local checkout

If you've built from source, provide the full command you used

No response

Code of Conduct

• I agree to follow the Code of Conduct

[betterclever]

I can confirm this exists.

Freshly generated Zone genesis configs include the standard Ethereum fork fields at 0, but omit the Tempo fork fields from t0Time through t8Time. The important part is that this fails silently: missing Tempo fork fields are not inserted into the hardfork schedule, so those forks fall back to ForkCondition::Never.

Opened a small fix in #578.