MultiversX ships Supernova on testnet, targeting ~600 ms blocks ahead of Sept. 10 mainnet
The upgrade decouples consensus from execution and claims 100–250 ms in-shard finality for latency-sensitive DeFi.
MultiversX has rolled out its “Supernova” upgrade on testnet, redesigning block production so validators can agree on blocks before transactions execute. The team is targeting ~600-millisecond blocks and 100–250 milliseconds of in-shard finality, with mainnet activation expected on Sept. 10, 2026.
Supernova Hits Testnet With an Expected Sept. 10 Mainnet Switch
Supernova is now live on MultiversX’s testnet, with the same architecture also running on devnet, as the network moves toward an asynchronous execution pipeline that is explicitly designed to keep consensus moving even when transaction execution is still catching up.
The stated timeline is tight and specific. Supernova has been producing ~600-millisecond blocks on the live testnet and devnet since Aug. 20, and the network is working toward an expected mainnet activation date of Sept. 10, 2026.
The upgrade is framed as a response to a familiar scaling ceiling for high-performance chains: when transaction execution sits on the consensus-critical path, the slowest computation becomes the system’s pace car. MultiversX’s bet is that the next step-change in latency comes from changing the order of operations, not just optimizing propagation and finality.
Decoupled Consensus and Execution: The Latency Targets and the New Validity Problem
Supernova’s core change is mechanical: it “decoupl[es] consensus from execution so the network can agree on blocks before processing their transactions,” shifting execution out of the consensus-critical path and into an asynchronous stage that runs after validators have already voted.
Before the upgrade, the flow was sequential. A proposer selected transactions, executed them locally, and proposed a block with the resulting state transitions, then validators re-executed those transactions before voting. Under Supernova, “The proposer selects transactions and proposes the block without executing them first,” and “Validators verify that the proposal follows protocol rules and can vote immediately, while execution continues asynchronously in the background.”
That reordering is what makes the latency targets plausible in theory. Execution output is “normally referenced and notarized in the next block header,” which means execution trails consensus by roughly one block, or about 600 milliseconds. In practice, the architecture is aiming for a pipelined cadence where consensus can keep producing ~600 ms blocks even if execution is one block behind, rather than forcing every validator to finish the same computation before the next block can be finalized.
For builders, the headline claim is that “in-shard finality lands as soon as the proof is available, usually within the same round at around 100–250 milliseconds,” paired with “more predictable execution conditions.” The target use cases are the ones that degrade quickly when latency becomes user-visible, including high-frequency DeFi primitives and onchain order books.
The catch is the validity problem that async execution introduces. If the network votes on a block before execution, a transaction that looked valid at proposal time can become invalid by the time execution reaches it, because account nonces and balances may have been consumed by other pending activity.
Virtual Mempool State, EIE, and Backpressure: How Supernova Tries to Keep Blocks Safe and Nodes in Sync
Supernova’s first line of defense is at the proposer layer, via a “virtual mempool state” that looks beyond the latest executed state and tracks pending nonces, expected balance consumption, and transactions already proposed but not yet executed or finalized through consensus. The goal is to give proposers a forward-looking view of account activity so they can avoid including transactions that are likely to fail once execution catches up.
The design also adds two explicit throttles meant to keep the network’s long tail of hardware from falling behind. The Execution-Result Inclusion Estimator (EIE) caps how many execution results can be referenced in a block based on what “minimum-spec nodes can safely process,” and automatic backpressure reduces block capacity if execution falls too far behind, giving the system time to catch up.
Those mechanisms are also where the market-relevant uncertainty sits today. The material describes the pipeline and its safeguards, but it does not provide independent benchmarks, throughput figures, or stress-test data that would show whether ~600 ms blocks persist under heavier, more complex transaction mixes. It also does not spell out, beyond the virtual mempool state and throttles, how post-consensus execution failures and invalid transactions are handled operationally in edge cases.
The next concrete milestones are procedural rather than narrative: confirmation or revision of the expected Sept. 10, 2026 mainnet activation date, sustained ~600 ms block production on testnet/devnet as load and transaction complexity rise, and any disclosed metrics showing how often EIE caps or backpressure reductions trigger under stress.
My Read: This Is a UX/Builder Bet—But Traders Should Treat the Numbers as Provisional Until Mainnet
The part most people will misread is the latency claim as a finished performance guarantee. What’s actually shipped is an architectural shift that removes execution from the consensus-critical path, and that’s a real design choice with clear precedent across high-performance chains: you get more predictable block cadence as transaction complexity rises, but you inherit a new class of validity and backlog problems that only show up under messy, adversarial load.
The threshold that matters is whether the testnet/devnet can hold ~600 ms blocks while the throttles stay mostly in the background, because if EIE and backpressure are constantly engaging, the pipeline is still “fast” on paper but constrained in practice. This becomes market-relevant when the mainnet date is confirmed and the network can demonstrate sustained low-latency behavior without routine execution lag becoming the dominant limiter.
