MoveScanner: Security Analysis for Move
- MoveScanner is a static analysis tool for Move smart contracts that detects vulnerabilities such as resource leaks, weak permissions, arithmetic overflows, unchecked returns, and cross-module issues.
- It employs control flow and data flow analysis along with specialized techniques like resource trajectory tracking and capability matrix analysis to generate detailed, machine- and human-readable security reports.
- Empirical evaluations show 88.2% detection accuracy on benchmarks with many checks yielding zero false positives, making it a robust tool for multi-chain environments like Aptos and Sui.
Searching arXiv for MoveScanner and closely related Move-language security papers. MoveScanner is a static analysis tool for the automated security analysis of Move smart contracts. It is presented as a response to the fact that, although Move provides a resource-oriented programming model, a linear type system, and strong built-in protections for digital assets, smart contracts in the Move ecosystem still face security challenges arising from developer programming errors and cross-module interactions. The tool adopts a control flow graph and data flow analysis architecture, operates at the bytecode level, supports multi-chain adaptation, and is designed to identify five key types of security vulnerabilities, including resource leaks, weak permission management, and arithmetic overflows (Luo et al., 25 Aug 2025).
1. Move-language context and the problem MoveScanner addresses
Move is a language for programming digital assets via a mix of value semantics and reference semantics. Its safety base includes a load-time bytecode verification pass and a borrow checker formalized as a modular, intraprocedural static reference safety analysis. That analysis proves three properties for Move programs: absence of dangling references, referential transparency for immutable references, and absence of memory leaks (Blackshear et al., 2022). Within that setting, MoveScanner is framed as a distinct security-analysis layer aimed at risks that remain relevant in practice because of programmer mistakes and inter-contract behavior, especially in ecosystems such as Aptos and Sui (Luo et al., 25 Aug 2025).
The tool is motivated by a gap between language-level safety and contract-level security. The MoveScanner paper states that existing security tools in the Move ecosystem have significant limitations and that most prior tools focus only on intramodule analysis, simple code patterns, or require formal annotations. This suggests that the tool is intended not to replace the bytecode verifier, but to extend the security-analysis envelope toward resource-centric bugs, permission failures, arithmetic errors, unchecked return values, and cross-module state interactions that may arise in compiled contracts despite the language’s underlying safety model (Luo et al., 25 Aug 2025).
2. System architecture and design principles
MoveScanner uses a modular architecture with three main components: Data Processing, Analysis Engine, and Result Output (Luo et al., 25 Aug 2025). Data Processing converts Move bytecode into intermediate representations for subsequent analyses. Analysis Engine provides a unified infrastructure for control flow, data flow, cross-module, and specialized analyses, including resource tracking and capability tracking. Result Output emits human- and machine-readable security reports in text and JSON, with fine-grained vulnerability details.
Several architectural properties are emphasized. The tool works directly on bytecode and therefore does not require source code. It is described as chain-agnostic and source-invariant, and it is intended to support bytecode-level analysis and multi-chain adaptation. The modular structure is extensible: each vulnerability check is independent, but all checks share foundational analysis components. The implementation also includes a uniform intermediate representation layer, built after parsing, so that analyses can operate efficiently on module-, function-, and instruction-level abstractions independent of source-code complexities. Additional implementation notes include a visitor pattern for traversing modules and functions, along with a CLI that supports batch analysis, configurable checks, and flexible reporting (Luo et al., 25 Aug 2025).
This design has methodological consequences. Because the tool analyzes compiled bytecode rather than surface syntax, it targets a common substrate across Move deployments. A plausible implication is that the architecture is meant to reduce dependence on chain-specific source tooling and to make analyses portable across ecosystems such as Aptos, Sui, and Starcoin, which the paper explicitly names in its discussion of multi-chain support (Luo et al., 25 Aug 2025).
3. Static-analysis methodology
The core analytical framework combines control flow graph construction, data flow analysis, resource lifecycle reasoning, capability reasoning, and cross-module call graph tracking (Luo et al., 25 Aug 2025). Code bytes are transformed into a graph of basic blocks with explicit predecessor-successor relationships, and all branches, loops, and exception paths are represented. The paper states that the tool uses reaching definitions analysis and live variable analysis according to the standard equations
and
On top of these general data-flow mechanisms, MoveScanner introduces two specialized analyses. The first is resource trajectory tracking, which analyzes the lifecycle of Move resources across all paths and tracks creation, movement, and destruction. The stated aim is to identify anomalies such as resource leaks due to incomplete moves, especially within branches or early returns. The second is capability matrix analysis, which constructs global capability matrices recording access and privilege relationships, including which modules and functions can exercise which abilities. By tracing the flow of capability objects, the tool is designed to detect privilege escalation and capability leaks (Luo et al., 25 Aug 2025).
A further component is the cross-module call graph, which supports inter-module reasoning about security properties. The paper characterizes this as crucial for detecting vulnerabilities arising from complex contract interactions. This is also the basis for claims that MoveScanner improves over earlier Move tools on cross-module and resource-centric vulnerabilities. The paper identifies cross-module call analysis, resource trajectory tracking, and capability matrix analysis as the main algorithmic innovations, and it associates them with individual detection procedures for resource leaks, unchecked returns, arithmetic overflows, cross-module security problems, and capability leaks (Luo et al., 25 Aug 2025).
4. Vulnerability taxonomy and Move-specific risk model
MoveScanner is described as being able to comprehensively detect at least five major vulnerability types, with further granularity in reported results (Luo et al., 25 Aug 2025). The reported classes are summarized below.
| Vulnerability type | Detection basis | Reported effect |
|---|---|---|
| Resource leaks | Resource trajectory tracking across all paths | Finds incomplete moves and resource state anomalies |
| Weak/incorrect permission management | Capability matrix analysis | Detects capability leaks and privilege escalation |
| Arithmetic overflows | Checks arithmetic operations for missing guards | Covers add, sub, mul, div, mod and division by zero |
| Unchecked return values | Return-value processing analysis | Finds silent logic errors and undetected failures |
| Cross-module vulnerabilities | Global call-graph reasoning | Detects state pollution and unintended resource manipulation |
The paper’s descriptions are specific. Resource leaks are defined as failures to properly move or destroy resource objects, leading to assets becoming stuck, lost, or inconsistent. Weak/incorrect permission management includes capability leaks and cross-module state pollution, especially where privileged tokens are exposed to untrusted recipients or where one module can modify another module’s global state without proper access control. Arithmetic overflows cover missing boundary checks in addition, subtraction, multiplication, division, and modulus, including missed division-by-zero cases. Unchecked return values refer to ignored results from functions that signal success, failure, or status. Cross-module vulnerabilities are described as inter-module bugs where exposure or call chains allow state pollution, privilege escalation, or unintended resource manipulation (Luo et al., 25 Aug 2025).
Beyond those five major classes, the paper states that MoveScanner identifies twelve previously unreported security risks linked to Move’s resource-oriented paradigm and cross-module designs. The paper does not enumerate those twelve risks in the supplied summary, but it presents them as part of the tool’s broader contribution to a Move-specific security taxonomy. This suggests that the authors regard the resource-oriented programming paradigm not merely as a source of safety guarantees, but also as a source of distinctive failure modes that require dedicated analysis abstractions (Luo et al., 25 Aug 2025).
5. Empirical evaluation and quantitative findings
The paper reports benchmark, open-source, and production-scale evaluations (Luo et al., 25 Aug 2025). On a benchmark dataset of hand-constructed contracts with known vulnerabilities, MoveScanner achieved 88.2% detection accuracy. On that benchmark set, the reported false positive rate was 0%. The benchmark breakdown also gives per-category results: Resource Leak had a 50% detection rate with 0 false positives; Arithmetic Overflow had a 60% detection rate with 0 false positives; Capability Leak, Cross-Module Pollution, and Unchecked Return were all reported at 100% with 0 false positives.
On 137 modules from open-source projects, MoveScanner found 2,882 potential vulnerabilities. In a manual review of 50 sampled findings, the distribution was 82% true vulnerabilities, 16% possible, and 2% false positives. On a production dataset from the Aptos Mainnet, involving tens of thousands of deployed contracts, the paper reports the following distribution of findings: Arithmetic overflow: 61.3%, Cross-module state pollution: 18.5%, Capability (privilege) leakage: 10%, Unchecked return: 9.8%, and Resource leakage: 0.4% (Luo et al., 25 Aug 2025).
The evaluation also situates MoveScanner against prior tools. Compared with Move Prover, MoveCheck, and VerMove, the paper claims higher automation, no dependency on source or manual annotation, superior support for cross-module and resource-centric vulnerabilities, a 37% lower false positive rate than conventional frameworks, and average analysis time of < 70ms per module. It also states that the tool successfully analyzed thousands of contracts rapidly and that, despite Move’s safety advances, nearly 19.3% of real contracts have non-trivial security bugs due to subtleties in resource and permission models (Luo et al., 25 Aug 2025).
6. Place in the Move security ecosystem and prospective development
MoveScanner is presented as filling a tooling gap in the Move ecosystem. The paper argues that the Move ecosystem lagged the Ethereum ecosystem in mature analysis tooling and that most earlier tools were constrained by intramodule scope, limited vulnerability coverage, or dependence on formal specifications. In contrast, MoveScanner emphasizes automation, bytecode-level portability, configurability, and explicit support for cross-module reasoning and resource-centric analysis (Luo et al., 25 Aug 2025).
The tool’s relation to the Move language’s existing verification stack is best understood as complementary. The borrow checker formalizes memory safety for references and resources at the bytecode-verification stage (Blackshear et al., 2022), whereas MoveScanner targets a broader class of contract-security issues tied to resource handling, permissions, arithmetic, return-value usage, and inter-module composition (Luo et al., 25 Aug 2025). This suggests a layered model of assurance in which language-level bytecode safety is necessary but not sufficient for contract-security auditing in production deployments.
The paper closes by identifying a forward path rather than claiming closure. Future work is said to focus on combining formal verification and dynamic analysis to build a security protection framework covering the entire contract lifecycle (Luo et al., 25 Aug 2025). In that formulation, MoveScanner serves both as a concrete static-analysis system and as a proposal for how Move-specific security mechanisms may evolve: from isolated bytecode checks toward integrated, lifecycle-wide security analysis grounded in the resource-oriented semantics of the language.
