Sui Move Tutorial: Master the Object Model From Scratch

• Sui Move treats every digital asset as a unique object with its own global ID — not a balance in an account.
• The four core abilities — key, store, drop, and copy — control exactly what each object can do on-chain.
• Objects can be owned, shared, or frozen, giving developers fine-grained control over who can touch an asset and when.
• This object-centric design is why Sui can process transactions in parallel, reaching speeds up to 297,000 TPS in testing.
• If you already understand Chialisp puzzles and coins, Sui Move’s mental model maps closely — both languages treat assets as programmable, self-contained units.

Sui Move is a version of the Move programming language built specifically for the Sui blockchain. It replaces the traditional account-balance model with an object model where every asset — a token, an NFT, a game item — is its own on-chain object with a unique ID, a type, and clear ownership rules. This tutorial walks you through the core concepts so you can start building on Sui with confidence.

What Is Sui Move and Why Does It Matter?

Most blockchains keep a global ledger of accounts and balances. When you send a token on Ethereum, the chain updates two account balances. Sui does something different. Every asset lives as its own object — an independent piece of on-chain data with its own ID, its own type, and its own owner. When a transaction runs, it takes specific objects as input and produces new or mutated objects as output.

This is not just a cosmetic difference. Because objects are independent, transactions that touch different objects can run at the same time. There is no need to wait for a global state update. That is the engine behind Sui’s high throughput, and it is baked directly into the language design of Sui Move.

Move itself was originally created for Meta’s Diem blockchain project. Mysten Labs — the team behind Sui — took the core language and extended it with their own object system and storage model. The result is a version of Move that is more opinionated and more powerful for managing digital assets than the original specification.

How Sui Move Compares to Account-Based Blockchains

On Ethereum, when you write a smart contract for an NFT, the contract holds a mapping of token IDs to addresses. The NFT does not exist on its own; it is an entry in a contract’s storage. On Sui, the NFT is a first-class object. It has its own address on-chain, its own fields, and can even own other objects inside it. Transferring that NFT is an explicit, atomic operation — no reentrancy risk, no complex contract calls.

On Algorand, assets are controlled through a stateless execution model using TEAL. On Chia Network, every coin is a puzzle — a small program that defines the rules for spending it. Sui Move sits in interesting company here. Like Chialisp puzzles, Move objects carry their own logic and rules. The difference is that Move objects are typed, mutable, and can own other objects — a richer composition model than Chia’s coin-as-puzzle approach. If you have worked through Chialisp’s puzzle and solution model, you already think in the right direction for Move — assets are programs, not just numbers.

Core Concepts Every Sui Move Tutorial Must Cover

Before you write a single line of code, you need four concepts locked in. These are not optional background reading — they determine how your code compiles, how your objects behave on-chain, and what errors you will hit when something goes wrong.

Objects and UIDs

In Sui Move, an object is a Move struct that has the key ability and contains a field named id of type UID as its very first field. The UID is a globally unique identifier generated by the runtime when the object is created. No two objects on the entire Sui network share a UID. This is the foundation of the whole model — every asset is addressable, traceable, and distinct.

Think of a UID the way you think of a coin’s puzzle hash in Chialisp — it uniquely identifies this specific on-chain entity. But unlike a puzzle hash, a UID does not encode spending rules. The rules live in the module’s functions. The UID is just the address.

module my_package::badge {
    use sui::object::{Self, UID};
    use sui::tx_context::TxContext;

    public struct Badge has key {
        id: UID,
        level: u64,
    }

    public fun create(level: u64, ctx: &mut TxContext): Badge {
        Badge {
            id: object::new(ctx),
            level,
        }
    }
}

The call to object::new(ctx) is what mints the UID. You cannot create a UID any other way. The TxContext parameter carries transaction-scoped data — including the sender’s address — and the runtime uses it to guarantee the new ID is unique across the entire network.

The Four Abilities

Move uses a capability system called abilities to control what operations are legal on a given type. There are four abilities, and understanding them is the key to reading any Move code you encounter.

key marks a struct as a Sui object — it can be stored at the top level of global storage and must have a UID field. Any struct you want to live on-chain as a standalone object needs this. store means the struct can be nested inside another object. If key is the rule for top-level objects, store is the rule for everything that can live inside them. drop allows a value to be discarded when it goes out of scope — useful for temporary, throwaway data. copy allows a value to be duplicated. Most objects that represent real assets will deliberately omit copy and drop to enforce scarcity — the same principle behind Chialisp’s rule that a coin’s value cannot be created from thin air.

Ownership: Owned, Shared, and Frozen Objects

Every Sui object has an ownership state. An owned object belongs to a single address. Only that address can use the object as a transaction input. This is the default state when you transfer an object to a user’s wallet — private, controlled, fast to process because Sui does not need network-wide consensus to touch it.

