Chain binary (v1.3.13) panic in SetChainHealth + genesis mismatch prevents sync and registration

[skimaharvey]

Environment

• CLI: v5.16.0 (also reproduced on v5.9.2)
• Chain binary: v1.3.13 (hyperspace-agentic-blockchain)
• OS: Ubuntu 24.04, kernel 6.17.0, x86_64
• GPU: NVIDIA RTX 3060 Ti (8GB VRAM), CUDA 13.0
• CPU: AMD Ryzen 7 5700X (16 threads), 47GB RAM

Problem

Node runs, connects to 15–26 peers, gets elected for pulse rounds, but never earns points because of two issues:

1. Chain binary panic (~90 seconds after start)

panic: runtime error: slice bounds out of range [:10] with length 0

goroutine 1 [running]:
github.com/hyperspace-a1/hyperspace-edge/cmd.(*AutoUpdater).SetChainHealth(0x1f9e03d?, {0x261dc58?, 0xc000532610?}, {0x0?, 0x5?})
    /lambda/nfs/titan/a1-blockchain-hyperspace/hyperspace-edge/cmd/autoupdate.go:186 +0x192
github.com/hyperspace-a1/hyperspace-edge/cmd.runServer({0x2642e18?, 0xc000354aa0?})
    /lambda/nfs/titan/a1-blockchain-hyperspace/hyperspace-edge/cmd/server.go:1576 +0x6b45

SetChainHealth receives a nil string (ptr=0x0, len=5) and tries [:10] on it. This is not controlled by the --auto-update flag — it is called from runServer() unconditionally. The chain binary crash-loops 3 times then gives up.

2. Genesis mismatch (block 0 hash differs from network)

	Local node	Network (all 4 bootnodes)
Block 0 hash	0xb6db9d45dcf698a50aac9b49ed19c6ccd018999b2ad60554763ae93256c78ae6	0xb56673843d4881e7172b5d1eac1bc8a621656cf7f7b10149535fefd9b3c8cd96
Timestamp	0x69bb27f9 (Mar 18)	0x69c0419e (Mar 22)

The genesis.json bundled in the CLI binary and produced by hyperspace-agentic-blockchain join produces the wrong block 0 hash. The network validators were initialized with a different genesis (March 22 re-genesis). Even if the chain binary didn't crash, the node would never sync.

Result

• Sync: unknown — chain never syncs (genesis fork)
• Registered: no — can't register on-chain
• Points: 0.00 — pulse rounds elected but never complete
• LM: 0.00x — liveness multiplier stays at 0

What I tried

1. Stripped --auto-update flag via wrapper script — no effect (crash path is unconditional in runServer())
2. Wiped ~/.hyperspace/edge-data/ — temporarily delayed crash but it recurs after ~90s
3. Upgraded from v5.9.2 to v5.16.0 — same chain binary, same crash
4. Used hyperspace-agentic-blockchain join --role relay — produces identical stale genesis with the wrong block 0 hash
5. Verified bootnode connectivity — all 7 bootnodes reachable on port 30301, chain binary connects to 4-7 peers at transport level
6. Checked Groot DHT — logs show [WARN] No bootstrap nodes configured because --groot.bootnodes is never passed by the CLI

Additional notes

• This appears related to Miner key file address doesn't match derived address from privateKey #43 (same Registered: no, zero points symptoms)
• The wallet show command also fails with "install ethers" — ethers is not bundled in the SEA binary
• The [STATS] logs consistently show Points: 0.00 | LM: 0.00x despite repeated pulse round elections
• The better_sqlite3.node native module also fails to load: [DB] SQLite init failed (node will still connect): No such built-in module

Node info

• Peer ID: 12D3KooWQcgXCFcoaBPoW3euyVh5dxqAa65qJX9gLkK9TT3wdBai
• Agent: 0xFOKMT836

[skimaharvey]

Update: Genesis timestamp is hardcoded in the chain binary

After further investigation, the genesis mismatch cannot be fixed locally. Here's why:

1. The genesis.json file does not contain a timestamp field — it only has allocations, validators, and chain config
2. I patched the file to add "timestamp": "0x69c0419e" (the network's timestamp) — the chain binary ignored it
3. Block 0 still shows timestamp: 0x69bb27f9 with hash 0xb6db9d45... regardless of what's in the JSON file
4. Making the file immutable (chattr +i) causes the CLI to detect "Corrupt genesis" and skip the chain entirely

This confirms the genesis timestamp is hardcoded inside the hyperspace-agentic-blockchain binary (chain-v1.3.13). The binary was built with the pre-March-22 genesis parameters, but the validator network was re-initialized on March 22 with timestamp 0x69c0419e.

The fix requires rebuilding the chain binary with the correct genesis parameters to match the live validator network.

[skimaharvey]

@twobitapps — Every CLI version (v5.9.2 through v5.16.3) and even fresh installs via curl | bash all ship chain-v1.3.13 with a genesis that produces block 0 hash 0xb6db9d45..., but the live validators run 0xb5667384... (March 22 re-genesis). Sync receives blocks but rejects them all with invalid parent block.

This affects every new node joining the network right now. Is there an updated chain binary or genesis in the pipeline?

[skimaharvey]

Update: I've now paid/signed up to register as a miner and received my validator key. Setting it up with hyperspace start --chain-role miner:

• The CLI picks up my validator key fine — logs show [CHAIN] Validator key found — stake requirement bypassed and Chain: miner
• But the node still reports Registered: no, Sync: unknown, Points: 0.00
• Chain binary runs briefly, receives blocks from peers, but rejects every one with invalid block: invalid parent block — because local block 0 hash (0xb6db9d45...) doesn't match network's (0xb5667384... from the March 22 re-genesis)
• I've tested v5.16.3 through v5.19.3 (current latest). Every CLI version downloads the same stale genesis, regardless of whether --chain-role miner is used

So even with a paid/signed miner key, registration is completely blocked by the genesis mismatch. Would love an update on when a fixed chain binary or genesis will be distributed — this affects every new miner signup.

Validator address: 0x871D52D91f6ebd4049EFcBb5503bBbb00c1BebA7

[Hafuyya]

Confirming this is still present with chain binary v1.4.0 (Mysticeti consensus).

Manually downloaded chain-v1.4.0 from hyperspaceai/agi releases and installed it with libmysticeti_consensus.so. The binary runs, but genesis block hash is still 0xb6db9d45... (March 18 genesis) — same mismatch as v1.3.13.

The CLI installer (curl -fsSL https://download.hyper.space/api/install | bash) as of v5.20.0 also doesn't ship v1.4.0 or its required libmysticeti_consensus.so — it still downloads v1.3.13, which now fails to start because it tries to load libmysticeti_consensus.so that doesn't exist.

So currently:

• v1.3.13 (shipped by CLI): won't start (libmysticeti_consensus.so: cannot open shared object file)
• v1.4.0 (manual install from GitHub): starts, but same stale genesis → rejects all blocks

Paid miner subscriber here as well. Node runs fine as a P2P agent (6 peers, inference serving, training participation) but chain layer is completely non-functional — Registered: no, Sync: unknown, 0 points.

Validator address: 0x6EC0b054E0043325832e4Ba3Df18E7D4a4CD58B4

[skimaharvey]

@ginkoe any update on that?