---
title: 'MoveScanner: Security Analysis for Move'
url: https://www.emergentmind.com/topics/movescanner
type: topic
---

# MoveScanner: Security Analysis for Move

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 [2508.17964].

## 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 [2205.05181]. 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 [2508.17964].

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 [2508.17964].

## 2. System architecture and design principles

MoveScanner uses a modular architecture with three main components: **Data Processing**, **Analysis Engine**, and **Result Output** [2508.17964]. 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 [2508.17964].

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 [2508.17964].

## 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 [2508.17964]. 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
$$
IN[B] = \bigcup_{P \in pred(B)} OUT[P], \quad OUT[B] = genB \cup (IN[B] - killB)
$$
and
$$
OUT[B] = \bigcup_{S \in succ(B)} IN[S], \quad IN[B] = useB \cup (OUT[B] - defB).
$$

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 [2508.17964].

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 [2508.17964].

## 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 [2508.17964]. 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 [2508.17964].

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 [2508.17964].

## 5. Empirical evaluation and quantitative findings

The paper reports benchmark, open-source, and production-scale evaluations [2508.17964]. 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%** [2508.17964].

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 [2508.17964].

## 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 [2508.17964].

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 [2205.05181], whereas MoveScanner targets a broader class of contract-security issues tied to resource handling, permissions, arithmetic, return-value usage, and inter-module composition [2508.17964]. 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** [2508.17964]. 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.

Source: https://www.emergentmind.com/topics/movescanner