Sui differs from account-centric chains for reasons deeper than consensus speed. Its state is organized around **objects with unique IDs, versions and digests**, and transactions explicitly name objects they read or mutate. That makes dependencies visible: two transactions over independent objects do not have to conflict at the execution layer. Shared objects require common sequencing, owned objects have localized authority, and Move defines resource semantics and object lifecycle. One current-architecture correction also matters: the old slogan that “owned-object transactions bypass consensus” is outdated. Sui's current 2026 documentation explicitly states that **all transactions are sequenced by Mysticeti DAG consensus**, after which deterministic execution can exploit object dependencies for concurrency.
Sui stores state as addressable objects rather than one account key-value space
In an account-centric smart-contract model, developers often think in terms of a contract address and storage slots. Sui makes an object the primary unit of on-chain state.
Every object has a stable ID
An object ID is a globally unique 32-byte identifier. It remains stable across the object's lifetime even when the object's contents change.
Version changes on mutation
Current object metadata includes an 8-byte unsigned version. A transaction that mutates the object produces a new version of the same ID.
Digest authenticates a specific state
An object reference is **(ID, version, digest)**. A transaction uses the exact reference so sender and validator agree on the same state rather than merely the same abstract object ID.
Last transaction digest links object history
Object metadata identifies the transaction that produced its current version. That naturally forms a transaction-object DAG: transactions consume object versions and produce new versions or new objects.
ID and version answer different questions
ID answers “which object?”, version answers “which state?”, and digest answers “which exact authenticated contents?” Explorers and debuggers should inspect all three.
Ownership determines who can use an object and how it is sequenced
Sui ownership is consensus-visible metadata rather than an application convention.
An address-owned object is controlled by one address
A transaction authorized by that owner can use the object. Coins and many user assets naturally fit the address-owned model.
An object-owned object belongs to another object
The owner field can itself be an object ID. This enables compositional ownership—for example, a game entity can contain child assets that cannot be independently extracted without parent logic.
An immutable object is readable by everyone and mutable by nobody
Once made immutable, the object cannot be transferred, deleted or mutated. It becomes globally readable static state.
A shared object is accessible to everyone and needs common coordination
Move can share an object using share_object. Competing transactions can then touch the same state, requiring deterministic network ordering.
A party or consensus-address-owned object has one logical owner but consensus sequencing
The current model includes ConsensusAddressOwner/party ownership for state controlled by one address while still sequenced through consensus.
A wrapped object is nested inside another Move object
While wrapped, the child does not behave like an independently addressable top-level input. The parent type's Move logic controls its lifecycle.
Ownership category is also a concurrency hint
With one owned object, the conflict domain is localized. If thousands of users mutate one shared object, that object becomes a hot synchronization point regardless of theoretical network throughput.
Move turns assets into resources with controlled lifecycle semantics
Sui uses Move while adapting it to object-centric storage.
An on-chain Move object needs key ability and UID
A Sui Move struct stored as an object has the key ability and an initial id: UID field. UID connects Move-level type safety with platform object identity.
Resources cannot be copied or dropped accidentally
Move abilities restrict which values can be copied, destroyed, stored or used as keys. Asset conservation is therefore partially expressed by the type system rather than only runtime checks.
Creation uses object::new
A function creates a fresh UID inside transaction context. Code then decides whether to transfer the object, share it, freeze it as immutable or wrap it inside another object.
Transfer changes ownership rather than an account balance slot
An NFT-like object keeps the same ID during transfer while owner metadata and version change.
A published package object is immutable
Published Move package bytecode cannot simply be rewritten in place. Upgrade mechanics publish a new package under the protocol's capability/linkage model, preserving auditability of deployed package objects.
Dynamic fields support expandable object state
Dynamic fields and dynamic-object fields let a parent own keyed collections without relying on one global account storage table.
Move resource safety does not make applications automatically safe. Access control, oracle assumptions, economic arithmetic and shared-object logic can still be wrong.
The transaction-object DAG exposes dependencies for parallel execution
A Sui transaction lists object inputs. The scheduler can therefore identify many conflicts from object references instead of learning all conflicts only after speculative execution.
Independent objects form independent branches
If transaction A mutates object X while B mutates unrelated Y, their state dependencies do not intersect. A deterministic executor can perform work concurrently while preserving one consensus sequence and deterministic effects.
The same object version cannot be consumed twice successfully
Two competing transactions that both expect the same (ID, version, digest) conflict. Once one mutation advances the object, the old version is no longer the current valid input for the other.
A shared object creates an explicit contention domain
A DEX pool, game world or marketplace registry represented by one shared object can become a hotspot. Application throughput depends on how state is partitioned across independently mutable objects.
Programmable Transaction Blocks reduce unnecessary round trips
One transaction can contain multiple commands such as splitting coins, calling Move functions and transferring outputs. Results of earlier commands can feed later commands atomically.
Parallelism does not mean every transaction runs simultaneously
The executor must respect read/write dependencies, shared-object ordering, gas-object conflicts and deterministic results. A hot object can serialize a large workload.
Historical fast-path wording now needs a qualification
Earlier Sui explanations often said simple owned-object transactions could bypass full consensus. **Current Sui Docs lifecycle says all transactions are sequenced by Mysticeti DAG consensus.** Object independence is now better explained as an execution and congestion advantage rather than blanket consensus bypass.
Mysticeti DAG consensus provides the current global sequence
The current Sui network uses Mysticeti, a low-latency DAG-based Byzantine consensus protocol.
A validator includes the transaction in a proposed consensus block
A full node's Transaction Driver selects a validator. The validator performs validity and safety checks and proposes the transaction in a Mysticeti block.
Later DAG blocks reference earlier proposals
Validators build a directed graph of blocks referencing peer blocks. Commit and order are derived from DAG structure rather than one permanent transaction leader.
Accepted transactions execute deterministically after commit
The current lifecycle sequences a transaction through Mysticeti, after which validators execute committed and accepted transactions and obtain identical effects from identical state.
Quorum acknowledgement or a certified checkpoint proves settlement
The full node gathers evidence for transaction effects. Sufficient validator acknowledgement or inclusion in a certified checkpoint gives the caller proof of irreversible settlement.
Consensus ordering and execution concurrency are compatible
A single deterministic order is useful for shared state, while independent transactions can still be physically executed in parallel when dependencies permit.
Shared-object congestion control protects hot state
Current protocol configuration includes per-object accumulated execution-cost limits and deferral rules. Network-wide capacity can be high while one popular shared object still develops a queue.
Checkpoints turn consensus commits into a permanent state-sync record
Consensus orders work, while explorers and new nodes need compact certified history.
Validators build checkpoints from consensus commits
Checkpoint summaries contain ordered transaction and effects references and link to prior checkpoints.
A certified checkpoint carries quorum signatures
Once signed by a validator quorum, the checkpoint becomes a trust anchor for state sync and historical verification.
Indexers consume the checkpoint stream
Current lifecycle documentation explicitly says indexers persist transactions, effects, events and created or updated objects from certified checkpoints into queryable indexes.
Explorers should show effects rather than only “from → to”
One Sui transaction can create, mutate, transfer, wrap or delete multiple objects and emit events. A simple account-chain narrative misses most of the result.
Practical explorer checklist
- Transaction digest and checkpoint.
- Sender and gas owner/payment object.
- Input object ID, version and ownership.
- Commands and Move calls.
- Created, mutated, transferred, deleted or wrapped objects.
- Shared objects and their versions.
- Events.
- Computation, storage and rebate gas fields.
Checkpoint finality and UI indexing latency are separate
A transaction may be settled before a particular explorer displays it because its indexer is behind. Debugging should distinguish consensus proof from frontend availability.
Delegated PoS ties validator voting power to staked SUI
Sui uses delegated proof of stake. Token holders delegate SUI to validator pools, and validator voting power depends on delegated stake under protocol caps.
New stake contributes to voting power starting next epoch
Current validator documentation states that a stake deposit becomes pending immediately and starts contributing to the validator's voting power **in the epoch after creation**.
Mainnet staking accounting uses 24-hour epochs
The validator-rewards page states that Sui uses 24-hour epochs. Epoch boundaries update validator economics and the reference gas price.
One validator is capped at 10% voting power
The voting-power scale totals 10,000 units and quorum threshold is 6,667. A single validator is capped at **1,000 voting power, or 10%**, even if its staking pool accumulates more stake; excess voting weight is redistributed across the remaining validator set.
Rewards depend on performance and commission
At epoch end, collected gas fees and stake subsidies are distributed through validators and staking pools. Validator commission takes an explicit share of staking rewards.
An underperforming validator can lose epoch rewards
The tallying rule allows validators to report poor operations. Documentation describes slashing the reported validator's staking rewards for that epoch, which is different from automatically burning all delegated principal.
Stake withdrawal is processed immediately using the previous epoch exchange rate
Current docs state that withdrawals do not need to wait for current epoch close. The user receives principal plus rewards accumulated through the previous epoch and does not receive still-unknown rewards from the current unfinished epoch.
StakedSUI is an object, not an invisible account flag
A deposit is wrapped into a StakedSUI object. Its creation epoch and the staking pool's exchange-rate history determine withdrawal value.
SUI pays for computation and storage and participates in storage-fund economics
Sui's gas model distinguishes computation from long-lived state effects.
A gas payment is itself an object input
A SUI coin used as gas has object identity and version. Reusing the same gas coin concurrently creates a dependency even between otherwise independent transactions.
Reference gas price updates per epoch
Validators submit gas-price quotes. Current documentation describes a stake-weighted **two-thirds percentile** used to set the next epoch's reference gas price, which then stays constant during that epoch.
Storage charges reflect long-lived state
Creating or expanding on-chain data incurs storage cost. Deleting state can return a storage rebate under protocol accounting.
The storage fund separates current revenue from future storage burden
Part of the economic design compensates future validators for retaining historically created state rather than sending every storage payment to the current producer set.
Object-centric design exposes state cost to application architects
Large object collections, dynamic fields and shared state impose storage as well as CPU cost. Good design minimizes unnecessary persistent state and hot-object contention.
A cheap single transaction does not imply a free application. Count hot-object contention, storage growth, gas-object management, indexer load and validator execution cost together.
Sui and Aptos both use Move but parallelize state differently
Both networks come from the Move ecosystem, yet their state and execution architectures differ materially.
Sui makes object identity part of the storage and execution model
Transactions explicitly reference object versions. Ownership categories expose many conflicts before execution.
Aptos retains an account/global-storage model
Aptos Move resources live in global storage under accounts and addresses. Developers more often reason about resources and modules under an account namespace than independently owned Sui objects as the primary state unit.
Aptos Block-STM uses optimistic dynamic parallelism
Current Aptos documentation describes an ordered block whose transactions execute speculatively in parallel. Block-STM detects conflicts and re-executes transactions when required while preserving the preset deterministic order.
Sui parallelism leans more heavily on explicit object dependencies
Object inputs expose ID, version, digest and ownership before execution. Shared objects still need consensus sequencing and congestion control.
| Characteristic | Sui | Aptos |
|---|---|---|
| Move heritage | Yes | Yes |
| Primary state mental model | Objects with ID/version/owner | Account/global-storage resources |
| Conflict signal | Explicit object references and ownership | Runtime read/write conflicts plus execution metadata |
| Parallel execution | Dependency-aware object model | Block-STM speculative execution |
| Shared mutable state | Shared/party objects | Resources/global state paths |
| Consensus | Mysticeti DAG | Aptos BFT family |
Similar Move syntax does not imply identical dApp architecture
Porting a contract between Aptos and Sui requires redesigning ownership, storage and transaction composition rather than merely renaming SDK calls.
Object-centric state is especially natural for asset-like resources
An NFT, game item, position, ticket or credential can be a standalone object with explicit ownership. Account-centric resources can represent similar products through a different storage topology.
Main conclusion and FAQ
Main conclusion
Sui's performance architecture begins with **explicit state dependencies**, not a headline TPS number. An object has ID, version, digest and ownership mode. Move controls creation, transfer, sharing and wrapping. A transaction names exact objects, so independent branches can execute concurrently while hot shared state becomes an explicit contention domain.
The current 2026 architecture also requires updating an older mental model: all transactions are sequenced by **Mysticeti DAG consensus**, after which validators deterministically execute committed work, certify effects and record results in checkpoints. Object independence remains valuable for concurrency and congestion but no longer should be described as blanket consensus bypass.
The DPoS layer ties validator voting power to SUI stake, caps one validator at 10% voting power, uses 24-hour epochs and distributes gas fees and stake subsidies through staking pools. Explorers therefore need to read object effects rather than merely from/to fields.
The engineering question for Sui is: **which exact objects does a transaction read and mutate, which are shared, where do dependency conflicts appear, what does Mysticeti sequence, which effects are checkpoint-certified, and how does stake distribution support the validator quorum assumptions?**
What is a Sui object reference?
It is the triple **(object ID, version, digest)**. ID identifies the object, version identifies a specific state, and digest authenticates that version's contents and metadata.
How does an owned object differ from a shared object?
An address-owned object has a specific owner and localized authority. A shared object can be accessed by multiple participants and requires common consensus ordering for competing mutations.
Does Sui still have a consensus-free fast path for owned objects?
Current 2026 transaction-lifecycle documentation says **all transactions are sequenced by Mysticeti DAG consensus**. The old blanket “bypass consensus” description is outdated; object independence now primarily explains execution parallelism and reduced contention.
Why can Sui execute transactions in parallel?
Object references make many dependencies explicit. Transactions over disjoint objects do not conflict and can execute concurrently while preserving deterministic effects. A hot shared object can still serialize workload.
When does delegated stake become active?
Current validator docs state that new stake starts contributing to voting power in the next epoch. Mainnet staking accounting uses 24-hour epochs.
Can stake be withdrawn immediately?
Current Sui documentation describes immediate withdrawal using the previous epoch exchange rate. Principal and rewards through the prior epoch are returned without waiting for current epoch close; the unfinished current-epoch reward is not included.
How does Sui parallel execution differ from Aptos Block-STM?
Sui structures concurrency around explicit object references and ownership. Aptos Block-STM runs ordered transactions speculatively in parallel, detects runtime conflicts and re-executes when necessary.
This material is educational and does not constitute financial advice or a promise of staking returns.