Sui Execution Layer — A Security Researcher's Deep Dive

I spent weeks reading every file in sui-execution. Here's how Sui processes transactions under the hood — from raw bytes to final state changes — and what I learned about its security model along the way.

What Is the Execution Layer?

When you submit a transaction to Sui — transfer a coin, mint an NFT, call a Move function — something has to actually run it. That something is the execution layer. It sits between the Sui blockchain (consensus, storage, networking) and the Move VM (the bytecode engine).

The execution layer is NOT the Move VM. Most of the work — coin splits, merges, transfers, gas charging, type checking — happens in Rust inside sui-adapter. The Move VM only gets called when there's an actual MoveCall command that needs to execute Move bytecode.

The Three Modules

The execution layer lives in sui-execution/latest/ and has three main crates:

How a Transaction Flows Through sui-adapter

Every user transaction (a Programmable Transaction Block, or PTB) goes through a strict pipeline before any code runs. Here's the full flow:

Stage 1: Linkage

Sui packages get upgraded. When you call a function, the chain needs to figure out which exact version of every dependency to use. The linkage stage scans the transaction, finds every package referenced, and resolves version conflicts.

Two constraint types: exact (must be this version) and at_least (this version or newer). If a transaction needs the same package at two different exact versions, it fails before any code runs.

The result is a simple map: original_package_id → version_to_use. This gets passed to the Move VM so it loads the right code.

Stage 2: Loading

Takes the raw transaction bytes and converts them into structured Rust types. For each input object, it reads the object from storage and resolves its Move type. For each MoveCall, it looks up the function in the package bytecode and loads its full signature (parameter types, return types, visibility).

Pure bytes (numbers, addresses) stay as raw bytes at this stage — their type isn't known yet until a command uses them.

Stage 3: Typing

The type checker. It walks every command and asks: "do all the types match up?" If you pass a Coin<SUI> to a function expecting Coin<USDC>, it dies here.

It also decides how each value is used:

Pure inputs get their type here too. The first command that uses a pure input as u64 gives it that type.

Stage 4: Verification (5 Passes)

Before execution, the typed transaction goes through 5 safety checks:

Stage 5: Metering

Gas is charged at three checkpoints before execution even starts:

Stage 6: Execution

The interpreter loops through each PTB command and delegates to Context:

Values flow between commands through numbered slots. Command 0 produces Result(0,0), command 1 can reference it. Context manages these slots with move/copy/borrow semantics — same rules as Move itself.

Stage 7: Settlement

After all commands execute:

Package Caching: Three Layers

When the VM needs a package (e.g., the sui framework), it doesn't hit disk every time. Three cache layers, fastest to slowest:

The first transaction of an epoch is slower (cold cache). After that, frequently used packages like 0x2 (sui framework) are served from memory.

Execution Modes

Not all transactions are equal. Four security levels control what's allowed:

The Native Functions (sui-move-natives)

When Move code calls transfer::transfer(), it's not running Move bytecode — it crosses into Rust. The sui-move-natives crate implements every native function.

Core Operations

Crypto Primitives

14 crypto files covering every scheme Move contracts might need:

Every crypto native follows the same pattern: charge gas first (proportional to input size), parse inputs, call fastcrypto in Rust, return the result. Invalid inputs return false or error codes — never panic.

The ObjectRuntime

The most critical piece. Every object::new(), object::delete(), transfer::transfer(), and event emission lands in the ObjectRuntime. It's the in-memory ledger that tracks all state changes during a transaction. At the end, it produces RuntimeResults which become the final TransactionEffects.

The Sui Verifier (sui-verifier)

When you publish a Move package, 6 Sui-specific verification passes run on your bytecode:

All passes are time-budgeted via a meter. If verification takes too long (pathologically complex bytecode), the module is rejected with PROGRAM_TOO_COMPLEX.

What I Learned as a Security Researcher

After weeks in this codebase, here are the non-obvious things I took away:

Move is the interface, Rust is the engine. Most people think the Move VM runs everything. It doesn't. Coin operations, transfers, gas, type checking, verification — all Rust. The VM is one tool the adapter calls when needed.

The typing pipeline is where the real security lives. Five verification passes before any code runs. Two independent borrow checkers. Quadratic gas for references. Hot potato taint analysis. This is more verification than most L1s do during actual execution.

Versioned execution is real engineering. Sui doesn't update its VM — it freezes the old one and ships a new one next to it. Every old transaction replays with the exact code that originally ran it. A custom Rust CLI tool (cut) automates the snapshot-and-rewire process.

Gas is charged before work happens. Three metering checkpoints before execution. Per-instruction metering during execution. Conservation checks after. The gas model is designed so attackers can't get meaningful free compute.

debug_assert-only invariants are real attack surface. Several critical checks in ObjectRuntime::finish() use debug_assert! which are no-ops in release builds. If an invariant is violated in production, execution proceeds silently. Worth auditing.

The deny list only checks top-level coin types. If you wrap a regulated coin inside another struct, the deny list doesn't see it. This is a design limitation, not necessarily a bug — but protocol builders relying on the deny list should be aware.

Related Posts

Sui Bella Ciao — Inside the New Move VM — Deep dive into the VM rewrite itself.

Sui's Cut Package — How Sui Freezes Its Execution Layer — How versioned execution snapshots work.