Re-fired CreateChainTx for hanzo/zoo/pars/spc/osage on clean P-state after
pars-testnet genesis fix (added quasarTimestamp:253399622400 to satisfy
fork-ordering check). All 5 testnet brand L1s now isBootstrapped=true.
Cross-check via api.lux-test.network/ext/bc/<brand>/rpc all returning
chainId successfully. eth_blockNumber=0x0 (BOOTSTRAP-ONLY mode — block 1
will roll on first txn).
Two related fixes, both validated live on do-sfo3-lux-k8s lux-testnet:
genesis.json:
Replaced the embedded cChainGenesis field with the canonical 2-alloc
A-form (matches standalone configs/testnet/cchain.json per 14b85b2).
Old: gasLimit 0x3b9aca00, warpConfig blockTimestamp:0, embedded
genesisHash + stateRoot annotations.
New: gasLimit 0xb71b00, warpConfig blockTimestamp:1730517266,
skipPostMergeFields:true. Empirically produces block 0 hash
0x1c5fe37764b8bc146dc88bc1c2e0259cd8369b07a06439bcfa1782b5d4fb0995 —
the canonical RLP-matching hash from lux-testnet-96368.rlp.
upgrade.json:
Dropped two entries that were breaking luxd boot:
- warpConfig {blockTimestamp:0, requirePrimaryNetworkSigners:true}
Fails luxd validation: "invalid precompile upgrades: PrecompileUpgrade
(warpConfig) at [0]: disable should be [true]". Warp is already
pre-allocated in the C-Chain genesis alloc at address 0x02..05
(code:0x01, nonce:1), so an explicit upgrade entry is redundant and
breaks block 0 identity if it touches state.
- feeManagerConfig at blockTimestamp:900000000 (Sep 1998!)
Fails luxd validation: "config block timestamp (900000000) <
previous timestamp (1766708400)". The list is required to be
monotonically non-decreasing; 900000000 placed mid-list between
strictPQ entries at 1766708400 broke that. Mainnet doesn't have
this entry; testnet inherited it as drift and it's never
activated cleanly. Drop and re-introduce later via a properly
ordered timestamp if/when fee admin is needed.
Live verification:
- all 5 lux-testnet pods boot to block 0 = 0x1c5fe377…
- RLP imports cleanly to h=218 (0xda)
- external eth_blockNumber at api.lux-test.network/ext/bc/C/rpc → 0xda
Required for bootstrap-chain wire-compat with luxd v1.28.29. The
running node's wallet/network/primary uses utxo.ParseUTXO ZAP
dispatcher; the previous v0.3.4 emitted incompatible TypeKind/ShapeKind
discriminators (`wire: ShapeKind discriminator does not match expected
primitive shape`). Bump aligns the wire format.
Also adds local-codec replace because the published luxfi/codec@v1.1.4
does not contain the zapcodec package — that landed locally for the
2026-06 Wave 1D refactor and luxfi/node references it via the
zapcodec dispatch path.
inventory/brand-l1-2026-06-05-reset.json: post-reset canonical brand
L1 IDs. Supersedes brand-l1-2026-06-05.json (initial deploy with
orphan-prone naming).
The _orphan-l2/ directory was created by #109 brand-genesis migration
as a transitional cohabitation for pars + spc (which didn't yet have
dedicated brand repos). Both brands NOW have proper homes:
pars → ~/work/pars/genesis/networks/<env>/genesis.json
(structured: chain.yaml + genesis.json + genesis.sha256 + precompiles.yaml)
spc → ~/work/spc/genesis/networks/<env>/genesis.json
(mirrors pars layout)
Delete all 6 brand-genesis files from _orphan-l2 and the explanatory
README. Replace with a single MOVED.txt pointing readers at the brand
homes.
One way to do everything: brand genesis lives under the brand's own
workspace. State-repo at ~/work/lux/state/chains/ remains the empirical
provenance archive that brand homes track.
Mirrors the spc-mainnet genesis fix from
~/work/lux/state/chains/spc-mainnet/genesis.json into the deployment
mirror at configs/_orphan-l2/spc-mainnet/genesis.json. Same pattern as
zoo-universe commit 071afb4 (zoo h=799 RLP unblock).
Required so the 11-block spc-mainnet RLP archive
(b72f2602ec72360d742bf234a93f113b6614ba1f2d1935f63d8659bf61990ffc,
exported 2026-06-05) imports cleanly: the archive's block 1 parent
hash matches block 0 derived from the state-repo canonical genesis,
not the prior deployment-mirror variant.
Sync verified by `cmp` — files are now byte-identical.
Dockerfiles for the two RLP utilities + GH workflow calling the
shared hanzoai/.github docker-build@main workflow. amd64-only,
lux-build-linux-amd64 runner pool per the cross-org isolation rule.
Consumed by the lux-operator ExportSchedules CronJob (#69) and the
TenantImports Job (#122). Both default to the in-cluster MinIO
endpoint at http://s3.lux-system.svc.cluster.local:9000.
Pre-existing modifications in builder/, configs/configs.go,
pkg/genesis/{config,networks,types,cert_policy}.go intentionally
left untouched per CTO commit-by-name discipline.
luxfi/genesis only owns Lux primary-network genesis (mainnet/testnet/
devnet/localnet). Brand L1 genesis blobs now live next to the brand
that owns them, in each brand's universe repo:
hanzo: hanzoai/universe → configs/genesis/{mainnet,testnet,devnet}/
zoo: zooai/universe → configs/genesis/{mainnet,testnet,devnet}/
The pars-* and spc-* dirs have no separate universe repo yet — they
cohabitate this repo under configs/_orphan-l2/ until one is spun up,
explicitly marked as orphans (see configs/_orphan-l2/README.md).
This commit:
- removes configs/hanzo-{mainnet,testnet,devnet}/genesis.json
and configs/zoo-{mainnet,testnet,devnet}/genesis.{json,upgrade.json}
- leaves MOVED.txt tombstones at each old path pointing at the
new canonical home
- moves configs/{pars,spc}-{mainnet,testnet,devnet}/ to
configs/_orphan-l2/ (git mv — history preserved)
- adds pkg/genesis/no_brand_shadow_test.go which fails if any
genesis.json reappears under configs/hanzo-* / zoo-* / pars-* /
spc-* at the top level
- updates LLM.md + configs/mainnet/UPGRADE_NOTES.md doc refs to
point at the new locations
Zero Go code references the moved paths — configs/configs.go
//go:embed only covers Lux primary (mainnet testnet devnet localnet),
not brand dirs. Verified by full pkg/genesis test pass.
Symmetric with cmd/rlp-import. Thin HTTP client that:
1. Idempotency precheck reads <output-file>.sentinel on the local PVC
and short-circuits when Status=done + range matches — luxd is never
contacted in the warm-cron case.
2. Health-probes ${LuxdRPC}/ext/health (30s cap).
3. POSTs admin_exportChain via /ext/bc/${chain}/rpc with KMS_AUTH_TOKEN
bearer auth (same env-var contract as rlp-import).
4. Maps Status → exit code:
ok | noop → 0
interrupted → 4 (operator re-runs with from-height=HighestExported+1)
bad input → 1
luxd unreach → 2
admin RPC err → 3
Lives in the cmd/ nested module per the existing rlp-import precedent.
Builds with GOWORK=off; Makefile target `make rlp-export` does this for you.
Tests cover: flag parsing, "latest" resolution, all four idempotency
fall-through branches, happy path + noop + interrupted server responses,
luxd unreachable, admin RPC error, KMS_AUTH_TOKEN bearer header
plumbing. 14 tests, all green.
Symmetric Makefile additions: `make rlp-export`, `make rlp-import`,
`make cmds`, `make test-rlp-export`.
Standalone Go binary that runs the six-step tenant RLP import lifecycle
in a single process: sentinel check → fetch → sha256 verify → wipe
chainData → POST admin.importChain → touch sentinel. Replaces the shell
loop split between luxd-startup.yaml's main container and the operator's
tenant-import init container.
The binary is invoked by luxfi/operator as a K8s Job — one per
LuxNetwork.spec.tenantImports[i]. Exit codes are wired for K8s backoff:
1=bad input/SHA mismatch/404, 2=luxd unreachable (transient retry),
3=admin.importChain RPC error. Content-hash addressing matches
TenantImportSpec.ContentHash byte-for-byte so the operator and the
binary compute identical sentinel paths.
Tests cover all six lifecycle steps + every failure exit code.
Per cryptographer review of #114 safe-subset precompile activation:
maxPools=10000 on mainnet C-Chain is a state-bloat risk (each pool
entry is permanent; 10000 slots at 32-byte keys + accounting blobs
balloons the trie). Devnet retains 10000 for fuzz / load testing.
Mainnet cap of 2000 still comfortably exceeds expected DEX-V4 pool
count (~50 canonical pairs + room for long-tail). Increase later via
forward-dated upgrade if usage approaches the cap.
routerConfig zero-address placeholders are a separate fix (#48 contract
deploy must land first; only then does it make sense to point routerConfig
at the real V3 quoter/factory + V2 router/factory addresses).
eciesConfig already excluded per #99.
ECIES on a public permissionless chain has a fatal usability flaw:
the recipient's private key must be passed in calldata so the
precompile can perform the discrete-log unwrap. Calldata is public,
so any genuinely-encrypted use leaks the private key on the first
unwrap — defeats privacy. Any cosmetic use (e.g. registering the
config but never calling decrypt) is a footgun waiting to fire.
Brand L2 cchain.json files (hanzo/zoo/pars/spc-mainnet/testnet/devnet)
were scrubbed in a prior patch; devnet/cchain.json was the lone Lux
primary copy that still carried the entry. This brings devnet in line
with mainnet (no eciesConfig in primary genesis) and matches the live
cluster CM state (verified empty across all 3 envs).
UPGRADE_NOTES.md at configs/mainnet/UPGRADE_NOTES.md documents the
exclusion rationale for posterity. Removal is final — eciesConfig
will not be re-added to any Lux-network chain.
Spawned via bootstrap-chain after luxfi/node v1.28.29 LockedOutput
dispatcher fix unblocked the deployer's P-chain UTXO balance
(was returning 0 because vms/components/lux had no branch for the
(TypeKindReserved, ShapeKindLockedOutput) envelope that
stakeable.LockOut.Bytes() writes for vesting allocations).
Each row records (brand, blockchain ID, per-chain network ID, EIP-155
EVM chain ID). Single source of truth for the post-deploy chain IDs;
downstream consumers (operator chain-aliases CM, explorer routes,
ingress, gateway) should read this inventory rather than re-deriving.
Deployer: BIP44 m/44'/9000'/0'/0/5 from LUX_MNEMONIC.
Bootstrap-chain run:
/tmp/bootstrap-chain --uri=https://api.lux{,-test,-dev}.network \
--hrp=lux|test|dev --bip44-idx=5 \
--network-label=mainnet|testnet|devnet \
--configs-dir=$ROOT/configs \
--track-chain-ids=hanzo,zoo,pars,spc \
--chain-name-override="hanzo=hanzo,zoo=zoo,pars=pars,spc=spc" \
--skip-bootstrap-wait
(name override required because the content-hash default produced
"hanzo-b5ed62f6" which P-chain CreateChainTx rejected as "illegal
name character".)
Empirical root cause of the wrong genesis block 0 hash on mainnet C-Chain
was that 18 precompiles were declared at blockTimestamp:0 — those activate
during Genesis.ToBlock() via ApplyPrecompileActivations, which mutates the
state trie (SetNonce + SetCode([0x01]) per precompile address). That state
trie mutation shifted block 0 stateRoot off the canonical 0x2d1cedac…
and consequently the canonical block 0 hash 0x3f4fa2a0… became 0x467015e9…
Fix: forward-date all 18 precompiles from blockTimestamp:0 → 1766708400
(the Quasar activation), so they activate AT the hard fork rather than
during genesis state setup. Block 0 is now byte-identical to the canonical
RLP and importChain accepts the chain on first try.
Structural reordering (47 entries total, strictly non-decreasing
blockTimestamp — validator requires monotone + warpConfig disable+enable
pair):
[ 0] warpConfig disable @ 1766708399
[ 1-25] aiMiningConfig … bls12381PairingConfig @ 1766708400
[26] warpConfig enable @ 1766708400 (quorumNumerator=67,
requirePrimaryNetworkSigners=true)
[27-46] pulsarVerify … fixedPointMathConfig @ 1782864000 (PQ + extras)
Verified live on lux-mainnet C-Chain:
block 0 hash = 0x3f4fa2a0b0ce089f52bf0ae9199c75ffdd76ecafc987794050cb0d286f1ec61e ✓
Re-introduces the 7 EIP-2537 BLS12-381 precompile entries that #114
(8a40886) had to drop from mainnet because all 7 sub-configs returned
the same ConfigKey via Key() — only one could land in the registry
and DisallowUnknownFields parse rejected the other six.
Fixed upstream:
luxfi/precompile v0.5.35 (commit 794912f) — per-sub-config Key()
luxfi/evm v0.19.1 — bumps precompile dep
luxfi/node v1.28.23 — Dockerfile EVM_VERSION=v0.19.1
Activation: Quasar horizon Unix 1766708400 (2025-12-25 16:20 PT,
already past → active on next chain restart). Matches testnet's
existing 1766708400. Devnet stays at 0 (forever-active).
Cluster apply requires luxd image rebuilt from node v1.28.23+ tag
so the C-Chain plugin (built from evm v0.19.1) accepts the parse.
Quasar Edition rip. Reverts e6cec59 (the deployment-skew bandage) now
that luxfi/evm v0.19.0 ships:
- QuasarTimestamp Go field with json:"quasarTimestamp" tag
- DisallowUnknownFields strict decode at upgradeBytes parse
There is one name. quasarTimestamp. The strict decoder turns any
remaining etnaTimestamp residual into a loud parse error at boot
instead of a silent fork-disable at activation.
Brand L1 EVM genesis (hanzo/pars/spc/zoo mainnet) and primary mainnet
upgrade.json: etnaTimestamp removed; quasarTimestamp: 0 retained.
New envs filled to canonical (was missing, hidden by the skew):
- configs/devnet/upgrade.json
- configs/local/upgrade.json
- configs/localnet/upgrade.json
All carry quasarTimestamp:0 + every PQ precompile + cipher precompile
at blockTimestamp 0 (always-on for dev surfaces).
Mainnet keeps strictPQTimestamp:1766708400 (Dec 25 2025 16:20 PT)
as the forward-dated profile gate; PQ precompiles already active
from block 0.
Pairs with: luxfi/evm v0.19.0 + luxfi/node v1.28.22 bump.
Commit af356f7 (Etna → Quasar Edition) renamed the field in source
but the deployed EVM plugin at s3://lux-plugins/v1.1.0/ is built
from luxfi/evm@v0.18.18 which still reads NetworkUpgrades.EtnaTimestamp
(json tag etnaTimestamp). Until a new plugin ships with the renamed
struct, mainnet upgrade.json must use the pre-rename key — otherwise
the override silently drops and the plugin's verifyNetworkUpgrades
trips "etnaTimestamp not enabled, but fortunaTimestamp enabled" for
every brand L1 EVM that inherits this override structure.
Matches the on-disk content active on lux-mainnet luxd pods
(/data/configs/chains/C/upgrade.json, applied via the luxd-startup
ConfigMap patch on 2026-06-03). When the plugin upgrade lands the
key flips back to quasarTimestamp.
Two surgical fixes that get lux-mainnet C-Chain past the
`PrecompileUpgrade verification` gate in luxd v1.28.21 (evm@v0.18.18):
1. warpConfig toggle (disable@1766708399 + enable@1766708400)
C-Chain genesis already enables warp at blockTimestamp 1730446786
(luxfi/genesis@v1.7.1 cchain.json). Per the validator at
evm/params/extras/precompile_upgrade.go:133, the next upgrade for
an enabled precompile MUST flip state — a re-enable without an
intermediate disable trips "disable should be [true]". Inserting a
disable upgrade 1s before Quasar (1766708399) followed by re-enable
at Quasar (1766708400) satisfies the toggle requirement and
activates the new warp config (requirePrimaryNetworkSigners=true)
at the network-wide PQ rollout, consistent with #114 intent.
Also moved the two warp entries to AFTER the at-zero precompile
block so the monotonicity check at line 129 (timestamps must be
non-decreasing across the entire list) passes.
2. Dropped bls12381 sub-config entries (G1Add/Mul/MSM, G2Add/Mul/MSM,
Pairing). All 7 share a single Configurator.MakeConfig() in
luxfi/precompile@v0.5.23/bls12381/module.go that returns a Config
whose Key() method hard-codes G1AddConfigKey:
func (c *Config) Key() string { return G1AddConfigKey }
This makes the EVM plugin's verifyPrecompileUpgrades loop see all
7 entries as "bls12381G1AddConfig", the 2nd-7th fail the
disabled/enabled toggle check with "disable should be [true]" even
though the entries are byte-distinct in the JSON.
Underlying fix is in luxfi/precompile (instance-field key like
`dead`/`graph`/etc — not a const). Until that lands and a new
EVM plugin ships to s3://lux-plugins/, mainnet upgrade.json must
not enumerate bls12381 sub-modules. The plugin still gates them
correctly via strictPQTimestamp; the loss is only explicit
activation scheduling for the bls12381 sub-keys.
After these two fixes lux-mainnet C-Chain bootstraps cleanly
(info.isBootstrapped=true, /ext/health C check OK).
Surgical fixes for 4 RED chains on lux-mainnet:
1. configs/mainnet/upgrade.json — C-Chain
warpConfig[0]: blockTimestamp 0 → 1766708400 (Quasar Edition Unix)
luxd v1.28.18 rejected blockTimestamp:0 without disable:true at
genesis because C-Chain genesis already configures warp. Forward-
dating activation to Quasar (consistent with #114 intent: warp
activates with PQ precompiles at the network-wide PQ rollout).
2. configs/{hanzo,pars,spc}-mainnet/genesis.json
Added etnaTimestamp:0 between durangoTimestamp and quasarTimestamp.
Deployed luxd v1.28.18 (luxfi/evm@v0.18.18) field names predate the
Etna→Quasar rename — its NetworkUpgrades struct still uses
EtnaTimestamp json:"etnaTimestamp". Without it, fork-ordering check
in evm@v0.18.18 params/extras/config.go:407 fails:
"etnaTimestamp not enabled, but fortunaTimestamp enabled at
timestamp 0x..." Adding etnaTimestamp:0 satisfies the binary's
ordering check; quasarTimestamp stays as forward-compat alias for
post-rename binaries.
zoo-mainnet/genesis.json unchanged (has only evmTimestamp +
durangoTimestamp, no later forks → no ordering issue → already GREEN).
The earlier MNEMONIC unification commit (4383ad4) missed this CLI tool;
it was still reading the legacy MNEMONIC env name directly via
os.Getenv. Per the "one var, one way" rule the canonical name is
LUX_MNEMONIC across every code path in the genesis repo.
Updated in cmd/bootstrap-chain/main.go:
- Package-doc usage example: MNEMONIC="..." -> LUX_MNEMONIC="..."
- --print-addr-only flag help: scrub MNEMONIC -> LUX_MNEMONIC
- --key-file flag help + comments: MNEMONIC -> LUX_MNEMONIC
- loadKey() reads os.Getenv("LUX_MNEMONIC") instead of "MNEMONIC"
- Error message references LUX_MNEMONIC
No backcompat fallback: callers using the legacy MNEMONIC env get the
clear "LUX_MNEMONIC env var or --key-file required" error.
Verification:
- go build ./... -> clean
- go vet ./... -> clean
- go test ./... -count=1 -> ok configs, ok pkg/genesis
Comment-only scrub of upstream-fork residue in user-facing docstrings,
CLI help text, and LLM.md prose. No behavior change; no wire-format
change.
pkg/genesis/keys.go:
- DefaultNumAccounts doc: drop "AvalancheJS" from canonical-BIP44 wallet
list (was "Core, MetaMask, AvalancheJS, lux key derive" -> now
"Lux Wallet, MetaMask, lux key derive").
- LoadKeysFromMnemonic doc: drop "Avalanche/Lux BIP44 path" (just
"Lux BIP44 path") and "Core Wallet, AvalancheJS" wallet list (now
"MetaMask, Lux Wallet").
- LoadKeysFromMnemonic inner loop comment: same scrub
("Standard Avalanche/Lux secp256k1 child" -> "Standard Lux ...";
"matches Core Wallet, MetaMask, cast" -> "matches Lux Wallet, ...").
- BuildBIP44WalletAllocations doc: drop "SLIP-0044 coin type Lux
inherits from its upstream lineage" prose. Replaced with brand-
neutral "BIP44 coin type Lux uses by canonical convention".
cmd/genesis/main.go:
- bip44-wallet-keys flag help: drop "SLIP-0044 coin type 9000" ->
"BIP44 coin type 9000 canonical convention".
LLM.md:
- "Fortuna Timestamp Fix" prose: drop "Fortuna, Etna, and Granite
upgrades" naming. Replaced with "pre-Quasar Edition upgrades"
framing. The JSON field names (etnaTimestamp / fortunaTimestamp /
graniteTimestamp) are preserved in the example block because they
are the wire format consumed by luxfi/evm.
Intentionally kept (per task scope and forward-compat realities):
- params_test.go:33 + params.go:303 "avax HRP" rejection guards —
these are protective security tests/comments, not residue. The whole
point is to refuse "avax"-HRP bech32 addresses synthesized from a
canonical lux validator's 20 bytes. Stripping the "Avalanche" prose
would obscure why the guard exists.
- pkg/genesis/types.go:229 EtnaTimestamp uint64 field — this Go field
is a downstream mirror of the wire-format identifier defined at the
source of truth in luxfi/evm/params/extras/network_upgrades.go and
consumed by ~95 JSON genesis blobs, K8s startup manifests, academy
docs, and migration tooling. Renaming the genesis-repo mirror alone
would break JSON round-trip with every other consumer in the
ecosystem. A wire-format rename of EtnaTimestamp -> QuasarTimestamp
must originate in luxfi/evm and migrate every embedded genesis
config + every k8s manifest + every doc in one coordinated PR series.
That migration is OUT OF SCOPE for this commit and is reported back
to the dispatcher; see external-caller surprises below.
Verification:
- go build ./... -> clean
- go vet ./... -> clean
- go test ./... -count=1 -> ok configs, ok pkg/genesis
- grep '[Aa]valanche\|AvalancheJS\|Core Wallet\|SLIP-0044' pkg/genesis
cmd LLM.md
-> only 2 lines remain (params.go:303 + params_test.go:33),
both inside the protective HRP-rejection guard prose.
One env, one way. The genesis mnemonic is now read from exactly one
env var: LUX_MNEMONIC. The prior two-env fallback chain
(MNEMONIC > LIGHT_MNEMONIC) is gone. Per-env isolation is by a
DIFFERENT mnemonic per env (loaded from KMS), not by env-var name.
pkg/genesis/keys.go:
- New MnemonicEnvVar = "LUX_MNEMONIC" constant.
- getMnemonicEnv() reads only LUX_MNEMONIC; no fallback.
- LightMnemonic constant kept (it's the well-known dev seed VALUE;
pass it as the value of LUX_MNEMONIC for local nets).
- IsProductionNetwork docstring updated to spell out the canonical 4:
mainnet(1) / testnet(2) / devnet(3) refuse public mnemonics;
local(1337)+ allows LightMnemonic.
- Docstring rot purged: the prior "50M free + 50M vesting at 1%/year
over 100y" claim was a lie — buildConfigFromKeyInfos never wired the
100-period schedule (the code admits the schedule "overflows zapdb
batch limit"). Replaced with the truth: 1000 × 50M LUX on X-Chain
AND P-Chain, immediate spend; C-Chain is treasury-only (2T LUX).
- Dead code deleted: StakingStartTime, UnlockInterval consts,
buildUnlockSchedule() function.
pkg/genesis/allocations.go:
- VestingConfig struct removed.
- DefaultVesting() removed.
- WithVesting() builder method removed.
- Vesting branches in PChain() / PChainMap() collapsed to immediate-only.
- MainnetAllocations no longer calls WithVesting(DefaultVesting()).
pkg/genesis/validator_keys.go:
- VestingPeriods const removed.
- GeneratePChainAllocationsWithVesting() removed.
pkg/genesis/networks.go (new):
- Canonical primary-network-id table: MainnetID / TestnetID / DevnetID
/ LocalID = 1 / 2 / 3 / 1337. Matching C-Chain (EVM) chain IDs:
96369 / 96368 / 96370 / 31337.
- IsCanonicalPrimaryNetwork helper.
cmd/checkkeys/main.go:
- Reads LUX_MNEMONIC via genesis.MnemonicEnvVar (no fallback).
cmd/derive100/main.go:
- Usage hint updated: mnemonic-env: LUX_MNEMONIC.
cmd/genesis/main.go:
- Flag help, env-var docs, examples, and error messages all reference
LUX_MNEMONIC.
pkg/genesis/light_mnemonic_guard_test.go:
- All t.Setenv calls use LUX_MNEMONIC.
- Test labels reference LightMnemonic (the constant) not the dead env name.
configs/getgenesis_test.go:
- Comment updated: LightMnemonic instead of LIGHT_MNEMONIC.
CHANGELOG.md + LLM.md:
- Documented the unification + the dead-code removal.
The validator stake-lock (3-entry 5y/10y/20y schedule attached to the
validator's UTXO inside buildConfigFromKeyInfos at keys.go:1077-1083)
is unchanged — that locked-stake bucket is the only UnlockSchedule in
the canonical genesis path and the ProtocolVM needs it.
External-caller sweep: grepped ~/work/lux, ~/work/hanzo, ~/work/zoo,
~/work/luxfi for genesis.VestingConfig / genesis.DefaultVesting /
genesis.GeneratePChainAllocationsWithVesting / genesis.StakingStartTime
/ genesis.UnlockInterval — zero hits. Safe to delete. (luxfi/keys at
~/work/lux/keys has its own MainnetAllocations copy — separate repo,
not affected.)
Verification:
- go build ./... → clean
- go vet ./... → clean
- go test ./... -count=1 → ok configs, ok pkg/genesis
- grep '[^_X]MNEMONIC\|LIGHT_MNEMONIC' under pkg/genesis cmd configs →
zero matches (only CHANGELOG history + Python script local vars).
- grep VestingConfig|buildUnlockSchedule|GeneratePChainAllocationsWithVesting
under source → zero matches.
The fix-suffix symlinks (hanzofix-testnet, zoofix-devnet, etc.) were a
workaround for P-chain CreateChainTx name-collision against stale chain
rows from earlier bootstrap attempts. They duplicated the genesis blob
under a second path per (brand, env) pair, violating the "one canonical
way" rule.
Now that bootstrap-chain derives chain.name from the canonical genesis
content (commit 6046cdb), collision is impossible and the workaround
has no reason to exist. The configs/ directory is back to one canonical
{brand}-{env}/ per pair (4 brands x 3 envs = 12 directories).
11 symlinks removed:
hanzofix-{devnet,testnet,mainnet}
zoofix-{devnet,mainnet}
spcfix-{devnet,mainnet}
parsfix-{devnet,testnet,mainnet}
(spcfix-testnet was never created; zoofix-testnet was already gone.)
The CreateChainTx `name` argument is a P-chain-unique identifier — caller's
choice. The brand alias ("hanzo", "zoo", "spc", "pars") is user-facing and
belongs at the chain-aliases ConfigMap layer. Conflating the two forced
the {brand}fix-{env}/ symlink workaround when re-bootstrapping over stale
P-chain chain rows from prior CreateChainTx attempts.
Default chain.name is now content-addressed: "<brand>-<8hex>" where
8hex = hex(SHA256("<brand>|<env>|"||genesisBytes))[:4]. Properties:
- Idempotent: same canonical genesis → same chain.name → re-runs detect
the existing chain via platform.getBlockchains and skip CreateChainTx.
- Collision-free: different genesis bytes (any change to chainId, alloc,
config) → different chain.name → CreateChainTx succeeds against
P-chain instead of colliding with the previous stale row.
- Brand-rooted: "hanzo-3f4a1c8b" stays humanly legible without conflating
the chain.name with the user-facing brand alias.
Spec struct renamed: Name → Brand (user-facing) + ChainTxName (P-chain ID).
Result JSON gains "brand" and "chainTxName" fields so downstream
consumers (chain-aliases CM, explorer-chains CM, gateway routes) can pin
on the brand value without parsing the chain.name suffix.
Override path: --chain-name-override "<brand>=<name>,..." pins explicit
names for legacy reattachment scenarios.
4 new tests pin the contract:
- Deterministic (same input → same output)
- DifferentGenesisDifferentName (bytes change → name changes)
- DifferentBrandDifferentName (brand-scoped)
- DifferentEnvDifferentName (env-scoped)
All 14 tests pass.
After Track D recovery (2026-06-02), brand chain names hanzo/zoo/spc/pars
were already taken on P-chain — CreateChainTx rejects duplicate names.
The 2026-05-27 recovery introduced "zoofix" + "spcfix" as the re-fire
chain names for testnet; this commit extends the same pattern to all
four brands × all three envs, with symlinks pointing at the canonical
brand-{env}/genesis.json blobs.
This lets bootstrap-chain --track-chain-ids=hanzofix,zoofix,spcfix,parsfix
re-fire CreateChainTx with the same canonical genesis without name
collision.
Rolled in production 2026-06-03 03:00-04:00 UTC:
- testnet: hanzofix=2jDUTLY5qiu6F9HqZxPSJ5EZ6YXgitDvdKrouPb49pBA89CSgE,
parsfix=2iGzgAvBDh5W4duZV6TPjjaDnnZ85pXSvaTuEMUZBCqTUz9nJx
(zoofix + spcfix were already in place from 2026-05-27)
- devnet: hanzofix=2Jtt431M99BpEVzRCv9KKNRdyUtkYadA3yzXxzfbPhXGwLTT3g,
zoofix=22xVZa9Kt74gh5NvGkePT4hYYWNoDApiznwx8a4z9WYVKG9fYZ,
spcfix=2Vw5ohskeRoHeTgQn3Zxdp3KSc9zqkvaCBvCA1ek6d6VKCSuuZ,
parsfix=ySWSTEgr2ZdVcpU1gNwAnPeXWFthVHW2TmFdEMSFy4kFNpTML
- mainnet: BLOCKED — legacy LUX vs staking asset fee mismatch
(separate asset-migration tx required first).
Close the Track D root cause that produced empty 0xa6aecc6c... state
roots on testnet brand L2s (hanzo, zoo, spc, pars). Pre-existing brand
L2 JSONs under configs/<brand>-<env>/genesis.json are already clean,
but nothing prevented a future generator (or a hand-edit cribbed from
the primary network's testnet/genesis.json embedded cChainGenesis blob)
from reintroducing those fields.
The fields override the result of luxfi/geth/core/genesis.go::
Genesis.Commit's flushAlloc — a stale value silently displaces the
canonical alloc trie, then the L2 boots with block 0 stateRoot pointing
at a trie node that was never persisted. That's the exact failure mode
producing "missing trie node 0x2d1cedac..." errors on the existing
testnet hanzo L2.
Changes:
- cmd/bootstrap-chain/main.go: hard-refuse any genesis carrying a
non-empty stateRoot or genesisHash before any CreateChainTx burns
LUX. Error names the specific geth/core/genesis.go lines and the
Track D context so the operator can fix at source.
- cmd/bootstrap-chain/main_test.go: TestBrandL2GenesisHasNoStateRoot-
OrGenesisHash walks every <brand>-<env>/genesis.json under configs/
and asserts the absence of both fields. Test self-checks that at
least one brand L2 dir was found so a path bug can't silently pass.
The historical Lux primary C-Chain header workaround that needed these
overrides is dead — the empirical block-0 hash now lives in
configs/mainnet/cchain.json. Brand L2 JSONs MUST stay clean.
Authorized by 2026-06-02 destructive recovery sweep — Track D root
cause closure.
The primary-testnet C-Chain upgrade schedule referenced three precompile
keys that the pinned luxfi/precompile v0.5.27 ships without
RegisterModule():
- kzg4844Config
- secp256r1Config
- ed25519Config
extras.UpgradeConfig.UnmarshalJSON rejects unknown ConfigKeys with
"unknown precompile config: <key>", so luxd would refuse to start the
testnet C-Chain VM at the next pod restart. The mainnet copy was
scrubbed in the same patch series (configs/mainnet/upgrade.json).
zoo-mainnet's standalone upgrade.json is out of scope here and will be
addressed under its own task.
47 entries remain (was 50): warpConfig + 19 net-new at the Quasar
Edition timestamp 1766708400 + 27 forward-dated cryptography
precompiles also at 1766708400. JSON re-parsed and validated.
Followup: re-add the three keys after bumping luxfi/precompile to a
version that declares RegisterModule() for kzg4844, secp256r1, and
ed25519 (mirroring the mainnet plan in UPGRADE_NOTES.md §Followup).
upgrade.json: 46 precompileUpgrades (was 49). Removed 3 unregistered
EIP entries surfaced by Red round-2 vector V19. All non-warp PQ/crypto
primitives forward-dated to blockTimestamp 1782864000 (2026-07-01
UTC) per #114 v3. evmTimestamp/durango/etna/fortuna/granite hold at 0
(genesis-active); strictPQTimestamp 1766708400 (2025-12-26 00:20 UTC)
unchanged.
Brand L2 genesis (hanzo/pars/spc/zoo × devnet/mainnet/testnet, 11
files): scrubbed legacy eciesConfig fields — never registered in the
canonical precompile table, would refuse-init when checkPrecompile
Compatible ran on next pod recreate. zoo-mainnet was cleaned in
218ff42 and is unchanged here.
Task #114 — extend the Lux primary C-Chain upgrade.json with the 30 missing
safe-subset precompiles, forward-dated to blockTimestamp=1782864000
(2026-07-01 00:00 UTC = 29 days from authorship 2026-06-02, exceeding the
14-day validator-buffer minimum). Brand L2s (hanzo/zoo/pars/spc) already
carry these in their block-0 genesis; this catches the primary network up.
Safe subset framing:
- Brand L2 genesis = 43 precompiles (~/work/lux/genesis/configs/hanzo-mainnet/genesis.json).
- Primary C-Chain = 42 (brand L2 minus eciesConfig) + 3 standard EIP
precompiles brand L2s don't carry (kzg4844Config, secp256r1Config,
ed25519Config) + 3 burn handlers (dead*Config) + warpConfig.
Total after patch: 49 entries:
- 1 warpConfig at blockTimestamp=0 (genesis pre-alloc at 0x0200…0005).
- 18 already-live precompiles at blockTimestamp=0 (aiMining, blake3,
cggmp21Verify, dead*x3, dexConfig, routerConfig, fheConfig, frostVerify,
graphConfig, hpkeConfig, mldsaVerify, mlkemConfig, pqcryptoConfig,
ringConfig, slhdsaVerify, zkConfig — the set inlined in
~/work/lux/universe/k8s/lux-mainnet/luxd-startup.yaml UPGRADE_JSON).
These MUST stay at blockTimestamp=0 — luxd's checkPrecompileCompatible
refuses to boot if an already-live precompile is rescheduled.
- 30 safe-subset additions at blockTimestamp=1782864000 (2026-07-01 UTC):
Pulsar + Magnetar + P3Q + Corona threshold; HQC; BLS12-381 G1/G2/MSM/
Pairing x7; Curve25519, X25519, Sr25519, BabyJubJub, Pedersen, Poseidon,
Pasta, X-Wing; Compute Market, Bridge Registrar, StableSwap, VRF,
Attestation, Anchor, FixedPointMath, KZG-4844, secp256r1, Ed25519.
Exclusions:
- eciesConfig — deliberately excluded per the rationale in
~/work/lux/precompile/x25519/contract.go (lines 17-23). ECIES requires
the recipient's private key in calldata; calldata is world-readable on
a public chain, irrecoverably exposing the key. Symmetric (AES,
ChaCha20) precompiles were removed for the same reason. X25519/ML-KEM/
HQC/X-Wing are retained because they expose only ciphertexts and
ephemeral public material, never secrets.
- contractDeployerAllowListConfig, contractNativeMinterConfig,
txAllowListConfig, rewardManagerConfig — admin-gated allowlists. The
primary C-Chain is permissionless by design; activating these would
hand admin to an arbitrary address (trust hazard) or activate empty
(dormant gate, strictly worse). They remain available for subnet/L2
activation where an admin role is appropriate.
- feeManagerConfig — removed from canonical. Previously parked at
blockTimestamp=900000000 (1998) as a registry-slot placeholder; that
placement violates the monotonicity rule enforced by
extras.ChainConfig.verifyPrecompileUpgrades. Activate via a separate
forward-dated governance event with admin addresses explicitly assigned
if needed; the chain-config feeConfig is already pinned directly.
Strict-PQ profile gate (NetworkUpgradeOverrides.strictPQTimestamp =
1766708400) activates contract.StrictPQReporter on the ChainConfig from
the Quasar Edition activation (2025-12-25 16:20 PST). All classical
pairing-based / discrete-log precompiles call
contract.RefuseUnderStrictPQ(state) at the top of Run() (verified across
bls12381 + secp256r1 module.go dispatchers + babyjubjub / pasta /
pedersen / poseidon / curve25519 / x25519 / sr25519 / ed25519 / frost /
cggmp21 / kzg4844 contract.go). The 30 forward-dated activations all
fall after strictPQTimestamp, so no window exists where a classical
primitive executes permissively on the primary network.
Tests (luxfi/evm params/extras):
- TestMainnetUpgradeJSON_IsForwardCompatibleWithLiveActivations PASS
(every already-live precompile preserved at the same blockTimestamp).
- TestMainnetUpgradeJSON_PrecompileTimestampsAreMonotonic PASS
(0 → 0 → ... → 0 → 1782864000 → ... → 1782864000, monotonic).
- TestMainnetUpgradeJSON_WarpRequiresPrimaryNetworkSigners PASS
(warpConfig.requirePrimaryNetworkSigners=true).
- TestMainnetUpgradeJSON_HasStrictPQActivation PASS
(strictPQTimestamp=1766708400).
- TestMainnetChainConfig_HasStrictPQTrue PASS (chain-configs side).
UPGRADE_NOTES.md sidecar documents the exclusion rationale, the activation
tier table, the strict-PQ posture, and a red-review checklist.
RED REVIEW REQUIRED — do not push to origin without sign-off. Mainnet
primary network upgrade is consequential.
Follow-up (separate PRs, out of scope):
- ~/work/lux/universe/k8s/lux-mainnet/luxd-startup.yaml currently writes
the same UPGRADE_JSON to all 5 EVM chain config dirs (C + brand L2s);
brand L2s already carry these precompiles in their block-0 genesis, so
the override is at best a no-op and at worst a wedge. Patch to scope
the inline upgrade.json to the primary C-Chain only and refresh its
contents from this canonical file.
Operators that already hold a 32-byte hex secp256k1 deployer key on disk
(e.g. ~/work/lux/keys/deployer-test-dev/private.key used to fund the
test+dev primary genesis allocations) can pass --key-file <path> instead
of MNEMONIC + --bip44-idx. MNEMONIC path remains the default.
Drove the brand-L2 CreateChainTx registration for testnet + devnet
(closes universe #168) — 8 chains, all bootstrapped 3/3 pods per env.
go.mod: add local replace github.com/luxfi/node => ../../node to pick up
the wallet's P-only fail-soft (lux/node@HEAD). Drop the replace once
luxfi/node tags the change. tidy refreshed transitive deps (accel v1.1.4
→ v1.1.8, local genesis v1.12.19 → v1.13.8) — these are no-op for the
bootstrap-chain logic.
LP-018 §Canonical EVM chainID map specifies the (brand × env) → uint64
table. The existing typed lookup EVMChainID(family, env) takes a
NetworkFamily + uint32; CRD validators, admission webhooks, and
operator-side helpers often hold brand+env as raw strings instead.
EVMChainIDFor wraps EVMChainID with case-insensitive string parsing for
both brand and env ("mainnet"|"main", "testnet"|"test", etc.). No
parallel data table — one source of truth.
Also retire stale "sovereign=true|false per LP-182" docstrings on
Family* constants; the locked NetworkSpec carries only networkID +
validators, and FamilyLiquid/FamilyPars can run as either Anchored
(validators > 0 on a Lux primary) or Independent (own networkID).
Update LP-182 references to LP-018 (LP-182 archived).
EVMChainID(family, env) is the source-of-truth lookup that operator
CRs and per-network genesis blobs must agree with. Total over the closed
set published in LP-182:
Lux x {mainnet,testnet,devnet,local} = {96369, 96368, 96370, 31337}
Hanzo x {mainnet,testnet,devnet} = {36963, 36962, 36964}
Zoo x {mainnet,testnet,devnet} = {200200, 200201, 200202}
SPC x {mainnet,testnet,devnet} = {36911, 36910, 36912}
Liquid x {mainnet,testnet,devnet} = {8675309, 8675310, 8675312}
Pars x {mainnet,testnet,devnet} = {7070, 494950, 494951}
NetworkFamilyOf(chainID) provides the inverse lookup so a CR validator
can detect an evmChainID typo early. ParseNetworkFamily is
case-insensitive on free-form input.
Unknown (family, env) cells return (0, false) — never a silent zero.
Empirically verified 2026-06-02 via ~/work/lux/state/cmd/rlp-vs-genesis:
RLP block 1 parentHash: 0x1c5fe37764b8bc146dc88bc1c2e0259cd8369b07a06439bcfa1782b5d4fb0995
Reverted genesis.json: 0x1c5fe37764b8bc146dc88bc1c2e0259cd8369b07a06439bcfa1782b5d4fb0995
Result: MATCH
Same anti-pattern as mainnet (ae7f530) and zoo-mainnet (218ff42): HEAD had 43
precompiles baked into config.precompileUpgrades at blockTimestamp:0, producing
a non-canonical hash that does NOT match the historical RLP.
Reverted to pristine 2-alloc form (verified against lux-testnet-96368.rlp):
- treasury 0x9011E888...
- warp pre-alloc at 0200000000000000000000000000000000000005 (code:0x01, nonce:1)
- timestamp 0x67259912 (1730517266) — distinct from mainnet's 0x672485c2
- gasLimit 0xb71b00, baseFeePerGas 0x5d21dba00
- no precompileUpgrades in config (forward-dated activations go in upgrade.json)
upgrade.json: sibling file (copy of mainnet's) activating all 43 PQ precompiles
at blockTimestamp 1766708400 (Dec 25 2025 16:20 PST). warpConfig stays at
blockTimestamp:0 because the alloc already pre-bakes its address. Preserves block
0 identity (so RLP imports cleanly) while activating PQ precompiles at the
network upgrade timestamp.
Empirically verified 2026-06-02 via ~/work/lux/state/cmd/rlp-vs-genesis:
RLP block 1 parentHash: 0x7c548af47de27560779ccc67dda32a540944accc71dac3343da3b9cd18f14933
Reverted genesis.json: 0x7c548af47de27560779ccc67dda32a540944accc71dac3343da3b9cd18f14933
Result: MATCH
Previous HEAD had 43 precompiles baked into config.precompileUpgrades at
blockTimestamp:0 — same anti-pattern as the mainnet C-Chain wedge — producing
non-canonical 0x24ac5ff9... that does NOT match the historical RLP.
Reverted to the pristine 2-alloc form (verified empirically against
~/work/lux/state/rlp/zoo-mainnet/zoo-mainnet-200200.rlp):
- treasury 0x9011E888...
- warp pre-alloc at 0200000000000000000000000000000000000005 (code:0x01, nonce:1)
- timestamp 0x6727e9c3, gasLimit 0xb71b00, baseFeePerGas 0x5d21dba00
- no precompileUpgrades in config (forward-dated activations go in upgrade.json)
upgrade.json: sibling file activating all 43 PQ precompiles at blockTimestamp:
1766708400 (Dec 25 2025 16:20 PST per network_activation_2025_12_25.md).
warpConfig stays at blockTimestamp:0 because the alloc already pre-bakes its
address. This preserves block 0 identity (so RLP imports cleanly) while
activating PQ precompiles at the network upgrade timestamp.
Same fix pattern as mainnet C-Chain (commit ae7f530).
Unblocks: #45 Zoo mainnet RLP import cascade.
Empirically verified 2026-06-02 via ~/work/lux/state/cmd/genesis-hash-empirical:
Block 0 hash: 0x3f4fa2a0b0ce089f52bf0ae9199c75ffdd76ecafc987794050cb0d286f1ec61e
RLP parent: 0x3f4fa2a0b0ce089f52bf0ae9199c75ffdd76ecafc987794050cb0d286f1ec61e
Result: MATCH
cchain.json reverted from 1-alloc HEAD form (which produced 0x2f4ae11a — does NOT
match historical RLP) back to the canonical 2-alloc form: treasury 0x9011E888 +
warp precompile pre-alloc at 0200000000000000000000000000000000000005 with
code:0x01, nonce:1, skipPostMergeFields:true, timestamp 0x672485c2,
baseFeePerGas 0x5d21dba00, feeConfig.targetGas 500000000.
upgrade.json: all non-warp precompile activations moved from blockTimestamp:0 to
blockTimestamp:1766708400 (Dec 25 2025 16:20 PST per LP-9xxx fork). This stops
core.ApplyPrecompileActivations from running at genesis time and mutating the
state root away from 0x2d1ceda.... Only warpConfig stays at blockTimestamp:0
because the alloc already pre-bakes its address.
cchain.canonical.json: annotated documentation companion preserving genesisHash
and stateRoot fields for human readers.
Authoritative empirical study + tooling: ~/work/lux/state/LLM.md section
"RLP <-> Genesis <-> Upgrade — Canonical Migration Contract (2026-06-02, empirically verified)".
Unblocks: #131 (mainnet C-Chain RLP repro), #177 (Phase E retry), #167 cascade.
The 'reject non-lux HRP' case had checksum cr6m3y on payload that
hashes to 537yam — i.e. invalid checksum. ParseAddress's bech32
decode rejected before the HRP check, so the assertion ('unsupported
HRP "avax"') never fired.
Use a different HRP (btc) with a valid checksum on the same 20-byte
payload so the rejection lands at the HRP whitelist, not bech32 decode.
dexConfig now ships with an explicit protocolFeeController
(0x9011E888251AB053B7bD1cdB598Db4f9DEd94714 — the LUX_MNEMONIC-derived
treasury, KMS-controlled). This is the transitional placeholder while
the production multisig is being deployed; downstream PR will swap to
the multisig address before mainnet. The placeholder is NOT a publicly-
known Anvil/Hardhat key — it is a deterministic key derived from a
mnemonic that lives only in KMS.
precompile v0.5.28 refuses activation when dexConfig.protocolFeeController
is empty or matches a known Anvil/Foundry dev address, so this entry
MUST carry the field to bootstrap the chain. Without it luxd halts at
the activation block.
routerConfig wired with zero v2/v3 router/factory addresses (the
zero-as-skip semantics in precompile/dex/router_module.go).
Three previously-missing precompiles registered with the modules.Module
registry in precompile v0.5.28 are now gated to activate at the Quasar
Edition timestamp (1766708400 = 2025-12-25 16:20 PST):
- kzg4844Config — LP-3665 EIP-4844 KZG point-evaluation extensions
- secp256r1Config — EIP-7212 passkey/WebAuthn P-256 verify
- ed25519Config — LP-3211 Solana/TON/XRP cross-chain signature verify
Activation timestamp 1766708400 is unchanged across the whole Quasar
block — single per-edition timestamp consistent with every other
precompile in the cohort.
Replace configs/mainnet/cchain.json with the minimal genesis shape that
matches the historical RLP archive (= byte-equal to
~/work/lux/state/pebbledb/configs/lux-mainnet-96369/genesis.original.json,
SHA256 55114f20049fc9fa8aa4be7b5b6c4057ad9756b5718191b99cbf42bb8a512ad8).
Previously cchain.json had baked-in:
- arrowGlacierBlock, cancunTime, blobSchedule, evmTimestamp (modern EVM forks)
- Warp precompile alloc at 0200...0005 (code=0x01, nonce=0x1)
- Two-alloc shape (warp precompile + 0x9011 deployer)
These additions changed the genesis hash from the RLP-matching value to
0x3f4fa2a0..., which is why admin_importChain has been failing.
NEW shape (matches RLP, one source of truth):
- Bare EIP block activations (homestead through london at 0)
- feeConfig + warpConfig {blockTimestamp: 1750805381, quorumNumerator: 67}
- Single alloc (0x9011 deployer treasury)
- No modern fork or precompile baked into genesis
NEW configs/mainnet/upgrade.json carries forward-dated activations:
- Quasar Edition (Dec 25 2025 16:20 PST = unix 1766708400):
42 PQ precompiles (eciesConfig excluded per task #99 as unsafe on
public chain), cancunTimestamp = 1766708400
- Etna era (Dec 25 2024) already in effect: etnaTimestamp = 1735143600,
warpConfig + feeConfigManagerConfig kept as before
- 42 entries = full set from hanzo-mainnet config MINUS eciesConfig
Block 0 identity preserved → RLP imports cleanly → forward-dated
Quasar Edition rules activate at runtime without changing block 0 hash.
Re-embedded cChainGenesis in configs/mainnet/genesis.json to match the
new cchain.json (jq --rawfile).
Companion docs:
- ~/work/lux/migration/LLM.md (Quasar Edition migration spec)
- ~/work/lux/state/LLM.md "RLP ↔ Genesis ↔ Upgrade Migration Contract"
CRITICAL: empirical verification of the new genesis hash against the RLP
must happen at deploy. The killed CCHAIN-LIVE agent reported the running
RLP expects 0x595e9630..., but earlier LLM.md notes (line 540) reference
0x3f4fa2a0... as the historical-RLP hash. The two diagnostics
contradict — likely indicates the RLP was regenerated at some point or
two RLP versions exist. The new cchain.json matches genesis.original.json
which lives next to the RLP archive at the state repo, so empirically it
should match the current /data/lux-mainnet-96369.rlp.
Hanzo AI