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.

1. How Gas Works on Sui

Single gas coin: Every transaction specifies one coin object to pay gas. That coin is consumed, charged, and the remainder is returned.

Two main components of gas cost:

1. Computation gas – cost of executing bytecode instructions, similar to CPU cycles.

2. Storage gas – cost of writing new objects to storage (persisting data is much more expensive than transient computation).

Refunds: If you delete or overwrite objects, you may receive storage rebates (partial refund of storage gas).

---

2. Object-Centric Impact

Because Sui executes transactions on objects, not accounts, gas is influenced by:

Number of input/output objects (each must be read/written).

Whether objects are shared or owned (shared objects require consensus, raising costs).

Dynamic fields / tables: Inserting/removing entries costs storage gas.

---

3. Differences vs. Other Chains

In Ethereum, every opcode has a fixed gas unit. In Sui, costs depend heavily on object writes vs. reads.

Sui doesn’t charge linear costs for loops over in-memory vectors (computation gas applies), but persisting large vectors to storage will spike storage gas.

Parallel execution reduces contention costs, but if your transaction touches a shared hotspot object, consensus adds overhead.

---

4. Optimizations for Developers

a. Minimize Shared Object Usage

Use owned objects whenever possible.

Turn global maps into sharded maps (per-user or per-key objects).

Shared objects cost more gas and reduce parallelism.

b. Store Less, Emit More

Persist only the minimum necessary state.

Use events for history instead of storing long vectors inside objects. Events are cheaper and designed for off-chain indexing.

c. Use Dynamic Fields Wisely

Good for composability (e.g., NFT traits, registries).

But each dynamic field insertion is a new object under the hood — which means storage gas.

Avoid creating unnecessary dynamic fields in hot paths.

d. Exploit Storage Rebates

When objects are deleted, a portion of their original storage gas is refunded.

Design contracts so that temporary objects (escrow, offers, temporary states) are cleaned up instead of lingering.

e. Batch Mutations with PTBs

Programmable Transaction Blocks let you mutate many owned objects in one transaction, then touch the shared object once at the end.

This lowers both gas and conflict rate.

f. Keep Structs Flat and Lean

Wide structs with large vectors stored in a shared object will be costly.

Instead, break large data into child objects or use events for append-only logs.

---

5. Practical Example

Let’s compare two approaches for a marketplace:

Bad (expensive):

Shared Marketplace object with vector of all listed items.

Each new listing mutates that vector.

Gas rises as vector grows, plus contention grows.

Better (optimized):

Shared MarketplaceRoot that only tracks a registry.

Each listing is its own owned object (cheap to store, parallelizable).

Use events to index activity off-chain instead of storing vectors.

On Sui, gas covers two things: the cost of running bytecode (computation) and the cost of storing data on-chain (storage). Unlike Ethereum, which charges per storage slot, Sui charges based on the objects you create, mutate, or delete. If you delete an object, you actually get a storage rebate, which encourages cleaning up state.

Because Sui is object-centric, your gas also depends on whether the objects are owned or shared:

• Owned objects can be processed without full consensus, so they’re cheaper and faster.
• Shared objects require consensus and cost more.

Optimizing means:

• Break big structures into smaller objects so updates are cheaper and can run in parallel.
• Minimize writes since they’re expensive, while reads are relatively cheap.
• Design contracts so unused objects can be deleted, returning some gas to users.

The result is a gas system that’s more predictable and efficient, especially if you structure your app around lightweight, owned objects.