A shared object is accessible by any address. This is what you use for a DEX liquidity pool, a marketplace listing, or any contract state that multiple users need to modify. Shared objects require the full consensus process because multiple transactions might try to touch the same shared object at once. They are more flexible but more expensive in gas terms.

A frozen object is immutable — no one can modify it after it is frozen. This is the right choice for on-chain constants, published metadata, or reference data that should never change. Move packages (the compiled modules you publish) are automatically frozen after publishing, which is why you cannot patch a bug in a deployed package — you have to publish a new version.

The init Function

The init function is a special function in a Move module that runs exactly once — when the package is first published to the network. It is the right place to set up any one-time state: minting an admin capability object, creating a shared registry, establishing module-level configuration. If your module needs an init, it must follow a strict signature: it receives only a TxContext argument (and optionally a one-time witness type as its first argument) and returns nothing. The runtime enforces this. You cannot call init again after deployment, which makes it a reliable bootstrapping mechanism.

Setting Up Your Sui Move Tutorial Environment

Before you can run a sui move tutorial example on your own machine, you need three things installed and configured: the Sui CLI, a code editor with Move support, and access to a test network for deployment.

Install the Sui CLI

The Sui CLI is your primary tool for building, testing, and publishing Move packages. The official installation guide at docs.sui.io covers installation for macOS, Linux, and Windows and is the most reliable source since install paths change across versions. After installation, run sui --version to confirm. Then run sui client active-env to see which network environment is active — devnet is fine for learning.

Configure Your Editor

Visual Studio Code with the Move extension gives you syntax highlighting, inline error checking, and auto-complete for Sui framework types. Search the VS Code marketplace for “Move” by Mysten Labs (the Sui extension). Once installed, open any .move file and the extension will wire itself to the Sui CLI automatically if it is in your PATH.

Create Your First Package

Run sui move new my_project in your terminal. This creates a folder with two things: a Move.toml file that declares your package name, version, and dependencies, and a sources/ folder where your .move files live. The Move.toml is the equivalent of a package.json in JavaScript or a Cargo.toml in Rust — it is how the compiler knows what version of the Sui framework to use. You will see a [dependencies] section that points to the Sui framework at a specific git commit. Do not change this unless you know you need a different framework version.

Writing Your First Sui Move Module

With your environment ready, here is a complete working module that creates a simple on-chain item, transfers it to the transaction sender, and includes a function to read its fields. This is the pattern you will use for almost every object-based application on Sui.

module my_project::item {
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};
    use sui::transfer;

    /// A simple on-chain item owned by a single address.
    public struct Item has key, store {
        id: UID,
        name: vector<u8>,
        power: u64,
    }

    /// Create a new Item and transfer it to the transaction sender.
    public entry fun mint(name: vector<u8>, power: u64, ctx: &mut TxContext) {
        let item = Item {
            id: object::new(ctx),
            name,
            power,
        };
        transfer::transfer(item, tx_context::sender(ctx));
    }

    /// Read the power level of an Item.
    public fun get_power(item: &Item): u64 {
        item.power
    }
}

Walk through what is happening line by line. The module declaration names this code my_project::item — the package name comes first, then the module name. The use statements import types from the Sui framework. The struct Item has both key and store — key so it can live as a standalone on-chain object, and store so it could later be nested inside another object if needed.

The entry keyword on mint is important — it marks this function as directly callable from a transaction. Without entry, external transactions cannot call the function directly (though other Move code can). The function creates the Item, gives it a fresh UID, and transfers it to whoever signed the transaction using tx_context::sender(ctx). At this point the object is an owned object in that wallet — private, fast to use, and inaccessible to anyone else unless transferred.

Build, Test, and Deploy

Run sui move build from your project root. If the code compiles without errors, you are ready to test. Run sui move test to execute any unit tests in your sources/ folder. Writing tests in Move is straightforward — you use the #[test] attribute above a function and the test_scenario framework to simulate transactions. Once your tests pass, deploy to Devnet with sui client publish --gas-budget 50000000. You will need a small amount of test SUI from the Devnet faucet for gas — the CLI output after publishing will give you the package’s on-chain ID.

Sui Move Tutorial: The Object Ownership Deep Dive

Ownership is where most beginners hit their first confusing error. The compiler enforces ownership rules at compile time, not runtime — if you try to use an object after transferring it away, your code will not compile. This is by design. Move’s type system is built on linear logic: every value must be used exactly once. You cannot duplicate an object (unless it has copy). You cannot drop it silently (unless it has drop). You must explicitly transfer it, consume it in a function, or wrap it inside another object.

This linear ownership model is what makes Move secure by default. There is no way to accidentally send the same token twice. The compiler catches double-spend attempts before they ever reach the network. Compare this to Solidity, where reentrancy attacks are possible because the language does not enforce consumption — a contract can call back into itself before its state updates, draining funds. In Sui Move, once an object is passed to a function, the caller no longer holds it. The object has moved.

