Defining an Object in Sui Move vs a Resource in Aptos Move

17 October 2026

An Object in Sui Move and a Resource in Aptos Move are both ways to represent unique, owned digital assets on their respective blockchains, but they differ fundamentally in how they are stored, accessed, and transferred. In Sui, an Object is a standalone entity with a globally unique ID, stored in the Sui object store, and moved by value. In Aptos, a Resource is a data structure stored under a specific account address, accessed via the account’s storage, and moved by reference or by consuming the resource.

How sui objects work

Sui Move treats everything as an object. An object is a package of data with a unique 32-byte ID, a version number, and an owner. The owner can be an address, another object, or the shared/public store. Objects are stored in Sui's global object store, not inside an account's storage.

Key characteristics: - Objects are created with the move function or by transferring an existing object. - Each object has a single owner at any time (unless it is shared or immutable). - To use an object, you must pass it as an argument to a function. It is not looked up from storage by address. - Objects can be nested inside other objects using dynamic fields, but each object remains independently tracked.

Example pattern:

struct Collectible has key, store {
 id: UID,
 name: String,
 value: u64,
}

The key ability makes this a Sui object. The id field must be present and of type UID. The object is then transferred to an owner address or stored inside another object.

How aptos resources work

Aptos Move stores data as resources under an account. A resource is a struct with the key ability, but it is not identified by a global ID. Instead, it lives at a specific path under a specific account address. The account’s storage is a map from type to value; there can be at most one resource of a given type per account.

Key characteristics: - Resources are created and stored under an account using move_to. - They are accessed using borrow_global, borrow_global_mut, or move_from. - Resources are not passed by value between functions; they are read from or written to the account storage. - Moving a resource from one account to another requires moving it out of one account and into another, not transferring an object ID.

Example pattern:

struct Collectible has key {
 name: String,
 value: u64,
}

The key ability allows this struct to be stored as a resource under an account. There is no id field required. To create one, you call move_to(account, Collectible { ... }).

Core Differences

Identity and Ownership

In Sui, an object is identified by its unique ID. Ownership is a property of the object itself, tracked by the system. You can transfer an object by calling transfer or public_transfer. The object does not belong to an account in the Aptos sense; it is an independent entity.

In Aptos, a resource is identified by its type and the account it is stored under. Ownership is implicit: the account that holds the resource owns it. There is no global ID. To transfer, you must remove the resource from one account and place it into another.

Storage Model

Sui uses a global object store. Any object can be looked up by its ID, regardless of owner. This enables the parallel execution model: transactions that touch different objects can run simultaneously.

Aptos stores resources inside accounts. To find a resource, you need the account address and the resource type. This is a hierarchical storage model. Parallel execution on Aptos uses Block STM, which speculatively executes transactions and resolves conflicts, rather than relying on object-level independence.

Passing and Access

In Sui, you pass objects as function arguments. If a function needs to read or modify an object, you must pass a reference or mutable reference to that object. The object is not looked up from storage inside the function.

In Aptos, functions typically use borrow_global or move_from to access resources by account address. The resource is not passed in; it is fetched from the caller’s or another account’s storage.

Nesting and Composition

Sui supports dynamic fields, which allow an object to hold a map of child objects keyed by any value. This is flexible but adds complexity. Objects can be nested arbitrarily, and each nested object retains its own ID.

Aptos does not have dynamic fields. You can nest structs inside a resource, but they are not independently addressable. To achieve composition, you typically use separate resources under the same account or different accounts.

When to use each

Use Sui objects when you need: - Fine-grained ownership and transfer of individual items. - Objects that can be passed directly between functions. - Complex nesting with dynamic fields.

Use Aptos resources when you need: - Data that is logically tied to a specific account. - Simple storage patterns with one resource type per account. - Compatibility with the Aptos account model and key rotation.

Practical example: A collectible

Sui version:

struct Collectible has key, store {
 id: UID,
 name: String,
 value: u64,
}

public entry fun mint(name: String, value: u64, ctx: &mut TxContext) {
 let collectible = Collectible {
 id: object::new(ctx),
 name,
 value,
 };
 transfer::transfer(collectible, tx_context::sender(ctx));
}

Aptos version:

struct Collectible has key {
 name: String,
 value: u64,
}

public entry fun mint(account: &signer, name: String, value: u64) {
 let collectible = Collectible { name, value };
 move_to(account, collectible);
}

In Sui, the function creates an object and transfers it to the sender. In Aptos, the function stores the resource under the signer's account.

Summary

Sui Objects are standalone, globally identified, and passed by value. Aptos Resources are account-local, type-identified, and accessed from storage. The choice between them depends on whether your application benefits from object-level independence and transfer or from account-bound storage and simpler key management.

Back to sui & aptos