Auditing Move Contracts: A Comprehensive Guide

I reached out to experienced Solidity auditors and Move developers with a simple question: What should auditors know about Move? Here is the Answer.

Why this matters to you

For Solidity auditors, it’s a goldmine due to the lack of experts and the rapid growth of ecosystems like Sui and Aptos and multiVm’s . Move’s resource-oriented programming reduces common vulnerabilities but introduces new challenges.

What to Expect

This article provides a foundational guide to auditing Move-based smart contracts, specifically tailored for Aptos. Whether you’re a developer, auditor, or blockchain enthusiast, you’ll find:

How Move auditing differs from Solidity auditing.
Why audits are critical even in a "safe-by-design" language.
Common vulnerabilities in Move codebases.
Tools and resources to kickstart your Move auditing journey.

Why Move’s Design Matters for Auditing

Move’s architecture introduces security properties that differ notably from Solidity:

Arithmetic and Precision: Arithmetic operations (such as overflow/underflow) are checked during VM execution, and division is integer-based (e.g., 10/3 gives 3), which is important to understand when auditing numeric logic.
Control Flow & Access: Function visibility (private, public(friend), and entry) and access control mechanisms in Move are stricter and more explicit than in Solidity.
Resource Safety: Digital assets in Move are modeled as resources that cannot be copied or dropped arbitrarily. This “linearity” guarantees that tokens or critical data are never duplicated or accidentally destroyed.
Built-in Verification: The Move Virtual Machine (VM) performs bytecode verification to enforce memory safety and type safety before execution.
Static Call Semantics: Unlike Solidity, Move does not support dynamic dispatch or fallback functions. Reentrancy attacks are impossible by design.

and you can read more about what make move secure here :

https://pontem.network/posts/what-makes-move-safe

If Move Is Secure, Why Do We Need to Audit the Protocol and Why Do We Need Auditors?

Even though Move is designed for safety:

Human Error & Business Logic: No language is immune to mistakes. Developers can still write flawed business logic or misconfigure permissions.
Implementation Vulnerabilities: The VM or its verifier may harbor subtle bugs. For instance, past vulnerabilities in the Move bytecode verifier on Aptos highlight that even “secure-by-design” systems need independent review.
Language Novelty: Move is relatively new, and developers might misuse built-in functions, leading to bugs. You can check previous audit reports (e.g., OtterSec) for examples.

Move vs. Solidity Auditing: Key Differences

Eliminated Solidity-Specific Risks

Reentrancy: Impossible due to static calls and the absence of fallback functions.

Overflow/Underflow: Caught by the MoveVM during execution.

fun overflow(): u8 {
   let num: u8 = 255;
   num = num + 1;
   return num // Arithmetic error caught by the VM execution
}

Unchecked External Calls: Move has no equivalent to Solidity's delegatecall.

Shared Risks

Access Control: Misconfigured permissions can expose sensitive operations.

Integer Division: Incorrect calculations can occur. Use the bigDecimals module for precise calculations.

public fun division_precision() {
    let amount = 10 / 3;
    debug::print<u8>(&amount); // Outputs 3 instead of 3.3333
}

Denial-of-Service (DoS): Infinite loops or excessive gas consumption can occur (Aptos uses gas similarly to Ethereum).

Oracle Manipulation: Reliance on external data remains a risk.

Is Rust Required?

No! Move is a separate language with syntax inspired by Rust, but auditing focuses on Move itself. Rust knowledge may help with deeper VM insights but isn’t mandatory.

Learning Resources

Audit Reports: Analyze findings from OtterSec and Halborn.
Move Audit Resources: A curated collection of the best resources for Move auditing 0xriazaka’s GitHub.
Monethic Articles: Deep dives into Move security on Medium.

ChaosSR