Skip to main content

Move VM Memory Safety vs EVM Reentrancy: Why the Aptos and Sui Resource Model Eliminates Entire Classes of Smart Contract Vulnerabilities

· 9 min read
Dora Noda
Dora Noda
Software Engineer

The DAO hack of 2016 drained $60 million from Ethereum in a single afternoon. Nine years later, reentrancy attacks still cost DeFi protocols $35.7 million across 22 separate incidents in 2024 alone. The same class of vulnerability — an attacker calling back into a contract before its state is updated — continues to haunt the EVM ecosystem despite years of developer education, audit tooling, and battle-tested patterns.

Aptos and Sui, both built on the Move language, take a fundamentally different approach: they make entire categories of vulnerabilities impossible by design.

The Root Cause: How EVM Reentrancy Happens​

To understand why Move is different, it helps to understand exactly why reentrancy is possible on Ethereum in the first place.

Solidity contracts can call external contracts mid-execution. When contract A calls contract B, execution transfers entirely to B. B can then call back into A — "re-entering" it — before A has finished updating its internal state. If A's withdrawal logic looks like this:

// Vulnerable pattern
function withdraw(uint amount) external {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}(""); // external call first
    balances[msg.sender] -= amount;                         // state update second
}

An attacker's contract can receive ETH in the callback, immediately call withdraw again, and drain funds before balances[msg.sender] is ever decremented. This is exactly what happened to The DAO — the attacker's contract recursively called back into the withdrawal function 3.6 million times in a loop.

The fix sounds simple: update state before making external calls (the "Checks-Effects-Interactions" pattern). But developers forget. Auditors miss it. The pattern is a convention enforced only by human diligence, not the language itself.

The Move Approach: Resources Can't Be Duplicated or Destroyed​

Move was designed from the ground up to prevent this class of error at the type-system level. The core concept is the linear type system and resource types.

In Move, a resource is a special kind of value that:

  • Cannot be copied — it can only be moved between storage locations
  • Cannot be dropped — it must be explicitly consumed or stored somewhere
  • Has a single owner at any given moment — tracked by the VM, not by a mapping

This sounds abstract, but the implications are concrete. Consider how a token transfer works:

  • In Solidity, a token balance is a uint256 in a mapping. The number can theoretically be manipulated if the update order is wrong.
  • In Move, a token is an actual resource object that lives in an account's storage. You physically move it from one location to another — there is no intermediate state where the resource exists in two places, or no places.

The Move VM enforces these invariants at the bytecode level, not the source level. Even if a developer writes buggy code, the VM will reject any transaction that attempts to duplicate or silently discard a resource.

Why Reentrancy Is Structurally Impossible in Move​

Reentrancy requires two conditions: the ability to call external code mid-execution, and mutable shared state that can be manipulated during that callback. Move breaks both.

Move does not allow dynamic dispatch in the way Solidity does. There are no arbitrary external calls that pass control to unknown code. Functions must be called statically — the callee is known at compile time. This means an attacker cannot deploy a contract that re-enters your module during a callback, because your module never hands execution to an unknown external contract.

Additionally, Move's object model on Sui and Aptos uses an ownership system where objects are explicitly passed in and out of functions. An object that has been "moved into" a function is not accessible anywhere else until the function returns it. Concurrent access to the same resource in a single transaction is simply not possible.

Research published in 2025 confirms: "In Move, reentrancy isn't possible since dynamic callbacks are not possible — a fundamental difference from Solidity where reentrancy remains a major threat."

Double-Spend Prevention Without Mutex Locks​

In EVM-based systems, double-spend protection relies on careful programming. Developers must manually ensure that a token can't be spent twice in one transaction by tracking state updates diligently.

Move's linear type system makes double-spending structurally impossible. Because a resource cannot be copied, spending a coin literally removes it from your account's storage. There is no way to spend the same resource twice in a transaction because after the first spend, the resource no longer exists in your control. The VM enforces this — it's not a convention, it's a constraint.

This also extends to capability objects on Sui. A Capability resource, once consumed, cannot be used again. Compare this to EVM access control patterns where a capability is typically a role encoded in a boolean or address mapping, which can be checked multiple times.

