xExchange

Cronos

MultiversX

Tectonic

<div style="margin: 26px 0; display: flex; flex-wrap: wrap; gap: 14px;">
 <div style="flex: 1 1 280px; padding: 18px 20px; border: 1px solid #a7f3d0; border-radius: 12px; background: #ecfdf5;">
  <h3 style="margin: 0 0 12px; color: #065f46; font-size: 20px;" id="what-multiversx-confirmed">What MultiversX confirmed</h3>
  <ul style="margin: 0; padding-left: 20px;">
   <li style="margin-bottom: 7px;">The problem involved transaction atomicity.</li>
   <li style="margin-bottom: 7px;">Invalid changes were recorded onchain.</li>
   <li style="margin-bottom: 7px;">Mainnet operations were suspended.</li>
   <li style="margin-bottom: 7px;">A patch entered shadow-fork testing.</li>
   <li>Targeted recovery was being evaluated.</li>
  </ul>
 </div>
 <div style="flex: 1 1 280px; padding: 18px 20px; border: 1px solid #fecaca; border-radius: 12px; background: #fef2f2;">
  <h3 style="margin: 0 0 12px; color: #991b1b; font-size: 20px;" id="what-remains-unknown">What remains unknown</h3>
  <ul style="margin: 0; padding-left: 20px;">
   <li style="margin-bottom: 7px;">Whether users permanently lost funds.</li>
   <li style="margin-bottom: 7px;">Which accounts or contracts were affected.</li>
   <li style="margin-bottom: 7px;">How the attacker triggered the failure.</li>
   <li style="margin-bottom: 7px;">Which recovery method will be adopted.</li>
   <li>When every service will reopen.</li>
  </ul>
 </div>
</div>
<h2 id="the-halt-froze-the-problem-it-did-not-undo-it">The halt froze the problem; it did not undo it</h2>
<p>In its <a href="https://x.com/multiversx/status/2101341591277391953" rel="noopener noreferrer nofollow">incident update</a>, 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.</p>
<p>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.</p>
<p>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.</p>
<p>When checked on September 20, the <a href="https://status.multiversx.com/" rel="noopener noreferrer nofollow">MultiversX status page</a> 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.</p>
<p>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.</p>
<h2 id="atomicity-is-the-a-rel-noopener-noreferrer-nofollow-blockchain-a-version-of-all-or-nothing">Atomicity is the <a rel="noopener noreferrer nofollow">blockchain</a> version of “all or nothing”</h2>
<p>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.</p>
<div style="margin: 26px 0; border: 1px solid #cbd5e1; border-radius: 12px; overflow: hidden; background: #ffffff;">
 <div style="padding: 14px 18px; background: #172554; color: #ffffff;"><strong>Atomic execution in plain English</strong>
 </div>
 <div style="display: flex; flex-wrap: wrap;">
  <div style="flex: 1 1 280px; padding: 18px; background: #f0fdf4; border-bottom: 1px solid #e2e8f0;">
   <h3 style="margin: 0 0 9px; color: #166534;" id="expected-result">Expected result</h3>
   <p style="margin: 0;">Every required step succeeds and all changes are committed together. If any step fails, none of the transaction’s changes should be committed.</p>
  </div>
  <div style="flex: 1 1 280px; padding: 18px; background: #fff7ed; border-bottom: 1px solid #e2e8f0;">
   <h3 style="margin: 0 0 9px; color: #9a3412;" id="atomicity-failure">Atomicity failure</h3>
   <p style="margin: 0;">One operation fails, but an earlier state change remains. The network can then record a partial result that should not have existed by itself.</p>
  </div>
 </div>
 <p style="margin: 0; padding: 13px 18px; color: #475569; background: #f8fafc;"><em>This is a simplified example of atomicity, not a reconstruction of the MultiversX incident.</em></p>
</div>
<p>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.</p>
<h2 id="finality-proves-agreement-not-bug-free-execution">Finality proves agreement, not bug-free execution</h2>
<p>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.</p>
<p>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.</p>
<blockquote style="margin: 24px 0; padding: 18px 22px; border-left: 4px solid #7c3aed; background: #f5f3ff; color: #1e293b;">
 <p style="margin: 0;">Consensus can establish which state the network accepted. It cannot guarantee that a software bug did not help produce that state.</p>
