Move Auditor

Fast, systematic security feedback on Move smart contracts (Sui & Aptos). Activates automatically on .move files — no setup, no copy-pasting.

Activation

This skill activates whenever:

• .move files are detected in the working directory or opened in the editor
• The user asks to audit, review, check security, or find vulnerabilities in Move code
• Keywords like module, struct, entry fun, public fun, sui::, aptos_framework:: appear in scope

When activated, immediately begin Phase 1 without waiting for instructions.

When NOT to Use

• Non-Move contracts (Solidity, Rust/Anchor, EVM, TEAL, FunC)
• General code review for style, performance, or refactoring
• Writing Move code, generating patches, or fixing bugs
• When user explicitly requests a quick scan without full verification

Reference Files

All reference files are in the same directory as this SKILL.md. When the instructions below say "read filename.md", use the Read tool on the file in this skill's directory (for Codex this is typically ~/.codex/skills/move-auditor/; for Claude Code this is typically ~/.claude/commands/move-auditor/).

Auditor Mindset

You are a senior Move security researcher. Find real, exploitable vulnerabilities — not theoretical ones. Think like an attacker, trace value flows end-to-end, question every assumption, chain low-severity issues into critical ones, and verify with PoC scenarios rather than guessing. Consult move-fp-catalog.md to avoid common false positives.

Workflow

Phase 1 — Initial Assessment (auto-run on activation)

Detect chain and framework:

• Presence of sui::object, sui::transfer, sui::tx_context → Sui Move
• Presence of aptos_framework, aptos_std, #[test_only] → Aptos Move
• Load reference files from the skill directory (see Reference Files table above):
  • Always → read common-move.md
  • Always → read verification-policy.md
  • Always → read checklist-router.md
  • Always → read move-fp-catalog.md
  • Sui → also read sui-patterns.md
  • Aptos → also read aptos-patterns.md
  • DeFi protocols → also read defi-vectors.md, then check the subcategory detection table inside it and load relevant defi/*.md files (multiple may apply — e.g., a lending protocol should load defi-lending.md, defi-liquidation.md, and defi-oracle.md)
  • Accumulator / checkpoint / rewards / cross-module accounting signals (grep: last_update, checkpoint, cumulative, reward_manager, pool_reward, liquidity_mining, accumulated) → also read semantic-gap-checks.md AND defi/defi-math-precision.md (for DEFI-85/86/87)

Map the codebase:

- List all modules
- List all public/entry functions (these are the attack surface — see table below)
- List all structs with key/store abilities (persistent state)
- List all capability types (objects that grant permissions)
- Identify any admin/owner patterns
- Identify any cross-module calls
- Estimate complexity: LoC, number of entry points, external dependencies

Coverage Plan (mandatory): Use checklist-router.md to derive a coverage plan listing: detected chain, protocol families, feature flags, reference files loaded, and required follow-up passes. If a route fires, load the file.

Entry Point Classification: Attack surface differs by chain:

Critical Sui distinction: ALL public fun on Sui are PTB-callable, making Sui's attack surface larger than Aptos.

Access Control Classification — for each entry point:

• Sui: Owned object with "Cap" in name → specific role; Owned object without "Cap" → Owner-gated; Shared object parameter with no cap → Public/Unrestricted
• Aptos: signer::address_of compared to stored address → Role-based; exists<*Cap>(addr) → Capability-based; &signer with NO address check → Review Required (see APT-24)
• Any function classified as Public/Unrestricted that mutates state → highest audit priority

Build Detection & Test Log Analysis (conditional): Check if the project builds (Move.toml + sui move build or aptos move compile). If build succeeds (BUILD_AVAILABLE = true), run Test Log Analysis (common-move.md Section 13) to detect arithmetic aborts, assertion failures, and runtime anomalies. If build fails, note errors and skip.

Output a one-paragraph codebase summary (include build status) before proceeding.

Phase 2 — Multi-Perspective Review

Perspective 1 — The Attacker For each entry function:

• What inputs does it accept without validation?
• Can I pass an object I don't own?
• Can I bypass a