Supernova Walkthrough Recap
What changes under the hood of the largest protocol upgrade in MultiversX history
The Supernova walkthrough focused on substance: what is changing in the MultiversX protocol, how it works, and what it means for builders, validators, and operators.
At its core, Supernova introduces a structural change to block production by separating consensus from execution. This recap summarizes that change and the reasoning behind it.
From Andromeda to Supernova
Supernova builds directly on the Andromeda upgrade.
Andromeda redesigned consensus and finality, removed confirmation blocks, and made finality both faster and deterministic. As explained during the walkthrough:
“As soon as you have a proof that a block has passed consensus, that block is already final. It cannot be reverted.”
After Andromeda, one major limiter remained: execution.
Transactions still had to be executed before blocks could pass consensus. In practice, execution dominated block time:
“Execution time, depending on how many transactions there were in a block, could take up to 4.5 seconds out of the block slot.”
Consensus was already fast. Execution was not.
The Architectural Change
Supernova removes execution from the consensus critical path.
Previously, block production required a proposer to execute transactions before proposing a block, and validators to re-execute them before voting. Supernova changes that flow.
“We completely decoupled execution from consensus, and now consensus runs on a proposed set of transactions.”
Blocks are proposed and voted on first. Execution happens asynchronously in parallel, and execution results are notarized in later block headers.
As it was summarized in the session:
“Everyone agrees on the set of transactions. And in parallel with agreeing on them, everyone also does the execution.”
What Block Production Looks Like Now
Before Supernova:
transactions were selected, executed, and proposed as a single synchronous step
validators re-executed transactions before voting
With Supernova:
transactions are proposed without prior execution
validators verify proposal rules and vote immediately
execution runs in the background
results are referenced and finalized in subsequent headers
Consensus no longer waits for execution to finish.
Why Execution Had to Move
Measurements shared during the walkthrough showed that consensus already completes very quickly on mainnet:
“More than 99.98% of blocks reach consensus in under 250 milliseconds.”
Execution was the remaining blocker to shorter rounds.
By removing execution from the critical path, Supernova enables much shorter block slots. The initial target is 600ms, with internal testing showing consensus completing well within that window.
Making Asynchronous Execution Safe
Decoupling execution introduces a clear challenge: avoiding the proposal of transactions that won’t execute later.
Supernova addresses this by redesigning the transaction pool.
The mempool now maintains a virtual state that tracks pending nonces, expected balance usage, and transactions already proposed but not yet executed.
“The transaction pool maintains state for accounts that had transactions proposed but not yet executed, so we don’t select transactions that cannot be executed.”
This virtual state is updated as blocks are proposed and as execution results are finalized, keeping transaction selection aligned with actual network state.
Keeping Validator Requirements Stable
Faster rounds should not exclude validators with minimum-spec hardware.
To prevent that, Supernova introduces the Execution-Result Inclusion Estimator (EIE).
“We need to make sure that whoever respects the minimum hardware requirements is able to participate in consensus, produce blocks, and earn rewards.”
EIE deterministically limits how many execution results can be referenced in a block based on what a minimum-spec node can safely process. If execution starts lagging, block capacity is reduced automatically.
Validator economics remain unchanged:
“From the point of view of economics, nothing has changed. The same rewards are generated and distributed as before.”
Automatic Backpressure
Supernova also includes built-in backpressure.
If execution falls behind proposals, the protocol dynamically reduces block capacity until execution catches up. This prevents unbounded execution backlog and requires no manual intervention.
Transition and Testing
Before activating the new execution model, the protocol performs a cleanup phase:
“We finalize all pending partial execution and scheduled execution before switching to the 600ms round time.”
Supernova is then validated through Battle of Nodes, which runs on a shadow fork of mainnet state:
“We want to stress-test Supernova using real participants and real workloads. Synthetic benchmarks are not enough for an upgrade of this size.”
The goal is to surface edge cases under realistic conditions before full activation.
What This Enables
For builders, Supernova changes the constraints they design within.
Shorter rounds and predictable finality make it easier to build applications that react quickly to on-chain state: real-time games, trading systems, responsive DeFi components, and complex cross-shard flows.
For users, interactions resolve almost immediately.
For autonomous agents, fast and deterministic finality is essential. Agents that react to events, coordinate across contracts, or operate continuously depend on clear guarantees around when state becomes irreversible.
Supernova provides those guarantees while keeping validator participation broad.
A Shift in the Baseline
Supernova does not add a feature on top of the existing protocol. It changes how the protocol itself moves forward.
Once consensus and execution are no longer tied together, the baseline assumptions around speed, responsiveness, and system design shift accordingly.
That shift is what Supernova brings to the MultiversX ecosystem.