</blockquote>
<p>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.</p>
<h2 id="the-shadow-fork-provides-a-rehearsal-before-mainnet-restarts">The shadow fork provides a rehearsal before mainnet restarts</h2>
<p>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.</p>
<p>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:</p>
<div style="margin: 22px 0; padding: 18px 22px; border-left: 4px solid #0284c7; background: #f0f9ff;">
 <ul style="margin: 0; padding-left: 20px;">
  <li style="margin-bottom: 8px;">Whether nodes calculate the same repaired state.</li>
  <li style="margin-bottom: 8px;">Whether unaffected balances remain unchanged.</li>
  <li style="margin-bottom: 8px;">Whether applications read the corrected records properly.</li>
  <li style="margin-bottom: 8px;">Whether bridges and exchanges can reconcile their data.</li>
  <li>Whether validators can restart without producing competing chains.</li>
 </ul>
</div>
<p>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.</p>
<h2 id="targeted-repair-would-avoid-rewinding-the-entire-chain">Targeted repair would avoid rewinding the entire chain</h2>
<p>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.</p>
<div style="margin: 26px 0; display: flex; flex-wrap: wrap; gap: 14px;">
 <div style="flex: 1 1 280px; padding: 19px 20px; border: 1px solid #bfdbfe; border-radius: 12px; background: #eff6ff;">
  <h3 style="margin: 0 0 10px; color: #1d4ed8;" id="targeted-state-correction">Targeted state correction</h3>
  <p>Only balances, contract storage or other records connected with the incident would be repaired. Unrelated transactions could remain in the finalized history.</p>
  <p style="margin-bottom: 0;"><strong>Main difficulty:</strong> proving that the correction includes every invalid change—and nothing else.</p>
 </div>
 <div style="flex: 1 1 280px; padding: 19px 20px; border: 1px solid #fed7aa; border-radius: 12px; background: #fff7ed;">
  <h3 style="margin: 0 0 10px; color: #c2410c;" id="broad-chain-rollback">Broad chain rollback</h3>
  <p>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.</p>
  <p style="margin-bottom: 0;"><strong>Main difficulty:</strong> legitimate transfers and application activity may need to be repeated or reconciled.</p>
 </div>
</div>
<p>The cost of a broader rollback was visible after the Tectonic exploit, when <a href="https://coindoo.com/why-cronos-could-recover-tectonic-exploit/" rel="noopener noreferrer nofollow">Cronos validators removed almost 11,000 blocks</a> 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.</p>
<p>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.</p>
<p>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.</p>
<h2 id="what-multiversx-users-should-do-during-the-pause">What MultiversX users should do during the pause</h2>
<p>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.</p>
<div style="margin: 26px 0; border: 1px solid #fbbf24; border-radius: 12px; overflow: hidden; background: #fffbeb;">
 <div style="padding: 14px 18px; background: #92400e; color: #ffffff;"><strong>Until MultiversX confirms normal operations</strong>
 </div>
 <div style="padding: 18px 22px;">
  <ul style="margin: 0; padding-left: 20px;">
   <li style="margin-bottom: 9px;">Do not submit or rebroadcast transactions.</li>
   <li style="margin-bottom: 9px;">Do not deposit or withdraw EGLD or ESDT through exchanges.</li>
   <li style="margin-bottom: 9px;">Avoid moving those assets through cross-chain bridges.</li>
   <li style="margin-bottom: 9px;">Keep the transaction hash for anything submitted near the halt.</li>
   <li style="margin-bottom: 9px;">Ignore recovery links, migrations and unsolicited support messages.</li>
   <li>Wait for both MultiversX and the relevant platform to confirm reopening.</li>
  </ul>
 </div>
</div>
<p>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.</p>
<p>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.</p>
<h2 id="a-restart-must-be-verifiable">A restart must be verifiable</h2>
<p>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.</p>
<p>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.</p>
<p style="text-align: center;"><em>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.</em></p>
<p>The post <a href="https://coindoo.com/multiversx-halts-mainnet-to-repair-invalid-state/" rel="noopener noreferrer nofollow">MultiversX Halts Mainnet to Repair Invalid State</a> appeared first on <a href="https://coindoo.com" rel="noopener noreferrer nofollow">Coindoo</a>.</p>

MultiversX Halts Mainnet to Repair Invalid State

Table of Contents

Coindoo.com

Other articles published on Sep 20, 2026

Join our free newsletter for daily crypto updates!