Why Move's Linear Types Are the Answer to Reentrancy Hacks

Reentrancy is a language bug. The DAO hack, Euler Finance, and hundreds of other exploits stem from Solidity's permissive mutability model. Contracts expose state that can be manipulated mid-execution via fallback functions. This is a choice, not a law.

Linear types enforce state ownership. Move's key and store abilities treat assets as physical objects. A resource can only exist in one place at one time, making the "check-effects-interactions" pattern a compiler guarantee, not a developer prayer.

EVM workarounds are duct tape. Tools like OpenZeppelin's ReentrancyGuard and formal verification for protocols like Uniswap V4 are reactive patches. They add gas overhead and audit complexity to solve a problem Move's type system prevents at compile time.

Evidence: Aptos and Sui have zero reentrancy hacks. Since mainnet launch, no major exploit on these Move-based chains has been a classic reentrancy attack. The $3B lost on Ethereum is the tax for an unconstrained programming model.

Reentrancy is a resource management failure. The EVM's call-based architecture allows a contract's state to be read and modified mid-execution, violating atomicity. This is not a logic bug but a fundamental flaw in the execution model.

Linear types enforce single ownership. In Move, a resource (like a vault's funds) is a type that cannot be copied or implicitly discarded. This compile-time guarantee prevents the double-spend logic at the heart of reentrancy attacks like The DAO hack.

Contrast with EVM post-facto fixes. Solidity relies on checks-effects-interactions patterns and OpenZeppelin's ReentrancyGuard library—runtime bandaids. Move's type system eliminates the vulnerability class entirely, akin to Rust's borrow checker preventing memory safety bugs.

Evidence from adoption. Protocols like Aptos and Sui use Move as their native language. Major hacks like the $197M Nomad bridge exploit are structurally impossible in these environments, shifting security left to the compiler.

Linear types enforce single ownership. A resource, like a token or NFT, can only exist in one place at one time. This eliminates the double-spend logic that reentrancy exploits, a flaw inherent to the EVM's allowance-based accounting.

The compiler is the security auditor. Unlike Solidity's runtime checks, Move's borrow checker validates resource safety at compile time. This shifts security left, making vulnerabilities like those in the original DAO or recent Euler Finance hack structurally impossible.

Contrast with EVM's allowance model. Solidity's approve/transferFrom pattern creates temporary states where an asset is both spent and unspent. Projects like Uniswap and Aave require complex reentrancy guards; Move's Aptos and Sui blockchains make these guards redundant by design.

Evidence: Zero reentrancy hacks have occurred on production Move blockchains like Aptos and Sui, which processed billions in TVL during their initial DeFi launches without a single incident of this class.

Linear types enforce single ownership. A Move resource, like a Coin, cannot be copied or implicitly discarded. This eliminates the double-spend logic at the heart of reentrancy attacks seen in Ethereum's DAO hack or the $60M Cream Finance exploit.

The asset is the capability. In Solidity, you call a function and trust its internal checks. In Move, transferring an asset is the authorization. This capability-based security model, inspired by systems like JPMorgan's Kadena, makes invalid state transitions unrepresentable in code.

Contrast with EVM mitigations. Projects like OpenZeppelin build fragile guardrails (nonReentrant modifiers). Move bakes the guardrails into the compiler. The Aptos and Sui blockchains demonstrate this: zero production reentrancy hacks since mainnet launch, a stark contrast to the perpetual exploit cycle on EVM L2s like Arbitrum and Optimism.

Evidence: Formal verification is trivial. The Move Prover formally verifies resource invariants—like a vault's total supply—against all possible transaction sequences. This turns a runtime bug (reentrancy) into a compile-time error, a guarantee impossible for Solidity's dynamic storage layout.