Objects have single ownership and versioning, so functions cannot unintentionally re-enter or duplicate resources.

Move’s strict resource ownership and linear types prevent reentrancy by ensuring objects can’t be accessed or modified concurrently during a transaction, eliminating reentrant calls and state inconsistencies.

You avoid reentrancy problems in Move because the object model forces strict ownership and linear usage of resources, meaning an object can only be borrowed or moved once in a transaction and its version must update before it can be touched again. This prevents a contract from being re-entered while still holding mutable access to the same state, which is the classic attack surface in Solidity. Since objects in Move can’t be duplicated or partially reused, and function calls complete before ownership is released, an attacker has no way to recursively drain funds or trigger inconsistent state changes. In practice, this design makes reentrancy exploits that plague account-based systems like Ethereum far less likely on Sui.

How Move Prevents Reentrancy Vulnerabilities

1. Linear resource model – Resources can't be copied or accessed from multiple places, preventing unsafe reentry.

2. Strict ownership and borrowing rules – Enforces exclusive access to data during execution.

3. No external or dynamic calls – Contracts can't call back into each other during execution.

4. Isolated, deterministic execution – All object access is static and scoped to a single transaction.

Result: Move's object model prevents reentrancy by design—eliminating the key risks that make reentrancy possible in other smart contract languages like Solidity.