MultiversX Halts Mainnet to Repair Invalid State

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.