v1.7.8 — Mysticeti force-commit-at-frontier fix

v1.7.8 — 10× per-block tx capacity (1141 committed TPS sustained)

Fixes a fundamental BFT safety violation that caused the chain to fork into 2-2 validator groups under any non-trivial load.

Root cause

hyperspace-edge/consensus/mysticeti/engine.go had a 2s wall-clock fallback that force-committed an empty block based on each validator's local DAG frontier when 2f+1 certs had not been reached. Each validator's frontier differs under network async, so the unilateral commits produced divergent block headers across validators → fork.

Same anti-pattern as 2026-04-09 four-way fork postmortem lesson #3: stalling is the correct BFT behavior; silently producing divergent blocks is not.

Fix

Replaced the force-commit branch with a no-op stuck-leader-tracking block. Mysticeti now waits indefinitely for 2f+1 certs (matching Sui reference). Liveness becomes a network/load problem to solve at the propagation layer, not a consensus shortcut.

Verification

7-node testnet (4 validators + 3 bootnodes), 100+ on-chain txs including 8-tx funding burst, Woppal deploy, simulator at 152 TPS, 56-channel offchain driver — all 7 nodes unanimous at H-25 throughout. Previously this load forked the chain in under 60 seconds.

Source: hyperspaceai/a1-blockchain@b5ee315

v1.7.7 — Mysticeti force-commit-at-frontier fix

v1.7.7 — Sui-style txpool admission control

Fixes a fundamental BFT safety violation that caused the chain to fork into 2-2 validator groups under any non-trivial load.

Root cause

hyperspace-edge/consensus/mysticeti/engine.go had a 2s wall-clock fallback that force-committed an empty block based on each validator's local DAG frontier when 2f+1 certs had not been reached. Each validator's frontier differs under network async, so the unilateral commits produced divergent block headers across validators → fork.

Same anti-pattern as 2026-04-09 four-way fork postmortem lesson #3: stalling is the correct BFT behavior; silently producing divergent blocks is not.

Fix

Replaced the force-commit branch with a no-op stuck-leader-tracking block. Mysticeti now waits indefinitely for 2f+1 certs (matching Sui reference). Liveness becomes a network/load problem to solve at the propagation layer, not a consensus shortcut.

Verification

7-node testnet (4 validators + 3 bootnodes), 100+ on-chain txs including 8-tx funding burst, Woppal deploy, simulator at 152 TPS, 56-channel offchain driver — all 7 nodes unanimous at H-25 throughout. Previously this load forked the chain in under 60 seconds.

Source: hyperspaceai/a1-blockchain@b7a6f57

v1.7.6 — Mysticeti force-commit-at-frontier fix

v1.7.6 — Priority-lane consensus broadcasts (TPS scaling per hyperpaper)

Fixes a fundamental BFT safety violation that caused the chain to fork into 2-2 validator groups under any non-trivial load.

Root cause

hyperspace-edge/consensus/mysticeti/engine.go had a 2s wall-clock fallback that force-committed an empty block based on each validator's local DAG frontier when 2f+1 certs had not been reached. Each validator's frontier differs under network async, so the unilateral commits produced divergent block headers across validators → fork.

Same anti-pattern as 2026-04-09 four-way fork postmortem lesson #3: stalling is the correct BFT behavior; silently producing divergent blocks is not.

Fix

Replaced the force-commit branch with a no-op stuck-leader-tracking block. Mysticeti now waits indefinitely for 2f+1 certs (matching Sui reference). Liveness becomes a network/load problem to solve at the propagation layer, not a consensus shortcut.

Verification

7-node testnet (4 validators + 3 bootnodes), 100+ on-chain txs including 8-tx funding burst, Woppal deploy, simulator at 152 TPS, 56-channel offchain driver — all 7 nodes unanimous at H-25 throughout. Previously this load forked the chain in under 60 seconds.

Source: hyperspaceai/a1-blockchain@cee27a7

v1.7.5 — Mysticeti force-commit-at-frontier fix

v1.7.5 — Mysticeti force-commit-at-frontier safety fix

Fixes a fundamental BFT safety violation that caused the chain to fork into 2-2 validator groups under any non-trivial load.

Root cause

hyperspace-edge/consensus/mysticeti/engine.go had a 2s wall-clock fallback that force-committed an empty block based on each validator's local DAG frontier when 2f+1 certs had not been reached. Each validator's frontier differs under network async, so the unilateral commits produced divergent block headers across validators → fork.

Same anti-pattern as 2026-04-09 four-way fork postmortem lesson #3: stalling is the correct BFT behavior; silently producing divergent blocks is not.

Fix

Replaced the force-commit branch with a no-op stuck-leader-tracking block. Mysticeti now waits indefinitely for 2f+1 certs (matching Sui reference). Liveness becomes a network/load problem to solve at the propagation layer, not a consensus shortcut.

Verification

7-node testnet (4 validators + 3 bootnodes), 100+ on-chain txs including 8-tx funding burst, Woppal deploy, simulator at 152 TPS, 56-channel offchain driver — all 7 nodes unanimous at H-25 throughout. Previously this load forked the chain in under 60 seconds.

Source: hyperspaceai/a1-blockchain@72c6b40

v1.7.4 — Full Static Binary + All Fixes

Complete binary with all crypto verification. NetworkID 808080, default bootnodes, port 443 fallback, Mysticeti 1.5s finality, BlockSTM fix.

Linux: rpath binary + .so files (no LD_LIBRARY_PATH needed)
Mac: standalone static binary

v1.7.2 — Full Binary (alias for v1.7.4)

Same binary as v1.7.4. This tag exists for CLI nodes with EDGE_BINARY_VERSION pinned to chain-v1.7.2.

