Worked example · 2026-09

MultiversX — a VM that did not roll back cleanly let invalid state reach the ledger, and the chain stopped — MultiversX mainnet — 2026-09-19

Loss

not quantified. MultiversX says the attempt caused invalid state changes, that funds are safe, and that the attacker's accounts were identified and frozen in coordination with major exchanges. Network progression was paused; a recovery hard fork used a checkpoint at round 33384826 (2026-09-19 06:37 UTC). Upbit flagged EGLD for trading caution and suspended deposits and withdrawals; Kraken set EGLD pairs to cancel-only.

OAK Techniques observed

OAK-T9.014 (Protocol-Client Consensus Bug — primary, class provisional. MultiversX confirms "an actor attempted to exploit a VM-level atomicity issue" that let invalid state changes settle on the ledger before block production was stopped. A defect in the protocol's own execution layer that validators accepted as valid is T9.014's subject, and this sits next to the Liquid Network anchor from earlier the same month. See techniques/T9.014-protocol-client-consensus-bug.md). The specific atomicity failure is undisclosed — whether async-call callbacks, partial reverts, or cross-shard execution — and a technical report has been promised.

Attribution

pseudonymous; accounts frozen, identity not disclosed.

Key teaching point

Atomicity is a promise the VM makes to every contract on the chain, and when the VM breaks it, every contract's invariants break at once. Contract authors reason about "this call either fully happens or fully reverts"; a VM-level atomicity bug invalidates that reasoning everywhere simultaneously, which is why the only available response was chain-wide: halt, fork, and repair state. The recovery — a targeted state repair plus exchange-side freezes — worked here because the chain could be stopped and the attacker's exits ran through centralised venues. Neither is a property to design around.