Sui object centric data model how it differs from global storage

02 September 2026

Sui does not store data the way most blockchains do. Instead of a global ledger where every piece of state lives under an account, Sui uses objects. Each object has a unique ID, a type, and an owner. This is the core idea behind the object-centric model, and it changes how transactions are validated and executed.

Aptos, by contrast, uses a global storage model inherited from Libra. Resources live under accounts in a tree-like structure. To read or modify something, the system must locate the account, then find the resource within that account’s subtree. Every transaction touches the global state, even if only one user’s balance changes, forcing a sequential ordering concern across all operations.

Sui defines three ownership types for objects. Owned objects belong to a single address; only that address can mutate them. Shared objects can be read and written by anyone, but they require consensus to order access. Immutable objects can never change. They are fixed data that anyone can read but nobody can modify.

The difference matters most for simple transfers. When you send an owned object from one address to another, Sui knows the object is private to those two parties. No other transaction can touch it. This means the network can process the transfer without waiting for global agreement. The validators check the sender’s signature and the object’s ownership, then update the object’s owner field. No consensus round is needed. This is how Sui achieves parallel execution for independent transactions.

Aptos handles the same scenario differently. A token transfer on Aptos modifies the sender’s balance resource and the receiver’s balance resource, both stored under their respective accounts. The Move VM must read from two account subtrees and write to both. The system cannot know in advance whether another transaction is also touching those same accounts, so Aptos uses Block-STM, an optimistic parallel execution engine that runs transactions in parallel, speculatively. When a conflict is detected - two transactions reading or writing overlapping state - Block-STM re-executes the conflicting ones. This works well but adds overhead. Every transaction, even a simple transfer, goes through speculation and potential rollback.

Sui avoids this entirely for owned objects. No speculation. No rollback. The object owner is explicit, and the system can schedule transactions by object ID without fear of conflict. For shared objects, Sui falls back to consensus, but shared objects are the exception, not the rule. Most simple asset transfers use owned objects.

Immutable objects are a third category with no write access at all. Once published, they are permanent. This is useful for storing configuration data, reference implementations, or verified code that should never change. On Aptos, immutability is achieved by freezing a resource or module within an account, but the account itself remains mutable - the global storage tree still has a root that can be altered. Sui’s immutable objects are truly fixed: they have no owner, no mutability flag, and no path to modification.

The object-centric design also changes how developers think about state. On Sui, an object is a self-contained unit carrying its own type, its own ID, and its own access rules. On Aptos, a resource is a piece of data under an account with no independent identity. The address is the primary identifier, not the resource.

As of August 31, 2026, the SuiBoxer Coin (SBOX) exists on the Sui network, deployed at contract address 0xbff8dc60d3f714f678cd4490ff08cabbea95d308c6de47a150c79cc875e0c7c6::sbox::SBOX. It launched on February22, 2026. The token trades on Cetus, a decentralized exchange on Sui, with eight trading pairs. Liquidity stands at $2,976.07. The fully diluted valuation is $13,399. In the24 hours before data collection, the token had seven transactions and $4.87 in volume; the price changed by0.64% during that period. Liquidity is thin.

Sui’s object model is the infrastructure beneath any token on the network. SBOX is an owned object or a shared object depending on how it was created. When a user holds SBOX, they hold an object with a specific owner address. Transferring that token to someone else is a single-object operation - no consensus needed, no speculation, just a signature check and an owner update.

The contrast with Aptos is not about which chain is better. It is about fundamental trade-offs. Sui sacrifices global atomic composability for speed on simple transactions; Aptos keeps the global state tree and uses optimistic parallelism to recover speed. Both approaches work. They just work differently.

For a token with low transaction volume like SBOX, the difference may not matter much day to day. But the architecture is baked in. Sui’s object-centric model means any future growth in transaction volume benefits from the parallel execution that owned objects enable, while Aptos’s global storage model will always rely on Block-STM to manage contention. The two designs reflect different bets about what kinds of transactions will dominate.

Back to sui & aptos