Here’s a summarized list of common mistakes new Move developers make on Sui:

Common Pitfalls for New Move Devs on Sui:

1. Misunderstanding Sui’s object model

• Treating everything like Ethereum accounts/slots instead of objects with ownership.

2. Overusing shared objects

• Making too many objects shared → high contention, poor parallelism, more gas.

3. Not handling Balance properly

• Keeping loose Coins → coin equivocation risks, unnecessary merges/splits.

4. Ignoring type safety features

• Skipping phantom types or resource semantics → cross-asset bugs, lost assets.

5. Redundant storage writes

• Rewriting big objects instead of using events or child objects for history.

6. Weak access control

• Forgetting to gate admin functions with capabilities or checks → anyone can mutate.

7. Poor concurrency design

• Centralizing state in one shared object instead of distributing into children → bottlenecks.

8. Gas inefficiency

• Emitting large events or storing full history on-chain instead of minimal diffs + off-chain indexing.

Embrace the object-centric model, use Balance, design for parallelism, and lean on Move’s type system + caps for safety.

When new developers start writing Move contracts on Sui, there are some recurring mistakes that tend to surface. If you’re mentoring new devs, these are the pitfalls you’ll probably see most often

Overusing Shared Objects

A lot of beginners model everything as a shared object, thinking it’s the “safe” option. In reality, shared objects are more expensive because they require consensus, and they often block parallelism. New developers miss that owned objects are cheaper, faster, and easier to reason about for most use cases.

Forgetting Cleanup Paths

Move enforces resource safety (you can’t drop or duplicate resources), but developers sometimes forget to provide destroy or reclaim functions. This leads to objects that get “stuck” because they can’t be moved or reclaimed, effectively locking user funds or assets.

Weak Access Control

It’s easy to forget that anyone can call a public entry function. New developers sometimes expose functions without checking ownership or capability permissions, which allows unintended or malicious calls. A best practice is to enforce capability checks or explicit ownership validation at every sensitive entry point.

Relying Too Much on Frontend Validation

Beginners often assume checks like “amount > 0” or “valid token type” can be safely left to the frontend. But Move contracts need to enforce these invariants on-chain, since any attacker can bypass UI checks by calling functions directly.

Inefficient Object Usage

Another common trap is repeatedly splitting and merging coins, or creating large, complex structs with vectors on-chain. This leads to high gas usage. Efficient developers learn to keep objects lean, reuse them, and batch writes to reduce storage overhead.

Ignoring Gas Profiling

New developers sometimes deploy without ever simulating or profiling gas costs. This results in contracts that technically work but are too expensive to use in practice. The Sui CLI’s dry-run and dev-inspect features are underused by beginners, even though they’re essential for testing efficiency.

Assuming Move’s Type System Prevents All Bugs

While Move’s linear types prevent duplication and resource loss, they don’t automatically protect against logical errors. Beginners often write code that looks safe but fails in edge cases (e.g., incorrect math in balance updates, or not checking vault supply caps).

When you are just starting with Move on Sui, one of the most common mistakes is forgetting that resources in Move cannot be copied or dropped unless you explicitly allow it. New developers often try to treat tokens or objects like regular variables and run into compiler errors. Another pitfall is poor struct design where ownership fields or access controls are not clearly defined, which can cause capability errors later. Many also overlook the importance of testing with the Sui CLI or dev inspect before publishing, which leads to wasted gas on fixes that could have been caught earlier. Mismanaging gas budgets is another frequent issue since underestimating gas can cause transactions to fail, while overestimating can lock up unnecessary amounts. Finally, new devs sometimes import modules or package IDs incorrectly, which causes “module not found” errors that can be avoided with careful rebuilds. If you slow down, understand object ownership, and rely on the compiler’s safety checks, you will save yourself a lot of frustration.