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.