Overview
The Radix Engine is the execution environment that runs all Scrypto smart contracts on Radix. Unlike the EVM (which is a general-purpose virtual machine), the Radix Engine is purpose-built for DeFi with asset-oriented programming enforced at the system level.
System-Level Enforcement
The Radix Engine enforces asset conservation, access rules, and resource behaviors (mint, burn, freeze) at the engine level – not in application code. This means an entire class of bugs (reentrancy, overflow, approval exploits) is structurally impossible.
Deterministic Execution
Every transaction produces the same result regardless of execution timing or node. Combined with transaction manifests, users can predict exactly what a transaction will do before signing.
The August 2026 vault reference vulnerability
On 31 August 2026 a single transaction took resources out of sixty vaults belonging to other people, and the Radix Engine permitted it. Between 16:02 and 16:57 UTC twenty-six such transactions emptied every Hyperlane-bridged asset on the network. At 22:02 UTC the cause was stated publicly as the engine rather than the bridge — "any assets, token or nft, could have been withdrawn and moved without permission" — and by then its node runners had halted mainnet to stop further use of it; the last state the ledger committed was version 557,840,627, at 21:19:48 UTC.
The defect sits in the reference check every transaction passes through before any WASM runs. In verify_boot_ref_value, a non-global node named in a manifest is accepted as a DirectAccess reference, and handed to the caller's frame, on one test: that its blueprint is FungibleVault or NonFungibleVault. Ownership is not checked, and is not an input to the function. Direct access exists so that recall can work, and recall is gated behind the resource's recaller role — but the same vault blueprint gates take, take_advanced and lock_fee behind the resource's withdrawer role, which on any freely transferable token is open. An account's balance is protected by the account component's own access rules on withdraw; a call made straight to the vault never reaches them.
The failure is worth stating precisely, because it is not the class of bug the section above says the engine removes. There was no reentrancy, no overflow and no approval to abuse. The engine's rules were not evaded — they were applied to a caller the engine had already decided was entitled to hold the reference. System-level enforcement moves the guarantee from application code into the engine, and this is the cost of that trade: application authors could not have written their way out of it, and one function in the boot path decided the outcome for every account on the network. The version this was read at is v1.3.1, the Cuttlefish release, and the same function on main was byte-identical to it at the time.
The fix left that function alone. verify_boot_ref_value is byte-identical in Scrypto v1.4.0, the Eagle Ray release of 7 September 2026, so a vault reference still passes the boot check. The change is in before_invoke, which runs before every method call and now asks whether the calling frame is allowed to invoke the object it names. For a Direct method, the kind recall uses, the object must be visible to the frame for a direct call; for any other method it must be visible for a normal one. A call that fails returns SystemError::InvalidInvokeAccess, an error v1.3.1 does not have. The check is gated on a system-logic version flag, should_check_method_receiver_access. Eagle Ray enacted on mainnet at the start of epoch 339,898 on 11 September, and after the restart a blueprint written to repeat the drain was published there; its call was rejected with that error.
The Radix Engine and Xi'an
The Radix Engine is the execution environment of Babylon mainnet, and everything above describes what runs there today. Its role in the sharded successor network is changing.
On 1 August 2026 the lead developer of the Xi'an production candidate confirmed that a purpose-built virtual machine is underway to replace the Radix Engine in Xi'an, having assessed the engine as "not in the ballpark" for sharded operation. The candidate integrates the real engine today, so this is a stated direction rather than a completed change.
The technical objection is narrow and specific. Cross-shard atomic commitment requires every transaction to declare in advance exactly which state it will read and write, because that declaration fixes which shards participate and lets conflicts be analysed before anything executes. The Radix Engine's state access is, on the developer's assessment, "too loose" to resolve those dependencies deterministically ahead of execution for a Turing-complete contract language – which leaves only unattractive routes to transaction preview, such as an ingress node holding state from every shard, or discovering each dependency part-way through execution.
For developers, the expected migration cost was given on 2 August 2026 as "best case scenario - contracts will just need a recompile. worst case scenario - there'll be some automatic transpiler devs can use to upgrade source code". How much the new VM borrows from the Radix Engine has not been stated beyond an April 2026 remark that it "might borrow some ideas from RE".