move-auditor

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/).

| File | When to load | |------|-------------| | common-move.md | Always — chain-agnostic checks (sections 1–10), verification checklist | | verification-policy.md | Always — evidence hierarchy, mock rejection rule, feasibility gates, severity discipline | | checklist-router.md | Always — deterministic coverage plan; maps detected protocol features to files and mandatory follow-up checks | | move-fp-catalog.md | Always — rationalizations to reject, Move FP catalog, self-hallucination check | | evidence-chains.md | Phase 7 — structured evidence templates for data flow, math proofs, PoC | | confidence-gates.md | Phase 7 — confidence gating, hard evidence requirements per finding type | | sui-patterns.md | When chain is Sui (imports sui::object, sui::transfer, etc.) — SUI-01 to SUI-44 | | aptos-patterns.md | When chain is Aptos (imports aptos_framework, aptos_std, etc.) — APT-01 to APT-25 | | defi-vectors.md | When protocol involves tokens, swaps, lending, staking, or oracles — DEFI-01 to DEFI-10 + subcategory router | | semantic-gap-checks.md | When the protocol has accumulators, checkpoints, rewards, lending state, cross-module accounting, or multi-step state transitions | | defi/defi-staking.md | When staking/yield detected (stake, unstake, reward_per_share, accumulator, last_index, reward_debt, last_reward_per_share) — DEFI-11 to DEFI-16, DEFI-88 | | defi/defi-oracle.md | When oracle usage detected (get_price, oracle, pyth, switchboard, price_feed) — DEFI-17 to DEFI-24 | | defi/defi-lending.md | When lending/borrowing detected (borrow, repay, collateral, health_factor) — DEFI-25 to DEFI-34, DEFI-80, DEFI-82, DEFI-84 | | defi/defi-math-precision.md | When complex financial math detected (PRECISION, DECIMAL, float, Decimal, WAD, fee/share math) OR when reward/accumulator/liquidity_mining patterns detected — DEFI-35 to DEFI-42, DEFI-85 to DEFI-87 | | defi/defi-slippage.md | When swap/DEX patterns detected (swap, min_amount_out, slippage, AMM pool) — DEFI-43 to DEFI-49 | | defi/defi-liquidation.md | When liquidation mechanisms detected (liquidat, seize, bad_debt, insurance) — DEFI-50 to DEFI-66, DEFI-81, DEFI-83 | | defi/defi-auction-clm.md | When auction or CLM patterns detected (bid, auction, TWAP, tick, concentrated) — DEFI-67 to DEFI-73 | | defi/defi-signatures.md | When signature verification detected (ed25519, secp256k1, verify_signature, nonce) — DEFI-74 to DEFI-79 | | defi/defi-lending-design-patterns.md | When lending/borrowing detected — known-good patterns (DESIGN-L1 to L4) that should NOT be reported as bugs | | audit-prompts.md | Optional — deep-dive prompts and Move vulnerability pattern pack | | sample-finding.md | Reference for output format — do not load during audits |

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:

| Visibility | Sui (PTB-callable?) | Aptos (tx entry?) | |------------|---------------------|-------------------| | public entry fun | Yes — PTB + direct tx | Yes — transaction entry | | public fun | Yes — PTB-callable! | No — module-callable only | | entry fun | Yes — direct tx only | Yes — transaction only | | public(package) fun | No — package-internal | No — package-internal | | fun (private) | No | No |

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