Supernova: Decoupling Consensus and Execution

Supernova: Decoupling Consensus and Execution

Supernova is a fundamental protocol upgrade that rethinks how consensus and execution interact in MultiversX.

Rather than optimizing around existing constraints, it removes one of them entirely.

From Andromeda to Supernova

With Andromeda, MultiversX eliminated several long-standing bottlenecks in consensus and finality. Blocks could finalize faster, cross-shard execution was streamlined, and overall responsiveness improved.

Yet one major constraint remained: execution.

Transaction execution was still synchronous and tightly coupled to consensus. As long as blocks had to be executed before they could be finalized, execution time would continue to cap how fast the network could move.

Supernova is designed to remove that remaining constraint.

The Core Architectural Shift

At the heart of Supernova is a structural change: consensus and execution are no longer interleaved.

Previously, the network had to both agree on a block and execute its transactions as part of the same synchronous process. With Supernova, agreement comes first. Execution follows asynchronously, running in parallel with consensus on subsequent blocks.

This decoupling reshapes the entire execution pipeline.

Block Production Before Supernova

Before Supernova, block production followed a strictly sequential model.

A proposer selected transactions from the mempool, executed them locally, and proposed a block containing execution results. Validators then re-executed those transactions before voting.

Execution time was therefore part of the consensus critical path. Heavier transactions meant slower rounds, regardless of how quickly the network could otherwise reach agreement.

Block Production With Supernova

Supernova introduces a different flow.

A proposer selects transactions and proposes a block without executing them. Validators verify that the proposal follows protocol rules and vote immediately. Execution then runs asynchronously in the background. The results of that execution are referenced and notarized in later block headers.

Consensus no longer waits for execution to finish.

Why This Matters

Execution is the most resource-intensive part of block production. Removing it from the consensus critical path allows the protocol to progress at the pace of agreement rather than computation.

This enables shorter block slots, more predictable finality, and more stable behavior under load. These gains come from architectural change, not from tuning parameters or relaxing guarantees.

Transaction Validity Without Synchronous Execution

Decoupling execution raises an obvious challenge: ensuring that proposed transactions will still execute successfully.

Supernova addresses this by upgrading the transaction pool itself.

The mempool maintains a virtual state that tracks pending nonces, expected balance consumption, and transactions that have already been proposed but not yet executed. Using this information, proposers can deterministically select transactions that are expected to execute once their turn arrives.

This virtual state is continuously updated as blocks are proposed and as execution results are finalized, keeping transaction selection aligned with the actual state of the network even when execution lags consensus.

Faster Blocks Without Higher Hardware Requirements

Increasing block speed often comes with an implicit assumption: more powerful hardware.

Supernova avoids that assumption by making execution capacity explicit and enforced by the protocol.

It introduces the Execution-Result Inclusion Estimator (EIE), a deterministic mechanism that caps how many execution results can be referenced in a block based on what minimum-spec nodes can safely process within the available time.

This prevents execution from silently outrunning slower validators and avoids pushing hardware requirements upward.

Built-In Backpressure

Supernova also includes automatic backpressure.

If execution falls too far behind new proposals, block capacity is reduced automatically. Execution is given time to catch up, after which normal throughput resumes. No manual intervention is required, and shards cannot accumulate unbounded execution backlog.

Cleaning Up Legacy Execution Paths

As part of the transition, Supernova removes legacy execution mechanisms such as scheduled execution and partial mini-blocks.

Before faster rounds begin, the protocol goes through an explicit cleanup phase to ensure no artifacts from the previous execution model remain. This makes the transition predictable and auditable.

A Phased Activation Model

Supernova is designed to activate progressively.

Public testing, Battle of Nodes, security audits, and readiness checks are used to validate behavior under real conditions before full activation. Each phase exists to surface issues early and reduce risk.

Nothing skips validation.

Why This Design Is Noteworthy

Decoupling consensus from execution is a hard problem.

Doing so while preserving deterministic behavior, protecting slower nodes, and maintaining a sharded architecture is harder still. Supernova achieves all three simultaneously.

That combination is what makes Supernova more than a performance upgrade. It represents a meaningful shift in how blockchain protocols can be structured.

What Supernova Unlocks

By decoupling consensus from execution, Supernova changes what the network can support in practice.

For builders, sub-second finality and predictable execution open the door to applications that depend on tight feedback loops: real-time games, high-frequency DeFi primitives, on-chain order books, reactive smart contracts, and complex cross-shard flows that no longer need to hide latency behind UX workarounds.

For users, interactions stop feeling transactional and start feeling immediate. Finality becomes something you experience rather than wait for. Actions resolve as they are taken, not seconds later, and the boundary between on-chain and off-chain interaction becomes much thinner.

For autonomous agents, fast, deterministic finality is not an optimization — it is a prerequisite. Agents that react to state changes, coordinate across contracts, or operate continuously require guarantees about when state becomes irreversible. Supernova provides those guarantees without sacrificing decentralization.

Taken together, these unlocks are not about headline throughput numbers. They are about shifting the class of applications that can realistically be built and operated on the network.

Supernova does not just make MultiversX faster.

It changes what it is practical to build on it.

‍