Sui and Aptos Split on Parallel Execution Design

Sui and Aptos share the Move programming language and roots in Meta’s former Diem project, but their execution architectures have diverged around how blockchain state is organized. An official Sui technical comparison published October 27 identifies the data model as the central distinction: Sui structures state around explicit objects, while Aptos primarily organizes resources under accounts and addresses and discovers transaction conflicts during execution. Aptos’ own documentation confirms that difference while also showing that the network now supports object abstractions of its own.

That distinction affects more than developer syntax. It determines when each network knows whether two transactions can safely execute in parallel. Sui transactions identify the objects they access before execution, allowing operations over independent objects to proceed concurrently. Aptos instead uses Block-STM, an optimistic parallel execution engine that runs transactions speculatively, detects conflicting state access and re-executes operations when necessary.

Sui Makes Transaction Independence Explicit

On Sui, assets and application state can exist as individual objects with unique identifiers and ownership rules. For address-owned objects, that structure lets the protocol determine transaction independence before execution, enabling unrelated operations to run concurrently and allowing some simple owned-object transactions to avoid the full consensus path required for shared state. That architecture has also shaped developer applications ranging from asset ownership to the DATA Network’s planned migration of AI provenance records into Sui.

The fast path does not apply uniformly to every Sui workload. Shared objects, which can be accessed by multiple parties, require consensus ordering, and transactions competing to write to the same shared object can become serialized. Sui’s object model therefore exposes parallelism structurally, but contention can still reduce throughput when applications concentrate state in shared objects. Sui documentation specifically recommends splitting heavily written state when applications need higher concurrency.

Aptos takes the opposite approach. Resources are commonly stored beneath accounts or object addresses, while Block-STM infers parallelism dynamically rather than requiring applications to declare all state access in advance. Transactions execute optimistically and conflicting operations are validated and, where necessary, executed again. That design allows Aptos to parallelize complex workloads without making Sui-style object independence the foundation of its transaction model.

The often-cited performance figure for Block-STM requires qualification. Aptos Labs demonstrated more than 160,000 Move transactions per second under low-contention conditions, but that result was an execution-only, in-memory benchmark rather than end-to-end blockchain throughput. Aptos continues redesigning its execution stack through MonoMove, which has produced up to 55x improvements in selected internal tests, although its production deployment remains planned rather than active.

Move Provides Shared Safety, Not Identical Systems

Both networks retain Move’s resource-oriented safety model. Structs cannot normally be copied or discarded unless their declared abilities permit it, and modules control how protected resources are created and modified. Those language constraints make accidental duplication or unauthorized construction of assets harder than in programming environments where token invariants depend entirely on contract convention. Aptos has continued extending that foundation with features including its recently activated Encrypted Mempool for pre-execution transaction confidentiality.

Move should not, however, be treated as an automatic defense against every smart-contract vulnerability. Application-level authorization, shared-state design and implementation errors remain relevant on both networks. Sui explicitly requires developers to enforce privileged access when using shared objects, while Aptos documentation includes reentrancy considerations for newer function-value functionality. The programming language narrows parts of the attack surface but does not replace secure application design.

For developers, the practical choice is less “objects versus no objects” than when and how parallelism becomes visible to the execution layer. Sui encodes independence directly into its object-oriented state model; Aptos allows Block-STM to discover it dynamically over account- and resource-based state. Both can support highly parallel applications, but the architectural choice affects contention, storage design and how developers reason about application state before a transaction reaches execution.