Why Move is More Secure Than Solidity: A Deep Dive into Smart Contract Safety
A comprehensive technical comparison of Move vs Solidity security, exploring why Move's resource-oriented programming model eliminates entire categories of smart contract vulnerabilities.
Why Move is More Secure Than Solidity: A Deep Dive into Smart Contract Safety
Smart contract security isn't just a technical concern—it's a $3 billion problem. Since the infamous DAO hack in 2016, the blockchain industry has witnessed exploit after exploit, with billions of dollars in user funds lost to vulnerabilities that could have been prevented. As we build the future of decentralized finance and digital ownership, one question becomes increasingly critical: Are our programming languages setting us up for failure?
This article provides a comprehensive technical comparison of Move vs Solidity security, examining why Move—the language powering Sui, Aptos, and other next-generation blockchains—was designed from the ground up to eliminate entire categories of vulnerabilities that have plagued Solidity developers for years.
The State of Smart Contract Security
Before diving into the technical comparison, let's understand the scale of the problem. According to DeFiLlama, over $3 billion has been lost to smart contract exploits since 2020 alone. The most devastating attacks—The DAO, Parity Wallet, Wormhole, Ronin Bridge—share a common thread: they exploited fundamental weaknesses in how Solidity handles state, external calls, and asset management.
This isn't a criticism of Solidity developers—many of whom are brilliant engineers—but rather an acknowledgment that Solidity was designed in 2014, before we fully understood the unique security requirements of blockchain programming. Move, created by Facebook's (now Meta's) Diem team in 2019, had the benefit of learning from five years of Solidity exploits.
Solidity's Security Challenges: A Technical Analysis
To understand why Move is more secure, we first need to examine the fundamental vulnerabilities that have made Solidity development so treacherous.
1. Reentrancy Attacks: The Original Sin
The reentrancy vulnerability is perhaps the most infamous smart contract exploit. It occurs when a contract makes an external call before updating its state, allowing the called contract to "re-enter" and exploit the inconsistent state.
The DAO Hack (2016): An attacker exploited a reentrancy vulnerability to drain 3.6 million ETH (worth ~$60 million at the time) from The DAO, ultimately leading to the Ethereum/Ethereum Classic hard fork.
Here's the classic vulnerable pattern:
// VULNERABLE Solidity Code
contract VulnerableBank {
mapping(address => uint256) public balances;
function withdraw(uint256 amount) external {
require(balances[msg.sender] >= amount, "Insufficient balance");
// DANGER: External call before state update
(bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
// State update happens AFTER the external call
balances[msg.sender] -= amount;
}
}
// Attacker contract
contract Attacker {
VulnerableBank bank;
function attack() external payable {
bank.deposit{value: 1 ether}();
bank.withdraw(1 ether);
}
receive() external payable {
// Re-enter before balance is updated
if (address(bank).balance >= 1 ether) {
bank.withdraw(1 ether);
}
}
}
The fix requires developers to remember the "checks-effects-interactions" pattern or use reentrancy guards:
// SAFE Solidity Code (with manual protection)
contract SafeBank {
mapping(address => uint256) public balances;
bool private locked;
modifier noReentrant() {
require(!locked, "Reentrant call");
locked = true;
_;
locked = false;
}
function withdraw(uint256 amount) external noReentrant {
require(balances[msg.sender] >= amount, "Insufficient balance");
// Update state BEFORE external call
balances[msg.sender] -= amount;
(bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
}
}
The problem: Security depends on developer discipline. Every single external call is a potential attack vector that must be manually protected.
2. Integer Overflow and Underflow
Before Solidity 0.8, arithmetic operations would silently overflow or underflow, leading to catastrophic vulnerabilities:
// Pre-Solidity 0.8 vulnerability
contract VulnerableToken {
mapping(address => uint256) public balances;
function transfer(address to, uint256 amount) external {
// If balances[msg.sender] = 100 and amount = 101
// This would underflow to a massive number!
balances[msg.sender] -= amount; // DANGER
balances[to] += amount;
}
}
While Solidity 0.8+ added automatic overflow checks, millions of dollars in legacy contracts remain vulnerable, and developers can still use unchecked blocks for "gas optimization"—reintroducing the vulnerability.
3. Unchecked External Calls
Solidity's low-level call functions return a boolean indicating success, but don't revert automatically:
// VULNERABLE: Return value not checked
function withdrawUnsafe(address payable recipient, uint256 amount) external {
recipient.call{value: amount}(""); // Silently fails!
// Contract thinks transfer succeeded
}
// ALSO VULNERABLE: Using transfer() with 2300 gas limit
function withdrawBrittle(address payable recipient, uint256 amount) external {
recipient.transfer(amount); // Can fail for legitimate contracts
}
4. Access Control Mistakes
Solidity's permissive default visibility has led to countless exploits:
// VULNERABLE: Missing access control
contract VulnerableVault {
address public owner;
// Forgot to add onlyOwner modifier!
function setOwner(address newOwner) external {
owner = newOwner; // Anyone can call this
}
// Function visibility defaults were problematic in older versions
function internalHelper() public { // Should be internal
// Sensitive logic exposed
}
}
5. Storage Collision in Proxy Patterns
Upgradeable contracts using proxy patterns are vulnerable to storage collision:
// Implementation V1
contract ImplementationV1 {
uint256 public value; // Slot 0
address public admin; // Slot 1
}
// Implementation V2 - DANGEROUS
contract ImplementationV2 {
address public admin; // Slot 0 - COLLISION with value!
uint256 public value; // Slot 1
uint256 public newValue; // Slot 2
}
This is particularly insidious because the vulnerability might not manifest until an upgrade, potentially corrupting contract state and user funds.
Move's Design Philosophy: Safety by Default
Move was designed with a fundamentally different philosophy: make the secure choice the default choice. Rather than relying on developer discipline, Move's type system and runtime make entire categories of vulnerabilities impossible to express.
The Resource-Oriented Programming Model
Move introduces a revolutionary concept: resources. Unlike Solidity's primitives, Move resources cannot be copied or implicitly discarded. They must be explicitly moved between locations, ensuring that digital assets behave like physical assets.
module example::safe_token {
/// A token that cannot be copied or dropped arbitrarily
struct Token has store, key {
value: u64
}
/// Transfer MUST move the token - no way to duplicate
public fun transfer(token: Token, recipient: address) {
transfer::public_transfer(token, recipient);
// token is now MOVED - cannot be used again
// Compiler enforces this at compile time
}
}
This single design decision eliminates:
- Double-spending vulnerabilities
- Accidental token duplication
- Lost tokens (compiler forces you to handle them)
Key Move Security Features
Let's examine the specific language features that make Move more secure.
1. Linear Type System
Move's linear type system ensures that every value is used exactly once (unless it has the copy ability). This is enforced at compile time:
module example::linear_types {
struct UniqueAsset has key, store {
id: u64
}
public fun process_asset(asset: UniqueAsset) {
// After this function, 'asset' is consumed
// You MUST do something with it
// Option 1: Transfer it
transfer::public_transfer(asset, @recipient);
// Option 2: Destroy it (if it has drop ability)
// let UniqueAsset { id: _ } = asset;
// NOT AN OPTION: Just ignore it
// Compiler Error: "Unused value without drop"
}
// This would NOT compile:
public fun double_spend_attempt(asset: UniqueAsset) {
transfer::public_transfer(asset, @alice);
transfer::public_transfer(asset, @bob); // COMPILER ERROR!
// "asset" was already moved
}
}
2. No Dynamic Dispatch = No Reentrancy
This is perhaps Move's most significant security advantage. Reentrancy is structurally impossible in Move.
In Solidity, any external call can trigger arbitrary code execution because of dynamic dispatch:
// Solidity: msg.sender.call() can run ANY code
(bool success, ) = msg.sender.call{value: amount}("");
In Move, there's no equivalent mechanism. You can only call functions that are statically known at compile time:
module example::no_reentrancy {
use sui::coin::{Self, Coin};
use sui::sui::SUI;
struct Bank has key {
id: UID,
deposits: Balance<SUI>
}
/// This function is IMPOSSIBLE to re-enter
public fun withdraw(bank: &mut Bank, amount: u64, ctx: &mut TxContext): Coin<SUI> {
// 1. Check balance
assert!(balance::value(&bank.deposits) >= amount, EInsufficientFunds);
// 2. Update state AND return coin in one atomic operation
let withdrawn = balance::split(&mut bank.deposits, amount);
coin::from_balance(withdrawn, ctx)
// There's no "external call" - we just return the coin
// The caller receives it after this function completes
// No opportunity for reentrancy!
}
}
The key insight: Move functions don't "call" external contracts mid-execution. They return values that the runtime then routes to recipients. This makes the "checks-effects-interactions" pattern unnecessary—it's the only possible pattern!
3. The Bytecode Verifier
Before any Move code executes on-chain, it must pass through the bytecode verifier—a static analysis tool that enforces safety invariants:
- Type safety (no type confusion)
- Resource safety (no duplication, no loss)
- Reference safety (no dangling references)
- Control flow integrity (no jumping to arbitrary locations)
// The bytecode verifier rejects this at deployment time
module example::rejected {
struct Asset has key {
id: UID,
value: u64
}
// This module would FAIL verification if you tried to:
// 1. Copy an Asset without 'copy' ability
// 2. Drop an Asset without 'drop' ability
// 3. Create references that outlive their data
// 4. Access private fields from another module
}
4. Built-in Formal Verification: The Move Prover
Move includes the Move Prover, a formal verification tool that can mathematically prove your code is correct:
module example::verified_token {
struct Token has key, store {
id: UID,
value: u64
}
/// Transfer tokens with formal guarantees
/// spec: ensures sender balance decreases by amount
/// spec: ensures recipient balance increases by amount
/// spec: ensures total supply unchanged
public fun transfer(
from_token: &mut Token,
to_token: &mut Token,
amount: u64
) {
assert!(from_token.value >= amount, EInsufficientBalance);
from_token.value = from_token.value - amount;
to_token.value = to_token.value + amount;
}
// Move Prover specification
spec transfer {
aborts_if from_token.value < amount;
ensures from_token.value == old(from_token.value) - amount;
ensures to_token.value == old(to_token.value) + amount;
// Conservation: total value unchanged
ensures from_token.value + to_token.value ==
old(from_token.value) + old(to_token.value);
}
}
The Move Prover can verify:
- Absence of arithmetic overflow
- Conservation of resources (total supply invariants)
- Access control correctness
- Custom business logic invariants
Code Comparison: Solidity vs Move
Let's compare implementations of common patterns in both languages.
Token Transfer
Solidity (ERC-20 style):
// Solidity: Multiple ways to lose tokens
contract SolidityToken {
mapping(address => uint256) private _balances;
function transfer(address to, uint256 amount) external returns (bool) {
require(to != address(0), "Transfer to zero address"); // Manual check
require(_balances[msg.sender] >= amount, "Insufficient balance");
// Multiple state changes that could be interrupted
_balances[msg.sender] -= amount;
_balances[to] += amount;
emit Transfer(msg.sender, to, amount);
return true;
}
// DANGER: Tokens can be sent to contracts that can't handle them
// DANGER: Tokens sent to wrong address are lost forever
// DANGER: Zero-amount transfers are valid (gas griefing)
}
Move (Sui Coin style):
module example::move_token {
use sui::coin::{Self, Coin, TreasuryCap};
use sui::transfer;
struct MOVE_TOKEN has drop {}
/// Mint new tokens (only treasury cap owner)
public fun mint(
treasury: &mut TreasuryCap<MOVE_TOKEN>,
amount: u64,
recipient: address,
ctx: &mut TxContext
) {
let coin = coin::mint(treasury, amount, ctx);
transfer::public_transfer(coin, recipient);
}
/// Transfer is trivial - just move the object
public fun transfer_token(token: Coin<MOVE_TOKEN>, recipient: address) {
transfer::public_transfer(token, recipient);
// token is moved - cannot be double-spent
// recipient MUST be a valid address (enforced by runtime)
// zero-value coins can be configured to be rejected
}
/// Split tokens for partial transfer
public fun transfer_partial(
token: &mut Coin<MOVE_TOKEN>,
amount: u64,
recipient: address,
ctx: &mut TxContext
) {
let split_coin = coin::split(token, amount, ctx);
transfer::public_transfer(split_coin, recipient);
}
}
NFT Minting
Solidity (ERC-721 style):
// Solidity: Multiple vulnerabilities possible
contract SolidityNFT is ERC721 {
uint256 private _tokenIdCounter;
mapping(uint256 => string) private _tokenURIs;
function mint(address to, string memory uri) external returns (uint256) {
// DANGER: No access control - anyone can mint!
// DANGER: Reentrancy via onERC721Received
// DANGER: Integer overflow in older versions
uint256 tokenId = _tokenIdCounter++;
_safeMint(to, tokenId); // Calls external contract!
_tokenURIs[tokenId] = uri;
return tokenId;
}
// Must manually implement:
// - Access control (Ownable, roles)
// - Reentrancy protection
// - Input validation
// - Enumeration (optional extension)
}
Move (Sui NFT style):
module example::move_nft {
use std::string::String;
use sui::object::{Self, UID};
use sui::transfer;
use sui::tx_context::TxContext;
/// NFT is a first-class object - cannot be duplicated
struct NFT has key, store {
id: UID,
name: String,
description: String,
uri: String,
}
/// Mint capability - only holder can mint
struct MintCap has key, store {
id: UID,
}
/// Initialize - MintCap goes to deployer
fun init(ctx: &mut TxContext) {
let mint_cap = MintCap { id: object::new(ctx) };
transfer::transfer(mint_cap, tx_context::sender(ctx));
}
/// Mint - requires MintCap ownership (enforced by type system)
public fun mint(
_cap: &MintCap, // Proves authorization
name: String,
description: String,
uri: String,
recipient: address,
ctx: &mut TxContext
) {
let nft = NFT {
id: object::new(ctx),
name,
description,
uri,
};
transfer::public_transfer(nft, recipient);
// No reentrancy possible
// No duplicate IDs possible (object::new guarantees uniqueness)
// Access control enforced by requiring MintCap
}
}
Access Control Patterns
Solidity:
// Solidity: Manual access control
contract SolidityAccessControl {
mapping(bytes32 => mapping(address => bool)) private _roles;
bytes32 public constant ADMIN_ROLE = keccak256("ADMIN");
bytes32 public constant MINTER_ROLE = keccak256("MINTER");
modifier onlyRole(bytes32 role) {
require(_roles[role][msg.sender], "Access denied");
_;
}
function grantRole(bytes32 role, address account) external onlyRole(ADMIN_ROLE) {
_roles[role][account] = true;
// DANGER: Centralized admin can grant any role
// DANGER: No role hierarchy enforcement
// DANGER: Roles are just mappings - can be manipulated if logic is wrong
}
function sensitiveAction() external onlyRole(MINTER_ROLE) {
// DANGER: Forgot modifier = public function
}
}
Move:
module example::move_access_control {
use sui::object::{Self, UID};
use sui::transfer;
use sui::tx_context::TxContext;
/// Capabilities are objects - possession = authorization
struct AdminCap has key, store {
id: UID
}
struct MinterCap has key, store {
id: UID
}
/// Only AdminCap holder can create MinterCaps
public fun grant_minter(
_admin: &AdminCap, // Must own AdminCap to call
recipient: address,
ctx: &mut TxContext
) {
let minter_cap = MinterCap { id: object::new(ctx) };
transfer::transfer(minter_cap, recipient);
}
/// Sensitive action requires capability
public fun sensitive_action(_minter: &MinterCap) {
// If you can call this, you MUST have a MinterCap
// No modifier to forget - it's a required parameter
// Compiler error if you try to call without it
}
/// Revoke = destroy or transfer away the capability
public fun revoke_minter(cap: MinterCap) {
let MinterCap { id } = cap;
object::delete(id);
// Capability destroyed - no longer exists
}
}
The Abilities System: copy, drop, store, key
Move's abilities system is central to its security model. Every type must declare its abilities explicitly:
| Ability | Meaning | Default |
|---------|---------|---------|
| copy | Can be duplicated | No |
| drop | Can be implicitly discarded | No |
| store | Can be stored in global storage | No |
| key | Can be used as a key in global storage | No |
module example::abilities {
// A fungible balance - can be copied and dropped
struct Point has copy, drop {
x: u64,
y: u64
}
// A unique asset - cannot be copied or dropped
// Must be explicitly transferred or destroyed
struct UniqueAsset has key, store {
id: UID,
value: u64
}
// A non-transferable badge - has key but not store
struct SoulboundBadge has key {
id: UID,
achievement: String
}
public fun example() {
let point = Point { x: 1, y: 2 };
let point_copy = point; // OK - has copy
let _ = point; // OK - has drop, can ignore
// let asset = UniqueAsset { ... };
// let asset_copy = asset; // COMPILER ERROR - no copy
// Drop asset silently? // COMPILER ERROR - no drop
}
}
Why this matters for security:
- Tokens can't have
copy: Prevents duplication - Critical assets can't have
drop: Forces explicit handling - Soulbound tokens:
keywithoutstore= non-transferable
The Move Prover: Formal Verification for the Masses
While formal verification has existed for decades, Move makes it practical for everyday smart contract development:
module example::formally_verified {
const MAX_SUPPLY: u64 = 1_000_000_000;
struct Treasury has key {
id: UID,
total_minted: u64,
total_burned: u64
}
public fun mint(treasury: &mut Treasury, amount: u64): u64 {
let new_total = treasury.total_minted + amount;
assert!(new_total <= MAX_SUPPLY, ETooManyTokens);
treasury.total_minted = new_total;
amount
}
spec mint {
// Preconditions
requires treasury.total_minted + amount <= MAX_SUPPLY;
// Postconditions
ensures treasury.total_minted == old(treasury.total_minted) + amount;
ensures result == amount;
// Invariant: total_minted never exceeds MAX_SUPPLY
invariant treasury.total_minted <= MAX_SUPPLY;
// Abort conditions
aborts_if treasury.total_minted + amount > MAX_SUPPLY;
}
spec module {
// Global invariant: conservation of tokens
invariant forall t: Treasury:
t.total_minted >= t.total_burned;
}
}
Trade-Offs: What Solidity Does Better
In the interest of a fair comparison, let's acknowledge Solidity's advantages:
1. Ecosystem Maturity
- Tooling: Hardhat, Foundry, Remix—battle-tested development tools
- Libraries: OpenZeppelin provides audited, reusable contracts
- Talent: Larger pool of experienced developers
- Documentation: Extensive tutorials, courses, and resources
2. Flexibility
- Dynamic patterns: Proxy upgrades, factory contracts, diamond patterns
- Interoperability: Easy interaction with any deployed contract
- Meta-transactions: Gasless transactions, relayers
3. DeFi Composability
- Flash loans: Enabled by Solidity's call semantics
- MEV: Complex arbitrage strategies (though this is debatable as a "feature")
- Existing liquidity: Billions in deployed capital
4. Learning Curve
- JavaScript similarity: Easier for web developers
- Immediate productivity: Simpler to write "hello world"
Why Kairo Chose Move/Sui for Policy Enforcement
At Kairo, we build security infrastructure that protects users from malicious transactions. Our choice of Move and Sui wasn't arbitrary—it was driven by security requirements that align perfectly with Move's design philosophy.
Policy Objects as True Resources
In Kairo, security policies are first-class objects:
module kairo::policy {
/// A policy is a resource - it cannot be duplicated or destroyed arbitrarily
struct Policy has key, store {
id: UID,
owner: address,
rules: vector<Rule>,
active: bool
}
/// Rules are verified at the type level
struct Rule has store, copy, drop {
rule_type: u8,
parameters: vector<u8>
}
/// Policy evaluation is deterministic and verifiable
public fun evaluate(
policy: &Policy,
transaction: &TransactionData
): bool {
// Type system guarantees:
// 1. Policy exists and is valid
// 2. Transaction data is well-formed
// 3. Result cannot be manipulated
let dominated = true;
let i = 0;
while (i < vector::length(&policy.rules)) {
let rule = vector::borrow(&policy.rules, i);
if (!check_rule(rule, transaction)) {
evaluated = false;
break
};
i = i + 1;
};
evaluated
}
}
No Unexpected State Mutations
Because Move has no dynamic dispatch, we can guarantee that:
- Policy evaluation cannot be interrupted or manipulated
- No external code can modify policy state during execution
- Results are deterministic and reproducible
Verifiable Security Guarantees
Using the Move Prover, we formally verify critical properties:
spec module {
// A policy, once created, cannot change ownership unexpectedly
invariant forall p: Policy:
p.owner == old(p.owner) || authorized_transfer_occurred();
// Policy rules are immutable after creation
invariant forall p: Policy:
p.rules == old(p.rules);
// Active policies always return consistent results
invariant forall p: Policy, t: TransactionData:
p.active ==> (evaluate(p, t) == evaluate(p, t));
}
This level of formal verification would be extremely difficult to achieve in Solidity, where dynamic dispatch and storage manipulation create complex state spaces.
The Future: Will Move Replace Solidity?
The honest answer: probably not entirely, but Move will capture significant market share, especially in security-critical applications.
Move Will Dominate In:
- High-value DeFi: Where security is paramount
- Gaming/NFTs: Where asset scarcity must be guaranteed
- Enterprise: Where formal verification is required
- Regulated finance: Where auditability matters
Solidity Will Persist In:
- Existing ecosystems: Ethereum's network effects are powerful
- Experimental DeFi: Where flexibility trumps safety
- Rapid prototyping: Where time-to-market is critical
The Convergence
We're already seeing Solidity adopt Move-like features:
- Transient storage (EIP-1153): Reduces reentrancy risk
- Account abstraction (EIP-4337): Better resource management
- Solidity 0.8+ defaults: Overflow protection
And Move is gaining Solidity's strengths:
- Better tooling: Sui Explorer, Move Analyzer
- Growing ecosystem: More libraries and frameworks
- DeFi primitives: Flash loans implemented safely
FAQ: Move vs Solidity Security
Is Move completely immune to hacks?
No programming language is immune to all vulnerabilities. Move eliminates certain categories (reentrancy, overflow, resource duplication) but logic errors, oracle manipulation, and economic exploits are still possible. Move makes accidental vulnerabilities much harder to introduce.
Can I port my Solidity contracts to Move?
Not directly—Move's programming model is fundamentally different. You'll need to redesign your contracts to use resources and capabilities. However, the result will likely be more secure and maintainable.
Is Move harder to learn than Solidity?
Move has a steeper initial learning curve due to its resource-oriented model and linear types. However, many developers find that once they "get it," Move code is more intuitive and less error-prone.
What about gas costs?
Move (on Sui) uses a different execution model with object-based storage. In many cases, Move contracts are more gas-efficient because they don't require expensive safety checks at runtime—the compiler enforces safety at compile time.
Does Move support upgradeable contracts?
Yes, through package upgrades on Sui. The upgrade system is designed with security in mind—you can't arbitrarily change storage layouts or break existing interfaces.
How does Move handle oracles and external data?
Move contracts can interact with oracle modules, but the design is different from Solidity. Oracle data is typically stored in shared objects that contracts read, rather than making external calls during execution.
Conclusion
The comparison of Move vs Solidity security reveals a fundamental truth: security is not just about careful coding—it's about language design. Move's resource-oriented programming, linear types, static dispatch, and formal verification capabilities represent a generational leap in smart contract security.
This doesn't mean Solidity is "bad" or that all Solidity developers should immediately switch. Solidity has a mature ecosystem, extensive tooling, and billions of dollars in deployed value. But for new projects, especially those handling significant value or requiring strong security guarantees, Move offers compelling advantages.
At Kairo, we chose Move and Sui because our mission—protecting users from malicious transactions—demands the highest level of security assurance. When you're building infrastructure that people trust with their assets, "good enough" isn't good enough.
The future of smart contract development isn't about choosing sides. It's about choosing the right tool for the job. For security-critical applications, that tool is increasingly Move.
Kairo Guard is a smart contract security extension that protects your crypto assets through policy-based transaction verification. Built on Sui with Move, Kairo provides the security guarantees that modern DeFi demands. Learn more about how Kairo keeps you safe.
Ready to secure your crypto?
Kairo Guard brings 2PC-MPC security and policy-gated transactions to your existing wallet. No seed phrases, no single points of failure.
Get Early Access