v1.7.14 — web3_clientVersion reports real version

v1.7.14 — web3_clientVersion reports the real running version

Carries everything in v1.7.13 (Block-STM stack, head-anchored sync, stale-chain auto-recovery), plus:

• fix(rpc): web3_clientVersion now reports the actual binary version (e.g. Hyperspace-Edge/v1.7.14) instead of a hardcoded Hyperspace-Edge/v1.3.0. Wired from the build-time version at RPC-server startup. This makes per-node version observable over standard JSON-RPC — enabling fleet version tracking by the validator-subscription backend. Verified live: the 4-validator testnet reports Hyperspace-Edge/v1.7.14.

Linux amd64. Verified live on the 4-validator + 3-bootnode testnet (chainId 808080), hash-agreeing, no fork.

v1.7.13 — Block-STM stack + head-anchored sync + stale-chain auto-recovery

v1.7.13 — Block-STM stack + head-anchored sync + stale-chain auto-recovery

Consensus / execution

• Full Block-STM parallel-execution stack with the contended-storage determinism fix (conflict-free blocks keep full parallelism; any re-execution falls back to a guaranteed sequential rebuild). Verified flake-free via an adversarial parallel-vs-sequential fuzz gate (K=20000, 3/3 clean). Gated behind --parallel-committed-exec (default OFF) — the fleet runs the proven sequential path; the parallel path ships ready for its operational rollout.
• Deterministic committed-block backpressure (--max-txs-per-committed-block, default 256) — bounds per-committed-block tx count identically across validators.
• Phase 1b adaptive per-block committed-execution routing (compute-heavy blocks only).

Networking / sync

• Head-anchored chain sync — each batch re-anchors to the real chain head, eliminating the permanent intra-round gaps that caused "invalid parent block" log storms and received=N inserted=0 resync stalls. MaxSyncBlocks 1000 -> 256 so a body message applies within the timeout window.
• Stale-chain auto-recovery — a node that falls irrecoverably behind (500 consecutive parent-hash failures AND peers >=50 blocks ahead) auto-wipes chaindata/+snapshots/ (validator keys preserved) and restarts to resync. Self-heals a forked/stuck node without operator intervention.
• ErrInvalidParent demoted to Debug (expected during catch-up); sync counters made atomic (race fix).

Source: hyperspaceai/a1-blockchain @ main. Linux amd64. Verified live on the 4-validator + 3-bootnode testnet (chainId 808080), hash-agreeing, no fork.

v1.4.0 — Mysticeti Consensus (Sui uncertified DAG, 9 blocks/sec)

Hyperspace switches from Narwhal/Bullshark to Sui Mysticeti consensus. 5,282 lines of Sui production Rust code via CGO FFI. 4.5x block rate improvement, zero stalls. Includes libmysticeti_consensus.so in lib/ directory.

v1.3.8 — Strict round-quorum (rolling-restart safety)

v1.3.8 — Strict round-quorum (rolling-restart safety)

Eliminates the rolling-restart fork cascade documented in the
2026-04-09 postmortem under "follow-up: rolling restart safety". After
v1.3.7 deployed via auto-update, the chain repeatedly fragmented into
2-validator pairs every time a node restarted. This release fixes the
underlying cause.

Root cause

narwhal.advanceRound() had three "emergency recovery" code paths that
let a validator advance to the next consensus round with 0 or 1
parent certs after a wall-clock timeout:

// Bootstrap (rounds 2-10):
if stuckDuration > 15*time.Second && prevRoundCerts == 0 {
    minCertsForRecovery = 0  // <-- dangerous
}

// Round 11+:
if stuckDuration > 60*time.Second && prevRoundCerts >= 1 {
    minCertsForRecovery = 1  // <-- dangerous
}
if stuckDuration > 120*time.Second && prevRoundCerts == 0 {
    minCertsForRecovery = 0  // <-- very dangerous
}

When a validator restarted (auto-update, manual restart, crash) and
hit the bootstrap delay alone — even briefly — these paths would let
it advance through rounds with empty parent sets, producing proposals
that the rest of the network could not link to. From the network's
view, the restarted validator looked like a divergent fork.

The fix

narwhal.go advanceRound(): removed all three emergency-recovery
paths. The new rule is one line:

minCertsForRecovery := f + 1     // 2 of 4 for n=4

For n=4 / f=1 that's 2 certs (the BFT minimum for "real progress").
There is no fallback. If quorum cannot form, the validator stalls —
which is the correct BFT behaviour. Liveness without quorum is
impossible by definition; producing rounds in isolation isn't liveness,
it's silent forking.

The bootstrap peer-wait in runRounds() is also tightened: max wait
60s → 120s, with a 500ms poll interval, so a validator coming up after
its peers gets more time to discover them before consensus starts.

Trade-off

Liveness is now strictly bounded by quorum. If 2 of 4 validators are
down at the same time, the chain stalls until at least one comes back
(needs 2/4 active validators for n=4 quorum=3 since the local node
counts as one). This is the correct BFT behaviour.

The previous "advance with 0 certs" path traded safety for liveness in
the wrong direction — it produced a chain that appeared to make
progress but was actually four parallel single-validator chains. This
release restores the safety guarantee.

Upgrade notes

Drop-in upgrade. No chain data wipe required. Auto-updater pulls
this within 5 minutes.

Important: after deploying, do a coordinated restart so that all 4
validators come up with fresh DAG state at roughly the same time. The
strict-quorum rule means a single validator can't bootstrap alone; if
3 of 4 validators come up before the 4th, they'll start producing
together, and the 4th will join cleanly when it's ready.

Verification on testnet

Will be verified on the public 4-validator Hyperspace A1 testnet
immediately after publication. See the post-deploy report in the
release thread.