In high-load Move-based apps on Sui, you prevent double-spending by relying on object-level concurrency control rather than global locks. Each transaction declares the objects it reads or writes, so the system can detect conflicts automatically. For shared objects like pools or vaults, common patterns include optimistic concurrency, where transactions retry if a conflict is detected, and ticketing or claim objects, where users must first acquire a temporary resource before updating the shared state. Another approach is splitting shared objects into multiple owned shards, reducing contention so multiple users can interact in parallel without conflicts. Move’s resource safety ensures that coins or NFTs can’t be duplicated during retries, and Sui’s parallel execution processes non-conflicting transactions simultaneously. You can read more here: Sui Shared Objects.

// Example: claim ticket before accessing shared vault
resource struct Ticket { user: address }

fun claim_ticket(user: &signer, vault: &mut Vault) {
    let ticket = Ticket { user: signer::address_of(user) };
    // only allow withdraw if ticket exists
}

To prevent double spending in high-load Sui apps:

• Use optimistic concurrency: rely on Sui’s object versioning—transactions fail if the object has changed.

• Implement ticketing systems: create per-user or per-action tickets to queue access.

• Use object cloning or sharding: split shared objects into smaller units to reduce contention.

• Design for parallelism: structure objects to avoid frequent shared access.

These patterns help maintain consistency and avoid race conditions under load.