One real-world incident on Sui highlights a nuance: a DEX was found to have a flaw where withdrawal logic failed to enforce single-use constraints on a mutable reference to a capability — not the capability itself. This demonstrates that while Move's resource model eliminates whole classes of bugs, developers can still introduce logic errors when working with references rather than owned resources. The threat surface is narrowed dramatically, but not to zero.

Integer Overflow: Another Problem Move Solves by Default​

In early Solidity (pre-0.8.0), integer arithmetic would silently wrap around on overflow. This allowed attackers to manipulate token balances by triggering overflow conditions — a vulnerability that contributed to several high-profile DeFi exploits.

Solidity 0.8.0 introduced automatic overflow checking, but only after years of damage. Move has included this protection since its inception: any transaction that causes an integer overflow is automatically aborted. There is no opt-out, no unchecked equivalent by default, and no legacy contracts with the old behavior to worry about.

Formal Verification: Move Prover vs. EVM Auditing​

Move's security story extends beyond the language into its tooling. The Move Prover is a formal verification tool built alongside the language itself — not an afterthought.

With Move Prover, developers write specifications directly in their Move source files using a specification language. These specs are then mathematically verified against the implementation. A spec might assert: "After this function executes, the total coin supply remains unchanged." The Prover will either confirm this is always true, or provide a counterexample showing exactly when it fails.

This is categorically different from how most Solidity auditing works:

AspectMove ProverSolidity Auditing Tools
Verification typeMathematical proofPattern matching / fuzzing
CoverageComplete (within spec scope)Best-effort
IntegrationPart of the language toolchainThird-party tools (Slither, Certora)
TimingDevelopment timePre-deployment audit
CostFree, in-repoExpensive manual audits

Tools like Slither for Solidity perform static analysis and detect known vulnerability patterns. Certora Prover for Solidity does support formal verification, and can express a broader set of properties — including cross-transaction invariants. But Certora requires writing specifications in a separate language and running a separate pipeline, making it a specialized audit step rather than an everyday development tool.

Move Prover's tighter integration means that formal verification is something Aptos and Sui developers can run locally during development, not just as an expensive audit gate. The Aptos framework itself ships with Move Prover specifications for its standard library, providing a security baseline that application developers inherit.

The Residual Risk: What Move Doesn't Eliminate​

Move's design is not a universal security guarantee. Real-world audits of Move contracts reveal that developers can still introduce:

  • Logic errors in business rules (the most common category)
  • Access control bugs when using mutable references instead of owned resources
  • Economic design flaws in DeFi protocols (price oracle manipulation, flash loan attacks)
  • Cross-module interaction bugs when multiple modules interact in unexpected ways

A 2024 study manually audited 652 Move contracts and identified eight defect types, half of which were previously unreported. The attack surface is smaller than Solidity, but it still exists.

The best security posture on Aptos and Sui combines Move Prover specifications, third-party audits, and economic security analysis — not just reliance on the language's built-in protections.

Why This Matters for DeFi Builders in 2025​

The numbers tell a stark story. In 2024, smart contract vulnerabilities cost the DeFi sector over $1.4 billion. Reentrancy contributed $35.7 million of that — a category that would be structurally zero on a Move-based chain with equivalent TVL.

For developers building financial applications, the choice of VM is effectively a choice about your default threat model. Building on EVM means adopting the Checks-Effects-Interactions pattern as a required discipline. Building on Move means that reentrancy is simply not in your threat model at all — your team can focus its security attention on logic errors and economic design instead.

This is not a small difference. Formal verification tools work better when the threat surface is smaller. Auditors can go deeper when they're not spending cycles on well-understood vulnerability classes. The cognitive load on developers writing correct code decreases when the language enforces critical invariants automatically.

The Infrastructure Layer​

Security guarantees only matter if developers can actually build on these chains at scale. Running your own Aptos or Sui node to access the network involves significant operational overhead — hardware provisioning, software upgrades, monitoring, and incident response.

BlockEden.xyz provides enterprise-grade API access for Aptos and Sui, letting developers build on Move's security guarantees without managing node infrastructure. Explore our services to build safer Web3 applications.

The combination of a memory-safe language, structural reentrancy prevention, and integrated formal verification makes Aptos and Sui a compelling platform for high-stakes DeFi applications. Move doesn't just make it easier to write secure smart contracts — it makes certain classes of catastrophic failure mathematically impossible.

Sources consulted:

Share on Twitter