MultiversX to pause transactions 24 minutes for Supernova

MultiversX will pause new transactions for about 24 minutes on Sept. 10 to activate the Supernova upgrade, which reduces block time from six seconds to 600 milliseconds and requires validators to run updated node software.

The upgrade is scheduled to activate during epoch 2233 at round 32,157,661. A migration window runs from Sept. 1 to Sept. 10 to allow operators to install the new binaries and coordinate the transition.

Supernova restructures the protocol’s consensus pipeline so validator voting can occur while transaction execution proceeds in parallel. The change removes execution from the consensus critical path. The design aims for intra-shard finality below 250 milliseconds and cross-shard settlement near 2.4 seconds while keeping epoch length and backward compatibility for addresses, keys and balances.

MultiversX expects mainnet to stop accepting new pooled transactions for roughly 240 rounds on the existing six-second clock-about 24 minutes-while clearing transactions already in flight. Transactions submitted during that slowdown are expected to remain queued until Supernova begins processing them.

A check of public network data on Sept. 1 showed 5,171 nodes on the network, with 95.35% still running version 1.11.11.0 at the start of the migration window. The protocol’s release candidate identified the planned activation point and the nine-day migration window; operators can run old and new binaries concurrently before activation.

Validator guidance warns that nodes running outdated software after activation could compute different transaction results and fall out of sync with the majority chain, which can produce invalid blocks or forks. Coordination across validators is required to avoid such outcomes once the new rules take effect.

Market activity ahead of the upgrade showed the EGLD token trading above $4 over the weekend, reaching about $4.05 before pulling back below that level.

The network’s version mix before Sept. 10 will determine whether the upgrade can be applied without nodes falling out of sync and whether the protocol achieves the stated latency improvements at mainnet scale.