How Sui's Object-Centric Data Model Works

Sui's object-centric data model represents every piece of on-chain state — a coin balance, an NFT, a piece of application data — as a distinct object with a unique identifier, a defined type, and clear ownership rules, rather than tracking state as entries in one large shared ledger the way account-based blockchains typically do.

This design choice is the foundation of Sui's approach to parallel transaction execution, and it's worth understanding at a level deeper than "it's fast" to see why the model actually enables that speed.

Objects instead of accounts

In an account-based blockchain, a transaction typically reads and writes to a shared global state structure — your token balance is one entry among millions in a giant interconnected ledger, and determining whether two transactions might conflict generally requires actually executing them (or a substantial part of them) to see what they touch. Sui instead gives every asset its own object, with its own ID and its own record of who owns it or how it can be accessed. A transaction explicitly declares which objects it needs to interact with before it runs.

This declared-inputs approach is the key mechanical difference: because a transaction states upfront exactly which objects it touches, the network can determine whether two transactions could possibly conflict with each other before executing either one, rather than discovering conflicts after the fact.

Owned objects: the fast path

Most everyday objects — a personal token balance, an individual NFT — are "owned" objects, meaning only their designated owner can authorize a transaction that uses them. Because an owned object can only be affected by transactions its owner authorizes, and no other party's transaction can touch it, Sui can process transactions touching only owned objects with minimal coordination: if your transaction only touches objects you own, and my transaction only touches objects I own, and we don't share any object, our transactions can be validated and executed completely independently and in parallel.

Shared objects: where coordination is still needed

Not every object can be exclusively owned. Some objects — a public liquidity pool multiple traders interact with, a shared piece of game state multiple players affect — are "shared" objects, accessible by transactions from multiple different parties. Because more than one party's transaction might touch the same shared object at the same time, the network does need to sequence and order transactions touching that specific shared object carefully, similar in spirit to how any concurrent system needs to manage access to a shared resource.

Sui's design isolates this coordination overhead specifically to transactions touching shared objects, rather than applying it network-wide — the large share of everyday transactions that only touch owned objects skip this overhead entirely.

Why this matters for throughput

Because the network can identify, before execution, which transactions are guaranteed not to conflict (those touching entirely separate owned objects), it can safely execute large batches of them fully in parallel rather than processing them one at a time or optimistically executing and rolling back conflicts after the fact. This is a structurally different approach from Aptos's Block-STM, which achieves parallelism by optimistically executing transactions and re-running any that turn out to genuinely conflict — see our Aptos vs Sui comparison for that distinction in more depth.

Object model vs account model

Factor	Sui's object model	Typical account model
State representation	Individual objects with IDs and ownership	Shared ledger of account/contract entries
Conflict detection	Upfront, based on declared object inputs	Often discovered during/after execution
Parallelism for owned-object transactions	High — minimal coordination needed	Depends on execution engine's optimizations
Coordination needed for shared state	Only for transactions touching shared objects	Applies broadly across shared ledger entries
Developer mental model	Object ownership and access patterns	Familiar account balances and contract storage

Honest tradeoffs

The object model's parallelism benefits come with a real learning curve: developers need to think explicitly in terms of object ownership, and design their applications' data structures around the owned-versus-shared distinction to get the full performance benefit, rather than simply porting over patterns from account-based Solidity development. This is a genuinely different mental model, and Sui's ecosystem and tooling, while capable, are newer and less extensively documented than the account-based tooling most existing blockchain developers already know.

Bottom line

Sui's object-centric model solves the transaction-conflict problem by making conflicts detectable upfront rather than discovered mid-execution, which is what enables its parallel processing of independent, owned-object transactions. It's a genuinely different and well-reasoned approach to blockchain scalability, though it asks developers to learn a new way of structuring on-chain data in exchange for that performance — a real tradeoff worth understanding rather than treating the object model as simply "faster" with no adjustment cost.