Gas in Sui works differently because transactions can run in parallel if they don’t touch the same objects. New developers often:

Mistake 1: Forget to optimize object dependencies, causing unnecessary contention.

Mistake 2: Overlook that gas is also an object, which can expire if not handled correctly.

Best Practice:

Minimize shared object usage unless necessary.

Benchmark gas usage early with testnet tools.

Always design transactions to maximize parallelism → cheaper and faster execution.

When you build on Sui, gas can trip you up if you do not plan carefully. One common issue is setting a gas budget that is too low, which causes your transaction to fail with an "insufficient gas" error. Another pitfall is overestimating the budget so much that you end up locking up more SUI than necessary during execution. Developers also forget that publishing Move packages costs more gas than calling simple functions, so if you are testing a lot without using dev inspect simulations, you will waste tokens quickly. Some get stuck when they use a gas coin with too small a balance, since every publish and call consumes gas no matter how simple it looks. A smart practice is to split coins and keep a few with enough balance so you do not run out mid-testing. Finally, overlooking the parallel execution model can make you think gas usage is higher than it really is when in fact it depends on object dependencies. By keeping track of budgets, reusing dev inspect for testing, and managing gas coins properly, you save costs and avoid unnecessary errors.

Many new Sui developers waste gas by overusing shared objects, rewriting large pieces of state, and fragmenting coins into too many Coin objects. Other pitfalls include storing big maps inside objects, mutating when read-only access would suffice, and emitting heavy events instead of lean diffs. Inefficient batching—splitting actions across multiple transactions instead of combining them—also drives up costs. To optimize, devs should minimize shared state, consolidate coins with Balance, favor child objects and events over big rewrites, mark inputs as read-only when possible, and bundle multi-step actions into single transactions. This keeps gas usage low while preserving safety and parallelism.