What MultiversX confirmed The problem involved transaction atomicity. Invalid changes were recorded onchain. Mainnet operations were suspended. A patch entered shadow-fork testing. Targeted r
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.
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 EnglishEvery required step succeeds and all changes are committed together. If any step fails, none of the transaction’s changes should be committed.
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.
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.
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:
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.
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.
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.
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.
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 operationsA 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.
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.
The post MultiversX Halts Mainnet to Repair Invalid State appeared first on Coindoo.
