fix(mainnet): DEFUSE C-Chain brick landmine — remove retroactive Multicall3 stateUpgrade[1]

stateUpgrades[1]@1784415311 (Multicall3 at 0xcA11...CA11, added in b6f6170) is a
latent brick for C-Chain 96369. The C-Chain EVM is github.com/luxfi/evm, whose
config load is strict:

  - plugin/evm/vm.go:962  dec.DisallowUnknownFields()
  - params/extras/state_upgrade.go checkStateUpgradesCompatible():
      len(newUpgrades) > len(activeUpgrades) => "cannot retroactively enable
      StateUpgrade[N]" => ConfigCompatError => VM init refused

Timestamp 1784415311 (2026-07-19) is already in the past. The live 5/5 run the
proven-canonical config (c3a1763) which has exactly ONE applied stateUpgrade,
[0]@1766708400 (23-account Path-A). The moment any luxfi/evm node rolls this
config with head past 1784415311, it computes 2 activated stateUpgrades vs the
1 in applied history -> retroactive error -> C-Chain bricks (warpConfig class).

Fix: remove stateUpgrades[1] entirely. Eliminates the retroactive-state-upgrade
brick class. File is now content-identical to proven-canonical c3a1763
(stateUpgrades=[0] only). Repo-config change ONLY — not rolled to live nodes.

Mainnet Multicall3 predeploy must instead use a FUTURE-dated monotonic
stateUpgrade or a deterministic factory (see deploy plan) — never a retroactive
one. Devnet got Multicall3 via CreateX factory with ZERO stateUpgrades.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
This commit is contained in:
zeekay
2026-07-20 15:02:45 -07:00
co-authored by Hanzo Dev
parent b6f6170d77
commit 060d74eedf
File diff suppressed because one or more lines are too long