“The most successful projects on Sui are not clones of existing DeFi protocols. They are native products that cannot be built elsewhere.”— Evan Cheng, Co-founder & CEO of Mysten Labs, CoinDesk, December 2024^[1]

This quote points at something deeper than marketing. Sui’s object model is genuinely different enough that building with it — not fighting it — produces applications that are structurally impossible on account-based chains. Gaming inventories where items own items. Composable DeFi positions. True digital ownership without wrapper contracts. These are not harder to build on Sui — they are easier, because the language was designed around them.

Case Study: Sui’s Object Model in Practice

Mysten Labs’ own Sui Kiosk standard demonstrates the power of nested objects at scale — a Kiosk is an owned object that can contain other objects, enforce royalties, and gate transfers through policy objects, all without a central contract managing state.^[2] By the close of 2024, Sui’s total value locked had grown from roughly $200 million to over $1.5 billion, driven partly by applications that could only exist with object-native composability.^[1]

Sui Move vs. Aptos Move: Key Differences for This Tutorial

Both Sui and Aptos use Move, but they diverged significantly after Diem’s dissolution. Aptos Move uses a resource-centric model built around account storage — resources live inside accounts, and functions operate on those account-scoped resources. Sui Move replaces account storage entirely with the object model. There is no “resource inside an account” on Sui — there are only objects, and each object knows its own owner.

This matters for developers choosing between the two ecosystems. Aptos’s model is closer to the original Diem design and may feel more familiar to developers coming from resource-oriented systems. Sui’s model requires a mental shift but pays off in composability and parallel execution. For the ChiaTribe audience coming from Chialisp — where every coin is already an independent unit with its own rules — Sui Move’s object model will feel more natural than Aptos Move’s account-centric approach.

Conclusion

The Sui Move object model is not just a technical detail — it is the design principle that makes Sui applications behave differently from anything built on Ethereum or Aptos. Once you internalize that every asset is an independent object with a unique ID, clear ownership, and explicit transfer rules, the rest of the language falls into place. Start with the four abilities. Understand owned versus shared objects. Write a simple mint function, build it, test it, and deploy to Devnet. The best way to understand this sui move tutorial is to run the code yourself, watch the object appear in your wallet, and transfer it to another address. That hands-on loop — create, transfer, query — is how the model becomes intuitive. From there, you are ready to explore dynamic fields, nested objects, and Sui’s coin and NFT standards. The primitives you learned here apply to all of it.

sui move tutorial FAQs

What is the difference between a Sui Move tutorial and a regular Move tutorial?

A Sui Move tutorial covers the object-centric storage model that is unique to Sui — including UIDs, ownership types, and the transfer module — which do not exist in standard Move implementations like Aptos Move. Standard Move tutorials focus on resource accounts and module-level storage, while Sui Move replaces those concepts entirely with independently owned objects.

Do I need SUI tokens to follow a sui move tutorial on Devnet?

You need a small amount of test SUI for gas fees when publishing packages, but Devnet and Testnet both have faucets that provide free test tokens. You can request test SUI from the Sui Discord faucet channel or directly through the CLI with sui client faucet once your environment is configured.

What does the key ability do in Sui Move?

The key ability marks a struct as a Sui object that can be stored at the top level of on-chain global storage. Any struct with key must include a field id: UID as its first field, which gives the object a globally unique identifier. Without key, a struct is an ordinary Move value and cannot exist as a standalone on-chain object.

How does Sui Move prevent reentrancy attacks?

Sui Move prevents reentrancy at the language level through linear ownership — when an object is passed into a function, the caller no longer holds it, making it impossible to call back in and use the same object twice in one transaction. Because transfers are atomic and ownership is exclusive, the class of bugs that causes reentrancy on Ethereum simply cannot be expressed in valid Move code.

Is a sui move tutorial relevant if I already know Chialisp?

Yes — the mental models are closer than they appear. Both Chialisp and Sui Move treat assets as self-contained programmable units (puzzles vs. objects) with explicit rules for transfer and consumption. The key expansion in Sui Move is typed, mutable objects that can own other objects and be composed in ways that Chia’s coin-based model does not support natively.

sui move tutorial Citations

1. CoinDesk — Evan Cheng: The Architect of Sui’s Object-Oriented Revolution (December 2024)
2. Sui Documentation — Move Concepts
3. Sui Documentation — Object Model
4. The Move Book — Object Model
5. Sui Foundation — Sui Move Intro Course (GitHub)
6. CoinTelegraph Research — Exploring Sui’s Object-Centric Model and the Move Programming Language (June 2024)
7. Supra Academy — The Ultimate Guide to the Move Programming Language (2025)
8. Sui Blog — Move 2024 Migration Guide