1. Key Difference: Objects vs. Accounts

Traditional blockchains (Ethereum, Solana, etc.) use account-based models where state is stored under a global address, and every transaction mutates that state. This creates contention (e.g., all swaps hit the same AMM pool account).

Sui flips this:

Owned objects – belong to a single address, can be mutated independently without consensus.

Shared objects – can be accessed by many users, require consensus, but are necessary for global coordination.

This object-centric model is what enables parallel execution — transactions that touch disjoint sets of objects can be executed simultaneously.

---

2. How to Leverage Object-Centric Design

a. Prefer Owned Objects for Parallelism

Each user should hold their own position, vault, or escrow object.

Example: in a lending protocol, each loan is an owned Loan object. Users borrow and repay without hitting a shared global ledger.

b. Use Shared Objects as Coordination Points

Keep shared objects lightweight and constant in size.

Example: a MarketplaceRoot that holds references to listings (via dynamic fields), but the listings themselves are owned objects.

c. Shard Shared State

Instead of one global order book, shard by pair, price range, or hash bucket.

Example: create multiple shared “order book segments” so users don’t all write to the same object.

d. Offload History to Events

Don’t store growing vectors inside shared objects.

Emit events for trades, mints, or governance actions. Off-chain indexers can reconstruct history without gas-heavy storage writes.

---

3. Design Considerations

4. Conflict Management

If two transactions touch the same shared object, only one succeeds — the other retries.

Minimize mutable fields inside shared objects to reduce conflicts.

2. Storage Costs

Storage writes dominate gas.

Use child objects for large payloads, and delete temporary objects to reclaim rebates.

3. Access Control

Owned objects can encode capabilities (NFT-style keys) that grant permissions.

Shared objects should check these capabilities instead of storing large per-user access tables.

4. Upgradability

Encapsulate logic inside modules and keep object schemas stable when possible.

Use witness patterns for package upgrades to ensure secure transitions.

5. Programmable Transaction Blocks (PTBs)

Batch many owned object mutations, then commit one shared update.

This design reduces shared-object contention while still enabling atomic workflows.

---

4. Example Pattern

Naïve (low scalability):

A single Vault shared object that stores balances for all users.

Every deposit/withdraw mutates the same object → bottleneck.

Optimized (scalable):

Each user has an owned Vault object with their balance.

A lightweight shared VaultRegistry tracks vault ownership.

Parallel execution is possible since each deposit touches a different owned object.

Sui’s object-centric model scales because transactions only lock the exact objects they touch. If two transactions involve different objects, they can run in parallel, unlike account-based chains where every balance update goes through the same account state.

For dApp design:

Owned objects (like a user’s inventory, position, or profile) scale best, since each user updates their own state without contention. Shared objects (like an AMM pool or game room) are needed for coordination, but keep them small and localized to avoid bottlenecks. Immutable objects work well for configs or metadata that never change. The key is to push most logic into owned objects, minimize writes to shared ones, and rely on events/indexers for discovery. This way your dApp taps into Sui’s parallel execution without running into hotspots.

Sui’s object-centric model scales because transactions only lock the exact objects they touch. If two transactions involve different objects, they can run in parallel, unlike account-based chains where every balance update goes through the same account state.

For dApp design:

Owned objects (like a user’s inventory, position, or profile) scale best, since each user updates their own state without contention. Shared objects (like an AMM pool or game room) are needed for coordination, but keep them small and localized to avoid bottlenecks. Immutable objects work well for configs or metadata that never change. The key is to push most logic into owned objects, minimize writes to shared ones, and rely on events/indexers for discovery. This way your dApp taps into Sui’s parallel execution without running into hotspots.