Most blockchains (Ethereum, Solana, etc.) follow an account-based model where assets are represented as balances tied to addresses. Sui introduces an object-centric model, where every asset is an object with its own unique ID, ownership rules, and metadata. This makes assets programmable, composable, and transferable without relying on smart contract state variables.

Benefit for devs: Fewer chances of re-entrancy bugs, easier NFT/game asset management, and more scalable transaction parallelization.

Pitfall to avoid: Treating objects like account balances; instead, think of them as standalone entities with defined ownership.

On most blockchains like Ethereum, everything revolves around accounts and balances, meaning all transactions update a shared global state. This often creates bottlenecks because every action has to pass through that single state, slowing down processing and sometimes leading to conflicts. Sui flips this model by making objects the core unit. Each token, NFT, or asset is an object with its own owner and version, which allows independent transactions to run in parallel if they do not touch the same object. This makes the system faster and more scalable while still being secure. For developers, it also means your logic feels closer to the real world since you treat assets as individual items instead of abstract entries in a ledger. By reducing global state dependencies, Sui avoids common problems like reentrancy bugs and improves user experience with quicker confirmations.

Read more here: Sui Object Model.

Sui’s Object-Centric Model vs. Account-Based Blockchains 1.** Abstraction**

• Account-based (Ethereum, Solana): State tied to accounts (balances, storage).
• Sui: State = objects (coins, NFTs, assets) with unique IDs.

2. Ownership

• Account-based: Assets belong to an address.
• Sui: Each object explicitly stores its owner (user, object, or shared).

3. Execution & Parallelism

• Account-based: Conflicting writes → serialized.
• Sui: Independent objects → can execute in parallel.

4. Safety

• Account-based: Bugs can cause double-spends/reentrancy.
• Sui: Move + resource types prevent duplication/loss of assets.

5. User Experience

• Account-based: Users manage balances at addresses.
• Sui: Users directly interact with objects (NFTs, coins, positions).

In short: Sui treats everything as objects with ownership, enabling parallel execution, safer asset handling, and richer logic, unlike account-based blockchains.

On most blockchains like Ethereum you work with an account based model where balances and states live inside global smart contracts. Every update or transfer touches this shared state which can quickly become a bottleneck since all transactions line up in a single queue. On Sui things work differently because it is object centric. Instead of one big shared ledger you deal with owned objects that represent assets like coins NFTs or even permissions. Each object has an owner and version so you always know who controls it and when it was last updated. This design allows transactions involving different objects to run in parallel which means faster confirmation and better scalability. It also makes your code easier to reason about since you only update the object you care about rather than worrying about hidden global states. For developers this shift removes many risks like reentrancy bugs and opens the door to applications that can scale smoothly without sacrificing security.

1. Core Paradigm Difference

Account-Based Blockchains (e.g., Ethereum, Solana)

Each user has an account with a global balance and nonce.

Smart contracts live at account addresses.

State is global and mutable per account.

Sui’s Object-Centric Model

Everything is an object with an ID, type, and owner.

Objects can be owned, shared, or immutable.

State transitions happen by consuming and creating objects, not modifying a global account balance.

2. Ownership and State Management

Account Model:

Balances and contract storage are tied to an address.

Multiple apps share the same account state → risk of cross-contract reentrancy.

Sui Object Model:

Ownership is explicit: objects belong to a user or to the shared pool.

No implicit global state → every state update references specific objects.

3. Transaction Semantics

Account Model:

A transaction specifies sender account, modifies balances/contracts in global state.

Concurrency is hard because all state updates go through shared account state.

Sui Object Model:

A transaction lists the exact objects it will read/write.

Enables parallel execution since independent objects can be updated simultaneously.

4. Concurrency and Performance

Account-Based:

Limited concurrency because global state requires locking for consistency.

Ethereum processes sequentially.

Sui:

Object dependency graph determines parallel execution.

Shared objects still require consensus, but owned objects can update in parallel → massive scalability advantage.

5. Access Control

Account Model:

Access controlled via account private keys.

Contract-level permissions are usually enforced through internal logic.

