<< All versions

Skill v1.0.0

currentAutomated scan100/100
mystenlabs/sui/move-bytecode-comprehension
──Details
PublishedOctober 24, 2026 at 08:52 AM
Content Hashsha256:9d42803f382ae1d8...
Git SHA108fad147d2f
──Files
Files (1 file, 3.7 KB)
SKILL.md3.7 KBactive
SKILL.md · 65 lines · 3.7 KB

version: "1.0.0" name: move-bytecode-comprehension description: > Use when reading or reasoning about compiled Move bytecode or sui move disassemble output. Mental model for the binary format, what survives compilation (and what's lost), and how to read disassembly soundly. Trigger on "what does this package do?", "read this .mv module", "interpret this disassembly", or whenever an analysis needs to interpret bytecode faithfully.


Move Bytecode Comprehension

Self-bootstrap: before relying on the routing below, load every reference file —
default to sui prompt skill move-bytecode-comprehension --all, or --list + `--file
<ref>` when budget is tight. This SKILL.md is the mental-model wrapper; reference files
cover the binary format and the practice of reading disassembly.

On-chain Sui packages are compiled Move bytecode (.mv, magic 0xA11CEB0B). For analysis you read it as disassembly (stack-machine, via sui move disassemble). This skill is the mental model for the binary format and for reading disassembly soundly.

The single most important fact when reading Move bytecode: abilities, visibility, the `entry` flag, signatures (incl. generics/phantom), and all on-chain identifiers — module/struct/field/function names — are preserved. What is lost is human intent metadata: constant/error names, #[error] messages, local variable names, comments, and macro structure. Tune reasoning accordingly.

What survives compilation — the survival table

Source constructIn bytecode?How it appears in disassemblyImplication
Module address + name✓module <addr>.<name>Identity is exact
Struct names✓struct Name ...Type-name reasoning is reliable
Field names + types✓listed on the structField-level reasoning holds
Abilities (key/store/copy/drop)✓has store, keyCapability / soulbound / hot-potato reasoning is reliable
Visibility (private/public/friend)✓keyword on fnCall-surface reasoning is reliable
`entry` flag✓entry keywordTx-entry reasoning is reliable
Function signatures✓full (Arg0: T, ...): RetParam/return reasoning holds
Generics + phantom type params✓<T> / phantomType-identity reasoning holds
Constant values✓LdConst[i](T: ...)Values readable, names are not
Constant / error names✗LdConst[i] index onlyUse abort *codes*/positions, not names
#[error] messages✗—Error intent lost; reason from the abort site
Local variable names✗loc0, Arg1, …Don't trust names; trust dataflow
Comments / doc✗—No author intent text
Macros (assert!, 1u8.do!)expandedinlined opcodes / branchesA macro looks like its expansion
Empty struct (e.g. OTW)✓ (as 1 field)dummy_field: boolOTW detect via name+`drop`+synthetic field

How to read

FileUse for
format.mdThe binary format: tables, abilities, visibility, signatures, opcode categories. Read once.
disassembly.mdReading the disassembly view: stack machine, basic blocks, locals, and the opcodes you'll actually see.

Practical stance

  • Disassembly is the view. Apply analyses to the .asm files produced by

sui-and-move-tools/fetch-and-disassemble.md. Abilities, visibility, the entry flag, signatures, struct/field shapes, control flow, and call patterns are all faithful.

  • Citation. Findings cite <module>.asm:B<block>@i<index> — the basic-block label

plus instruction index within the block.

  • Bytecode version is shown as // Move bytecode vN; note it — opcode availability

varies by version.

All versions