Move vs Solidity How Move Language Chains Compare to EVM Development

02 September 2026

Smart contract developers know the drill. You write a Solidity function, test it, audit it, and pray you caught every edge case. Move was designed to change that equation. Built originally for the Diem project at Facebook, Move takes a fundamentally different approach: safety is baked into the language and the virtual machine, not left to the developer's discipline.

The core difference: linear types vs account balances

Solidity treats tokens as numbers stored in a mapping from address to uint256. The ERC-20 standard works, but it trusts the contract to enforce who can transfer what. A single missing require or a reentrancy gap can drain an entire pool.

Move treats assets as first-class resources. A token is an instance of a struct with the store or key ability. The language enforces that this resource can never be copied, lost, or silently discarded. If a Move function takes a resource as input, it must either destroy it, store it, or return it. The compiler enforces this.

Reentrancy: Solved at the VM Level

Reentrancy attacks have cost the Ethereum ecosystem billions. The pattern is well understood: an external call triggers a fallback that re-enters the original function before state updates complete. The standard fix is a mutex in the form of OpenZeppelin's ReentrancyGuard.

Move's resource model eliminates reentrancy at a deeper level. On Sui, transactions execute against owned objects - only the current transaction can modify them. No external contract can re-enter because the object's ownership is exclusive for the duration of the call. On Aptos, the Move VM prevents recursive calls that would modify the same resource without proper borrowing. The language itself guarantees that a function cannot be called again on the same mutable state while it is still executing.

Integer overflow: already handled

Solidity prior to 0.8.0 required SafeMath for arithmetic safety. Even after 0.8.0 added built-in overflow checks, the checks are opt-out via unchecked blocks. A single forgotten unchecked or a third-party library that predates 0.8.0 reintroduces the bug.

Move makes overflow a compile-time error. Arithmetic operations expect fixed-size integers, and the VM aborts on overflow or underflow at runtime. There is no unchecked escape hatch. If a developer wants wrapping behavior, they must explicitly call a standard library function like math::overflowing_add. The safe path is the only default.

ERC-20 transfer vs move resource transfer

Consider a standard ERC-20 transfer function in Solidity. The function checks the sender's balance, deducts from it, and adds to the recipient. Each step is a guarded action. Miss the balance check - or forget to handle the return value of an external call - and bugs appear. Auditors must trace every possible execution path.

In Move, a transfer is a move of a resource from one account to another. On Sui, transfer functions are built into the object model. The sender's object is consumed, and the recipient receives a new object. The language guarantees the object exists and the sender owns it. No guards needed because the type system ensures the resource is valid and owned.

Here is a concrete illustration. In Solidity, an ERC-20 transfer contains five guard statements in the reference implementation: owner check, spender allowance check, sufficient balance check, and two update operations. Move's transfer function on Sui simply takes the Coin object from the caller and sends it. The Move VM checks ownership at the object level. The developer cannot accidentally transfer more than they hold because they can only pass objects they own.

Unauthorized transfers: different threat models

Solidity uses msg.sender checks within function bodies. Every function that changes state must explicitly verify the caller's permission. A single missing require in a new function on an upgradeable contract can expose all user funds.

Move verifies ownership at the resource level on Sui and at the account level on Aptos. A Coin object can only be passed as an argument to a function if the caller's signature matches the owning account. The compiler and runtime enforce this without explicit checks in the function body. The developer cannot accidentally expose a function that lets anyone drain locked tokens. The type system prevents it.

The Tradeoffs

This safety comes with constraints. Move's linear type system forces developers to think carefully about resource ownership from the start. Writing ad-hoc token logic on Sui or Aptos requires more upfront planning than slapping together a Solidity contract. The learning curve is steeper for developers accustomed to EVM conventions.

Tooling is narrower. Hardhat, Foundry, and Remix support thousands of active projects. Sui's CLI and Aptos's Move framework are younger. Editors have fewer snippets, fewer tutorials, and fewer examples of real-world dapps.

Audits remain necessary on Move chains, but they focus on business logic rather than reentrancy or overflow. The language removes whole categories of bugs that consume the majority of audit time on Ethereum. For developers building high-value protocols, the tradeoff increasingly favors Move's design.

Back to sui & aptos