Sui Object Model:

Ownership is native → an object’s owner field controls who can mutate it.

Capability-based access (special objects representing roles) is common.

6. Gas and Storage Model

Account-Based:

Gas charged for computation and storage updates, but storage permanence often subsidized or ignored.

Users can leave bloated storage in the network.

Sui:

Storage is paid upfront via storage rebates.

When an object is deleted, part of the storage fee is refunded.

7. Security and Safety

Account-Based:

Reentrancy and global mutable state create attack surfaces.

Sui:

Objects are isolated, reducing cross-contract state interference.

Move language ensures strong type safety and resource guarantees.

Key Advantages of Sui’s Object Model

High parallelism for performance.

Clear ownership semantics → safer design.

Fine-grained state management → better modularity.

1. State Representation

Account-Based Blockchains (Ethereum, Solana)

State is tied to an account address.

Balances, contract storage, and permissions are grouped under accounts.

Sui Object-Centric Model

State is represented as individual objects with their own ID, type, and ownership.

Objects can be moved, transferred, or deleted independently.

2. How Transactions Work

Account Model

A transaction modifies balances or contract state within accounts.

Global state changes → higher contention.

Object Model

A transaction explicitly declares which objects it will interact with.

No global mutable state → easier to run transactions in parallel.

3. Concurrency

Account-Based

Sequential execution dominates because accounts share global state.

Sui

Transactions that touch different objects execute in parallel, improving throughput.

4. Ownership

Account-Based

All assets belong to an account implicitly.

Object-Centric

Ownership is explicit and tracked per object.

An object can belong to:

A single address (owned object)

Shared state (shared object)

Immutable state (immutable object)

5. Design Benefits

Fine-Grained Control: Developers can model assets and permissions as separate objects instead of writing custom access logic in contracts.

Natural Fit for Assets: NFTs, tokens, and game items are represented as first-class objects with explicit ownership.

Reduced Attack Surface: Isolation of state reduces risk of global reentrancy attacks.

6. Gas and Storage

Account-Based: Users pay for computation; storage often grows unchecked.

Sui: Storage costs are charged upfront; deleting objects refunds storage cost.

7. Developer Mindset Shift

In account-based systems, you design around global contract state.

In Sui, you design around object lifecycles and ownership transitions.

1. State Management

Account-Based Blockchains (Ethereum, Solana)

State is centralized around accounts.

A contract maintains shared mutable state for all users (e.g., ERC-20 token balances inside one contract).

Sui’s Object-Centric Model

State is split into discrete objects, each with a unique ID.

Assets like tokens, NFTs, or game items exist as independent objects rather than entries in a global map.

2. Transaction Design

Account-Based:

A transaction modifies state indirectly via a contract call.

You can’t predict conflicts until execution because any account may be touched.

Sui Object Model:

A transaction declares upfront which objects it will read/write.

The system detects conflicts early and executes unrelated transactions in parallel.

3. Ownership & Access Control

Account-Based:

Ownership is implicit — accounts own their balances, but logic is centralized in the contract.

Fine-grained roles require custom coding inside contracts.

Object-Centric:

Ownership is first-class, tracked per object at the protocol level.

Move capabilities (like key, store) and object ownership allow native multi-role access control without complex logic.

4. Parallelism & Performance

Account-Based:

Most transactions require global locks on shared contract state, limiting concurrency.

Sui:

Independent objects = no global lock.

Transactions that touch different objects run in parallel, significantly improving throughput.

5. Programming Paradigm

Account-Based:

Developers think in terms of contracts managing shared state.

Object-Centric:

Developers think in terms of object lifecycles, ownership transitions, and capabilities.

Fits naturally for NFTs, game assets, DeFi positions as independent entities.

6. Security Implications

Account-Based:

High risk of reentrancy and state corruption due to global state dependencies.

Sui:

Strong type safety and ownership rules prevent dangling references and limit attack vectors.

7. Gas & Storage Economics

Account-Based:

Gas focuses on execution; storage often grows unchecked.

Sui:

Storage is paid upfront; deleting an object refunds cost.

Encourages efficient state usage.