Decoupling consensus from execution sounds like acting first and asking questions later — if execution hasn't actually happened yet when validators vote, what happens if the outcome doesn't match expectations?
The key here is that a validator's vote confirms the content and submission order of a transaction, not the final state after execution — these are two things traditional designs bundle together, but they're actually separable problems that can be verified independently. Supernova's approach has validators first reach consensus on which transactions a Block should contain and in what order — once that consensus is reached, it's irreversible. What state changes those transactions actually produce upon execution happens after that consensus is reached, and the execution result gets referenced and notarized in the following block. That essentially defers verification of the execution process by one step, without ever letting the execution result itself escape verification.
This design is fundamentally similar to "decide what to do and in what order first, then actually do it," compared to an approach that finishes everything before announcing anything — it lets validators reach consensus on transaction order without needing to wait for execution to finish, which is exactly where the speed advantage of decoupling comes from. But the execution result still gets published and notarized in a subsequent block; verification isn't skipped, it's just shifted from "must complete before the vote" to "completes immediately after the vote."
If cross-shard settlement time dropped from 18 seconds to 2.4 seconds, what does that improvement actually mean for an everyday user, or is it just a technical number for developers?
Cross-shard settlement time directly affects how long it takes for a transaction to be confirmed when a sender and receiver happen to sit on different shards — MultiversX's sharded architecture splits the network into multiple shards to boost processing capacity, but that also means a meaningful proportion of transactions between users cross shard boundaries. These transactions previously took roughly 18 seconds to confirm; compressed to 2.4 seconds, that wait time for everyday transfers and cross-wallet interactions has gone from noticeably laggy to something closer to imperceptible.
For everyday users, this improvement will be most directly felt in application scenarios requiring frequent interaction — real-time actions in an on-chain game, or a payment flow that needs quick confirmation before proceeding to the next step. These kinds of applications may previously have avoided sharded architecture entirely, or specifically designed around cross-shard interactions, because settlement took too long. With this improvement, that constraint should theoretically loosen substantially — it's not purely a technical metric meant only for developers.
MultiversX needed a 24-minute halt to complete this upgrade, while Solana's Alpenglow emphasizes a staged rollout with the network never stopping — what's different about the trade-off logic behind each?
This difference reflects two different risk-management philosophies. MultiversX chose to briefly pause the entire network, essentially trading a known, controlled brief downtime for the certainty that no Node would get stuck between old and new rules at the moment of the switch — during that 24-minute halt, every node sits in the exact same known state, with no transition-period risk of some nodes running old rules while others have already moved to new ones.
Solana's Alpenglow takes the opposite approach, using a staged, weight-based rollout (10% of staked weight upgrades first, expanding to 25%, only then triggering the full network switch), attempting to complete the transition while the network keeps running without interrupting service. The cost is a longer overall transition process and more complex coordination, requiring additional mechanisms — like a feature gate — to ensure an overwhelming majority of validator weight is ready before triggering the switch. Neither approach is unambiguously superior. MultiversX's sharded architecture and consensus design may make the coordination cost of a brief full-network pause relatively low, while Solana's network scale and the ongoing commercial importance of never interrupting service may make "zero downtime" worth the extra coordination complexity it takes to achieve.
If I hold or use EGLD around the September 10 upgrade, what checks should I actually do to make sure my assets aren't affected?
First, if your assets sit entirely in your own wallet (self-custody), per the project's announcement, addresses, private keys, and balances all remain backward compatible before and after the upgrade — no Token swap or claim action is needed, and any message urging you to take action during the upgrade window should be treated as a fraud warning sign. Second, if your assets sit on an exchange, check ahead of time whether the exchange you use has announced a specific withdrawal pause window, and complete any necessary withdrawal or transfer before that pause begins, to avoid being stuck unable to access assets during the halt.
Third, if your assets are staked, understand that the unbonding period doesn't shorten because of this upgrade — even though the chain itself now produces blocks ten times faster, the originally configured unbonding days remain unchanged, which means when planning ahead for how you'll use your funds, you shouldn't assume "the chain got faster, so Staking unbonding will too." Fourth, if you're running a Node yourself, make sure your software version has been upgraded to one supporting the new rules, and pay attention to the officially announced specific switchover timing (the actual clock time derived from the round count, not just a bare date) to avoid temporarily falling off the network after the switch due to a lagging software version.
MultiversX formally activated its Supernova hard fork on September 10, 2026, at epoch 2233, round 32,157,661, cutting Block generation time from 6 seconds to 600 milliseconds — a tenfold speedup. This upgrade goes well beyond simply speeding up the block cadence: it fully decouples consensus from transaction execution. Previously, a validator had to actually finish executing a transaction before it could vote on that block; after Supernova, block proposers can submit transaction content first, letting validators vote immediately, while actual execution happens asynchronously — the resulting execution state gets referenced and notarized in the following block. This architectural change pushes intra-shard Finality below roughly 250 milliseconds and cuts cross-shard settlement time from about 18 seconds to roughly 2.4 seconds, all while preserving MultiversX's original sharded architecture rather than sacrificing decentralized Sharding for the sake of speed.
Because this upgrade alters core logic at the consensus layer itself, MultiversX chose to halt the entire network from accepting new transactions for roughly 24 minutes during the switchover, ensuring more than 5,000 nodes could fully migrate onto software supporting the new rules before resuming operation, rather than risking a Node split mid-migration. During the lead-up, the team continuously tracked node software version distribution — after the final release v2.0.6.0 shipped on September 7, 84.2% of mainnet nodes had upgraded within 24 hours, indicating strong validator cooperation with this hard fork. For everyday users, the practical thing to watch is whether withdrawals function normally during that pause window if assets sit on an exchange or are staked — most exchanges announced withdrawal pauses ahead of the upgrade, though as of early September some exchanges still hadn't published specific pause timing.
Worth noting: even with block production ten times faster, MultiversX's staking unbonding period didn't shorten as a result — the officially configured unbonding period remains measured in days and doesn't automatically scale down proportionally just because block time got shorter. That means if a user assumed "the chain got faster, so getting staked assets back will be faster too," that assumption doesn't hold — the configuration parameter is set independently of block time.
If you self-custody EGLD, there's nothing you need to do — the project states addresses, private keys, and balances remain backward compatible with no Token swap or claim required. If you hold EGLD on an exchange or have it staked, check ahead of any future similar upgrade whether your specific exchange has announced a withdrawal pause window, and factor in that unbonding still takes the same number of days it did before, regardless of how much faster block production has become. Beyond MultiversX specifically, this upgrade is also a useful reference point for evaluating any chain that claims a speed boost: check whether the claimed improvement addresses consensus finality, execution throughput, or cross-shard settlement — the three are genuinely different bottlenecks, and a chain solving one doesn't necessarily mean the others improved by the same Margin.