Original source text
Blockchain
20 September 2026 | 14:55 MultiversX stopped its mainnet after an attempted virtual-machine exploit altered the blockchain’s state—the live record of balances, token ownership and smart-contract data. The harder decision is how to repair those changes without reversing legitimate transactions.
What MultiversX confirmed The problem involved transaction atomicity. Invalid changes were recorded onchain. Mainnet operations were suspended. A patch entered shadow-fork testing. Targeted recovery was being evaluated. What remains unknown Whether users permanently lost funds. Which accounts or contracts were affected. How the attacker triggered the failure. Which recovery method will be adopted. When every service will reopen. The halt froze the problem; it did not undo it In its incident update, MultiversX said an attacker attempted to exploit an atomicity problem in the mainnet virtual-machine layer. Developers suspended network operations while they traced the resulting state changes and prepared a patch. No confirmed loss figure had been disclosed.
Stopping block production prevents new transactions from building on records that may already be incorrect. It also blocks another attempt using the same method while engineers determine which balances or contract entries were affected.
The pause does not undo changes the network already accepted. Those records remain the starting point used by wallets, applications and bridges until MultiversX adopts a recovery plan.
When checked on September 20, the MultiversX status page classified the system as partially degraded. The public API, xPortal, Explorer, Wallet, Bridge, xExchange and xLaunchpad showed degraded performance, while the gateway and index were listed as operational.
Those labels describe individual services and do not confirm that normal transaction processing has resumed. Restoring the interfaces also would not resolve the underlying accounting problem. To understand why, it helps to start with transaction atomicity.
Atomicity is the blockchain version of “all or nothing” A smart-contract transaction can contain several connected operations. One balance might be reduced, another increased and a liquidity pool updated. Atomic execution requires the complete sequence to succeed before any of those changes becomes permanent.
Atomic execution in plain English
Expected result Every required step succeeds and all changes are committed together. If any step fails, none of the transaction’s changes should be committed.
Atomicity failure One operation fails, but an earlier state change remains. The network can then record a partial result that should not have existed by itself.
This is a simplified example of atomicity, not a reconstruction of the MultiversX incident.
A broken transaction could leave an account balance, token supply or contract record inconsistent with the intended result. MultiversX has not disclosed what type of data was altered, so there is not enough evidence to say that the attacker created tokens, drained a particular contract or stole a known amount.
Finality proves agreement, not bug-free execution Blockchain finality means validators have agreed on which block and resulting state belong to the canonical chain. It does not prove that the software used to calculate that state was free from defects.
Validators execute the same protocol rules and compare their results. If those rules contain the same flaw across every node, validators can consistently agree on an outcome that the protocol was never intended to permit.
Consensus can establish which state the network accepted. It cannot guarantee that a software bug did not help produce that state.
Installing corrected software prevents the same execution path from working again, but it does not decide what should happen to the changes already recorded. MultiversX must identify the affected entries and give validators a reproducible way to verify that unrelated activity remains unchanged.
The shadow fork provides a rehearsal before mainnet restarts MultiversX has prepared a patch for testing in a shadow-fork environment. A shadow fork copies the relevant mainnet history and state into an isolated environment, allowing engineers to reproduce real network conditions without experimenting on live balances.
The team can apply the patch, replay the affected sequence and test a proposed recovery before validators install it on mainnet. That process should establish:
Whether nodes calculate the same repaired state. Whether unaffected balances remain unchanged. Whether applications read the corrected records properly. Whether bridges and exchanges can reconcile their data. Whether validators can restart without producing competing chains. Passing those tests would not reopen every service automatically. Deployment still requires coordination among validators, exchanges, bridges and the infrastructure providers connecting users and applications to MultiversX.
Targeted repair would avoid rewinding the entire chain MultiversX said it was evaluating a targeted recovery intended to preserve finalized transaction history and legitimate user records while addressing only the changes connected with the incident. The project has not explained how that correction would be implemented.
Targeted state correction Only balances, contract storage or other records connected with the incident would be repaired. Unrelated transactions could remain in the finalized history.
Main difficulty: proving that the correction includes every invalid change—and nothing else.
Broad chain rollback The network would return to an earlier block and rebuild from there. Transactions completed after that point could disappear even if they had no connection with the incident.
Main difficulty: legitimate transfers and application activity may need to be repeated or reconciled.
The cost of a broader rollback was visible after the Tectonic exploit, when Cronos validators removed almost 11,000 blocks covering nearly two hours. The rollback reversed most of the incident-related borrowing still recorded on Cronos, but it also reversed unrelated transactions completed during that period.
The two incidents have different causes. The Cronos example matters here because it shows the collateral cost of rewinding a shared ledger. MultiversX says it is considering a narrower repair, but it has not yet shown how the affected records would be isolated.
A targeted repair would not necessarily delete the original blocks. The transaction history could remain visible while a coordinated protocol change establishes the state that applications and validators will recognize after the restart. The method cannot be assessed properly until MultiversX publishes its recovery design.
What MultiversX users should do during the pause For ordinary holders, the simplest instruction is to wait. MultiversX has not asked users to migrate tokens, connect wallets to a recovery website or approve a corrective transaction.
Until MultiversX confirms normal operations
Do not submit or rebroadcast transactions. Do not deposit or withdraw EGLD or ESDT through exchanges. Avoid moving those assets through cross-chain bridges. Keep the transaction hash for anything submitted near the halt. Ignore recovery links, migrations and unsolicited support messages. Wait for both MultiversX and the relevant platform to confirm reopening. A network repair would be adopted by validators and infrastructure operators. It would not require users to reveal seed phrases or send assets to a new address.
Wallets and explorers may also need time to resynchronize after block production resumes. A stale balance or missing recent transaction in an interface would not, by itself, show that the underlying assets had changed.
A restart must be verifiable Restarting block production will restore availability, but it will not answer the finality question by itself. MultiversX still needs to disclose which accounts or contracts were affected, how the repaired state was calculated and how validators independently reached the same result.
If that record shows that only incident-related changes were corrected, targeted recovery may preserve more legitimate activity than a broad rollback. Without it, the network could resume while users remain unable to verify why some finalized changes were altered and others were retained.
This article is provided for informational purposes only and does not constitute financial or investment advice. Network conditions and recovery instructions may change as MultiversX releases further updates.
Author
Alex is Editor-in-Chief of Coindoo and co-founder of Millennial Media Group, with nearly a decade of experience covering financial markets - crypto first, then everything else. It started in 2016 with Bitcoin. Like most people at the time, he didn't fully understand it - so he kept digging. Blockchain, tokenomics, the projects, the cycles. That curiosity never stopped, and eventually pulled him into traditional markets too: equities, commodities, macro. Not because he left crypto behind, but because you can't properly understand one without the other. What drives him is straightforward: he wants to know why something is happening, not just that it's happening. Most market coverage stops at the headline - price up, price down, here's a chart. Alex finds that kind of reporting actively unhelpful. If you walk away from an article without understanding the mechanism behind the move, what did you actually learn? He holds a degree in Tourism from New Bulgarian University - not the most obvious path into financial markets, but markets have a way of pulling in people who are simply too curious to stay out. He has authored over 200 in-depth analyses and more than 10,000 articles across crypto and traditional finance. He still thinks every day in markets teaches him something new. That's probably why he hasn't stopped.
