Orientation & Mental Models: How Sui Really Works Problem this solves: Developers coming from EVM or traditional databases often misjudge Sui because they assume accounts store balances and contracts store global maps. On Sui, data is first-class and structured as objects with ownership, which changes how you model everything from wallets to marketplaces.

What you’ll learn:

The Sui object/ownership model

Why parallel execution matters (and when it doesn’t)

How consensus interacts with transaction types

Practical implications for fees, performance, and data modeling

1. Sui at a glance Execution language: Move (asset-oriented; linear types prevent accidental loss/duplication).

Data model: Every on-chain thing is an object with id, version, owner, type, and contents.

Ownership types:

Owned (by an address or another object) → can be updated without consensus among validators for unrelated objects (enables parallelism).

Shared (co-owned; globally accessible) → mutations require consensus ordering.

Immutable (frozen forever after creation).

Throughput design: Highly parallelizable; transactions touching disjoint sets of owned objects can execute concurrently.

Why it matters: If you can keep your hot data as owned (not shared), your app scales and fees stay low.

2. The mental model shift Traditional smart contracts often keep state in a single storage map. On Sui:

You rarely “look up” by key in a global store.

You create objects, pass object references to functions, and Move enforces safe mutation/transfer.

Lists, maps, and indexes exist inside objects (and can leverage dynamic fields for scale).

Design pattern:

Represent a user’s inventory / portfolio as an owned object (e.g., Portfolio) that contains balances or item references.

For public coordination (auctions, leaderboards, AMMs), use a shared object—but push non-contentious writes to owned per-user objects.

3. Transaction categories & consensus Single-owner transactions: Operate on one user’s owned objects → can be executed in parallel, lower latency.

Shared-object transactions: Touch shared state (e.g., orderbook) → require consensus ordering, potentially higher latency.

Rule of thumb: Keep hot paths in single-owner lanes; isolate shared objects to “coordination only.”

4. Fees, gas, and storage rebates Each object mutation consumes gas and may incur storage cost; deleting objects can give a storage rebate.

Designing data with fewer, denser objects (or using nested structures) can lower ongoing storage fees.

Avoid gratuitous object churn (creating tons of small short-lived objects).

5. Step-by-step: Refactor a marketplace design Problem: You built a marketplace where every listing writes a shared global Listings map. It’s slow and costly.

Solution path:

Per-seller inventory: Model a SellerStore as an owned object containing the seller’s listings.

Public discovery: Keep a minimal shared Directory object that indexes only IDs and metadata for search.

Purchases: Buyer interacts with Directory to fetch listing ID, then directly updates seller’s owned SellerStore plus buyer’s owned Cart/Portfolio.

Atomicity: Compose moves so the payment, transfer, and store updates occur in a single transaction touching minimal shared state (ideally only the Directory for verification, or even zero shared if references suffice).

Measure: Benchmark gas and latency before/after.

Outcome: Most transactions stay in parallel lanes; consensus load is reduced to just coordination.

6. Common pitfalls & fixes Pitfall: Using one giant shared object as a “database.” Fix: Split into per-user owned objects; reserve shared for minimal coordination.

Pitfall: Frequent object creation for ephemeral data. Fix: Reuse objects, mutate fields, or batch updates.

Pitfall: Storing large blobs on-chain. Fix: Store hashes/URIs; keep critical state only.

Pitfall: Thinking “address = account storage.” Fix: Think “address controls a graph of objects.”

7. Checklist Did I minimize shared objects?

Can user flows mutate owned objects only?

Are indexes split into lightweight shared directories + heavy owned storage?

Am I leveraging storage rebates/deletions?