Upgrade Separates Consensus and Execution to Address Scaling Limits

High-performance blockchain designs have long wrestled with a structural trade-off: when execution is tied directly to consensus, the network’s throughput becomes limited by how fast validators can process transactions. As research and engineering teams push improvements in finality and block propagation, execution itself is increasingly viewed as the next bottleneck to redesign.

MultiversX, a Cointelegraph Decentralization Guardians (CTDG) ecosystem participant, is now testing an approach that aims to remove that bottleneck. Its Supernova upgrade decouples consensus from transaction execution, enabling validators to vote without waiting for execution to complete—shifting computation into an asynchronous pipeline. Supernova is live on testnet, and deployment planning targets a mainnet activation date later this year.

Key takeaways

• Supernova reorders the block workflow so proposers submit transaction blocks without executing first, while validators can vote immediately based on protocol validity.


• Execution output is confirmed in subsequent block headers, with execution lagging consensus by roughly one block (about 600 milliseconds).


• A “virtual mempool state” helps preserve validity by tracking pending nonces, expected balance consumption, and transactions already proposed but not yet executed.


• EIE (Execution-Result Inclusion Estimator) limits how many execution results a block can reference, based on what minimum-spec nodes can safely handle.


• Automatic backpressure reduces block capacity when execution falls too far behind, giving the system time to catch up.

Why execution-on-consensus became a scaling problem

In conventional synchronous blockchains, validators don’t just agree that a block is well-formed—they also must execute the transactions to verify state transitions before voting. That keeps the system deterministic and consensus-critical, but it also creates a shared bottleneck: the most computationally heavy transactions effectively slow the entire network.

Many networks have spent years optimizing around agreement speed and block dissemination. MultiversX’s framing is that these gains are not enough if execution remains on the critical path. The core question Supernova addresses is architectural: does execution have to stay inside the consensus loop, or can it be processed asynchronously while preserving safety and correctness?

Supernova’s asynchronous pipeline: voting first, executing after

Supernova, now live on testnet, introduces a changed block production sequence.

Previously, block production followed a more sequential pattern: a proposer selected transactions, executed them locally, and proposed a block containing those results. Validators then had to re-execute the same transactions to verify state transitions before voting, meaning execution sat directly inside the consensus-critical path.

With Supernova, that ordering changes. According to MultiversX’s description of Supernova’s decoupling, the proposer selects transactions and proposes the block without executing them first. Validators then verify that the proposal follows protocol rules and can vote right away. Execution continues asynchronously in the background, producing an output that is normally referenced and notarized in the next block header—so execution trails consensus by about one block, or roughly 600 milliseconds.

The practical consequence is that network responsiveness becomes less dependent on how quickly validators can execute every transaction before they can participate in consensus. Instead, consensus advances on protocol validity, while execution catches up in parallel.

Preserving validity when execution lags consensus

Decoupling execution from consensus creates an obvious safety and validity challenge: if execution is delayed, how does the network determine whether transactions included in a proposed block are likely to remain valid by the time their execution results are produced?

Supernova addresses this with a virtual mempool state. As described by MultiversX, the virtual mempool looks beyond the latest executed chain state and tracks forward-looking execution inputs such as pending nonces, expected balance consumption, and transactions already proposed but whose execution results have not yet passed consensus. That gives proposers a more accurate view of account activity so they can select transactions expected to execute successfully when their turn arrives.

To keep the system robust under varying validator performance, MultiversX also introduces two safeguards designed for operational stability:

• Execution-Result Inclusion Estimator (EIE): EIE limits how many execution results can be referenced in a block. The cap is tied to what minimum-spec nodes can process safely, reducing the risk that weaker nodes are overwhelmed by referencing too many pending results.


• Automatic backpressure: If execution falls too far behind, block capacity is reduced to allow the network to catch up—rather than letting lag accumulate indefinitely.

What Supernova changes for developers and users

For builders, the key message is that “in-shard finality” can arrive as soon as the proof is available. MultiversX states this typically happens within the same round at around 100–250 milliseconds, alongside more predictable execution conditions. This matters most for applications that rely on fast feedback loops—examples mentioned include high-frequency DeFi primitives and onchain order book systems, which can degrade when latency becomes a user-experience problem.

Supernova has also been producing 600-millisecond blocks on live testnet and devnet since Aug. 20. The network’s broader objective is to make onchain interactions feel more immediate, shifting the experience closer to responsive application infrastructure rather than delayed settlement.

On timeline, MultiversX indicates mainnet activation is expected for Sept. 10, 2026. While testnet performance does not always translate directly to mainnet behavior under full load, the architecture itself is designed to handle execution lag without forcing every validator to execute first during consensus.

Supernova within the CTDG and Cointelegraph ecosystem

The upgrade also lands within a broader infrastructure collaboration involving Cointelegraph Decentralization Guardians. Earlier coverage noted that Cointelegraph joined MultiversX as a validator through the CTDG program in March 2026, deepening the organization’s operational role beyond content and community work.

Cointelegraph’s CTDG Dev Hub is also described as a MultiversX official partner, connecting the protocol to a wider developer community. The input also references practical involvement such as the MultiversX Foundation delegating to a CTDG validator and the Dev Hub team building a dedicated validator dashboard on MultiversX.

From an industry perspective, this matters because protocol upgrades of this kind often require ecosystem alignment: performance improvements are only meaningful if infrastructure, tooling, and participating validators can adopt new execution and consensus mechanics reliably. Supernova’s focus on backpressure and minimum-spec safeguards suggests the design is attempting to make that transition smoother.

As Supernova moves from testnet toward the projected mainnet date, the most important things for users to watch are whether execution lag remains within expected bounds under real load, and how consistently EIE and backpressure prevent validators from falling behind without overly constraining throughput. The success criteria won’t only be faster finality—it will be whether execution remains dependable when consensus and execution operate on different clocks.

https://www.cryptobreaking.com/upgrade-separates-consensus-and-execution/?utm_source=blogger%20&utm_medium=social_auto&utm_campaign=Upgrade%20Separates%20Consensus%20and%20Execution%20to%20Address%20Scaling%20Limits%20