225,000 Empty Rounds Since MultiversX Last Produced a Block

The MultiversX mainnet has not produced a block since Saturday morning. Its clock, however, has not stopped. At 21:11 UTC on September 20 the metachain reported a current round of 33,616,168 against a last committed block at round 33,391,172 — a gap of 224,996 rounds. Since the Supernova upgrade cut the round to 600 milliseconds, that arithmetic converts cleanly: thirty-seven and a half hours in which the network counted out a quarter of a million slots and filled none of them.

MultiversX confirmed on September 20 that an attacker had attempted to exploit an atomicity issue at the virtual-machine level, that the attempt caused invalid state changes on chain, and that the network was paused to prevent further impact. The statement, carried by Bloomingbit and PANews among others, told users not to submit or rebroadcast transactions and not to deposit or withdraw EGLD or ESDT tokens through exchanges or bridges. A fix has been prepared and is being validated on a shadow fork; if it passes, deployment will be coordinated with validators, exchanges and infrastructure partners.

No loss figure has been disclosed. That is not the same as saying nothing was lost — only that the team has not said, and nobody outside it can currently read the chain to find out.

What the node is still willing to tell you

The public gateway keeps answering even with the chain stopped, and what it returns is worth reading slowly. All three shards and the metachain stopped within three and a half minutes of one another on September 19, between 07:37:49 and 07:41:12 UTC.

The metachain's final numbers are the interesting ones. It reports a highest final nonce of 33,342,245, a proposed nonce of 33,342,246, and a last executed nonce of 33,342,247. Execution, in other words, had run two blocks past the last block the network agreed on. Under the architecture MultiversX shipped ten days ago that is not a malfunction — it is the design working as specified. It is also, precisely, the state a recovery now has to reconcile.

Ten days ago, the order of operations changed

Supernova activated on mainnet on September 10 at 18:06:06 UTC, at activation round 32,157,661, cutting the round from 6,000 milliseconds to 600 — figures MultiversX publishes precisely on its own builders page. The speed is the headline. The cause is structural, and MultiversX named it in the title of its own write-up: decoupling consensus and execution.

Under the old arrangement, a proposer executed the transactions in a block and then asked the network to agree on the result. Under Supernova, as Cointelegraph described the design in August, the proposer selects transactions and proposes the block without executing them first. Validators check protocol compliance and vote. Once the votes aggregate into a proof, the block is final. Execution then runs asynchronously, and its results are notarized in a later block header — normally the next one, roughly 600 milliseconds behind.

This is not a fringe reading of the upgrade. The code says the same thing: the release that carried Supernova into mx-chain-go was cut from a branch named feat/supernova-async-exec, and the machinery lives in a directory called process/asyncExecution. The design also ships with its own brakes — an inclusion estimator that caps how many execution results a block may reference, and automatic backpressure that shrinks block capacity when execution falls too far behind.

Related Ontology stopped the chain on a suspicion

None of that is a criticism of the architecture, which answers a real bottleneck and which several chains are converging on. But it changes what a virtual-machine bug means. When execution sits behind finality, a block can be irreversibly agreed before anyone knows what its transactions did. If the answer turns out to be "something invalid," the chain does not get to decline the block. It has already accepted it.

The quiet merge on activation day

There is one more entry in the record, and it needs handling with care.

On September 10 — the same day Supernova activated, in the hours before the activation round — MultiversX's virtual-machine repository received four commits. Three are titled "hardening with copy." The fourth, which merges them, is titled "Merge commit from fork," which is the message GitHub generates by default when a maintainer merges a private fork created for a security advisory. Together they touch eight files and change 72 lines for 84 removed.

The content is unusually uniform. Nearly every change replaces a shared byte slice with an explicit copy — bytes.Clone applied to contract addresses, storage keys, token identifiers, return data and transfer fields across the output, storage, runtime and managed-type contexts. One change fixes something plainly broken: a clone routine that called copy into a slice that had never been allocated, and therefore copied nothing at all.

Aliasing of that kind is a well-understood hazard. When two parts of a virtual machine hold references to the same underlying buffer rather than to copies of it, writing through one can change what the other sees, including after the point where a change was supposed to have been discarded. That is the same family of problem as an atomicity failure, which is the phrase MultiversX used.

It is not, however, proof of anything, and this desk is not going to pretend otherwise. MultiversX has not said which defect was exploited, has published no advisory on that repository, and the commits themselves read like deliberate hardening rather than an emergency. Merging a security fix quietly is a legitimate technique, not misconduct — it is what responsible disclosure looks like from the outside. The honest summary is narrower and still worth writing down: the last public change to the MultiversX virtual machine before the chain halted was a private security merge that spent all of its eighty-odd lines making the VM stop sharing memory it should have been copying.

Five days later, on September 14, a second fix landed in the main chain repository — a corrected type assertion in metaProcessor.getLastExecutionResult after a rollback, inside the asynchronous-execution manager, with 115 lines of code and 648 lines of new tests. That is the component that remembers what execution produced when the chain has to unwind. Whether it is related to what happened on the 19th, only MultiversX can say.

What a targeted recovery asks for

The team says it is evaluating a recovery that would preserve finalized transaction history and legitimate user state while reversing only the invalid changes connected to the incident. The alternative is the blunt one: rewind the chain to a block before the trouble and accept that everything after it, valid or not, goes with it.

The targeted option is better for users, and it is also the one that requires somebody to draw a line through the ledger and label each side. Deciding which state changes are "legitimate" is a judgment, taken by a small group, encoded in a patch, and ratified by validators mostly running what they are handed. Chains that have done this before generally found the engineering was the easy part.

For now the guidance stands: no transactions, no resubmissions, and no movement through exchanges or bridges until MultiversX says the network is back. A deposit or withdrawal that appears to succeed at an exchange right now is the exchange's internal bookkeeping, not the chain's.