Sui Platform
What makes Sui's runtime structurally different from EVM and SVM — and where does that difference become decisive?
The object model is the foundation. Everything — coins, NFTs, devices, identities — is an object with an ID, type, owner, and data. Ownership is explicit, not inferred from a balance mapping. Parallelism follows naturally: transactions on disjoint object sets execute concurrently without coordination.
Object Model
The single most important design decision. Every other property — parallelism, safety, composability — follows from it.
| Object type | Ownership | Consensus needed | When to use |
|---|---|---|---|
| Owned | Single address | No — fast path | Coins, NFTs, capability objects, user state |
| Shared | Protocol-controlled | Yes — full Mysticeti | AMM pools, order books, multi-party coordination |
| Immutable | Nobody (frozen) | No — read-only | Published packages, constants |
The design rule: Default to owned objects. Shared objects go through full consensus — they cost throughput. Only use shared when multiple parties genuinely need simultaneous write access. The prediction_game Season object is shared because multiple bettors must update it concurrently. A user's coin is owned — only they control it, so no coordination is needed.
Ownership is explicit in the object struct:
Object ID: globally unique (derived from tx hash + creation order)
Type: Move module::struct name
Owner: address | shared | immutable
Version: monotonically increasing
Data: the fields you define
No balance mapping. No global state table. Each object carries its own ownership. That's why transactions on disjoint objects run in parallel — there's no shared lock to acquire.
Mysticeti Consensus
Mysticeti is purpose-built for sub-second finality. The key design choice: a DAG (Directed Acyclic Graph) structure instead of a single-leader chain.
| Property | Value | Implication |
|---|---|---|
| Finality | ~390ms end-to-end | Real-time UX — prediction bets, payments, agent workflows |
| Structure | DAG, not chain | All validators propose in parallel — no leader bottleneck |
| Security | BFT, tolerates <1/3 faulty stake | Same Byzantine guarantees as Tendermint, lower latency |
| Validator count | 100+ | Decentralized enough for permissionless use |
Fast path vs full consensus: Simple transfers on owned objects bypass Mysticeti entirely — they use a lightweight certificate protocol. Only shared object transactions go through full DAG consensus. This is why the throughput/latency numbers look different for owned vs shared object operations.
Practical implication: Build with owned objects wherever possible. The owned-object fast path is why Sui can target ~390ms for most user-facing operations.
Parallel Execution
The object model makes parallelism explicit rather than inferred. Two transactions can execute in parallel if and only if they touch disjoint sets of objects.
User A sends coin to User B → touches {coin_A, account_A, account_B}
User C places a bet → touches {season_obj, pool_obj, coin_C}
No overlap → execute in parallel
Solana (Sealevel) attempts to infer parallelism from account access lists — developers declare which accounts a transaction touches upfront, and the runtime parallelizes based on that declaration. If the declaration is wrong, the transaction fails. Sui's object model makes this structural — the runtime knows exactly which objects each transaction touches because they are the inputs.
Linear scaling: Throughput scales with validator hardware as long as transactions are touching disjoint objects. A DePIN network with 10,000 devices each sending telemetry can process all 10,000 concurrently — each device has its own owned object.
Storage Fund
Every byte of on-chain storage has an economic cost. Sui handles this through the storage fund — a mechanism that internalizes long-run storage costs into the transaction that creates the storage.
| Mechanism | How it works |
|---|---|
| Storage deposit | Publishing a package or creating an object pays a one-time fee proportional to bytes |
| Storage rebate | Deleting an object returns most of the original deposit |
| Fund distribution | Storage deposits accumulate in the fund; validators receive share as compensation for storing history |
Practical consequence: Applications that create many objects need to model storage costs upfront. The device_registry module creates one object per device — at scale, that's a significant storage deposit. Objects that can be deleted (temporary results, expired sessions) should be deleted to reclaim deposits. The storage fund makes "create and forget" expensive, which is correct incentive design.
Move Bytecode Verifier
The verifier runs at publish time, not deploy time. Before a package reaches the network, the bytecode verifier checks:
| Check | What it prevents |
|---|---|
| Linear types | Assets duplicated, accidentally destroyed, or silently dropped |
| Capability enforcement | Functions called without required capability object |
| Memory safety | Dangling references, double-free |
| Type safety | Object type confusion |
| Reentrancy | By construction — no dynamic dispatch across external contracts |
This is why "entire vulnerability classes eliminated" is accurate rather than marketing language. Reentrancy attacks (DAO hack, countless DeFi exploits) cannot exist in Move because the type system prevents the call pattern that enables them. The verifier is not a runtime check — it's a publish-time gate.
Move Prover extends this to formal verification of custom invariants. Economic properties — attribution percentages sum to 100, value conserved across operations — can be formally proven rather than tested. The prover is part of the standard toolchain, not a $50K audit add-on.
Programmable Transaction Blocks
PTBs chain up to 1,024 operations in a single atomic transaction, all executing in approximately 390ms. Each operation can use the outputs of previous operations.
Split coin → Transfer half → Call moveCall with remainder → Transfer result → All atomic
This is the composability primitive. A DeFi flow that requires 5 separate transactions on EVM can be a single PTB on Sui. The prediction_game settle-and-distribute flow is one PTB. Attribution recording and reward distribution run in the same PTB as the purchase.
Prohibited in PTBs: sui::random cannot be called mid-PTB. Randomness must be the final operation in a dedicated transaction. This prevents manipulation: a caller cannot inspect the random result from earlier in the PTB and then conditionally proceed. See Sui Move Patterns for the canonical randomness pattern.
zkLogin + Sponsorship
Two features that change consumer onboarding:
zkLogin: OAuth provider (Google, Apple, Facebook) → JWT → Zero-Knowledge Proof → Sui address. The address is deterministic from the OAuth identity. No seed phrase. No browser extension. No "get SUI first" step. The ZKP proves you hold the OAuth credential without revealing it.
Sponsored transactions: The platform co-signs a PTB to pay gas. The user signs to prove intent. The network accepts dual-signed transactions natively — no middleware, no relayer infrastructure. 23.4% of Sui transactions in 2025 were sponsored. The UX consequence: a user with no SUI can execute a transaction on their first interaction.
Together: a new user clicks a blink link, signs in with Google (zkLogin), approves the transaction modal, and a PTB executes — all without installing anything or owning any cryptocurrency.
Context
- Sui Development — Onboarding path and full package inventory
- Sui Technical — Architecture deep dive and agent economy primitives
- Sui Standards — PTBs, zkLogin, kiosk, and EVM comparisons
- Smart Contract Comparison — Cross-platform scoring (safety, speed, composability)
Links
- Sui Object Model — Official documentation
- Mysticeti Paper — DAG-based BFT consensus design
- Move Language Book — Resource types, linear types, formal verification
- Move Prover User Guide — Formal verification toolchain
Questions
Where does the owned-object fast path make something trivial that other runtimes make hard — and where does shared-object consensus introduce friction that account-based models don't have?
- If throughput scales linearly with hardware on owned-object transactions, what is the actual bottleneck for a DePIN network with millions of devices?
- At what PTB complexity does the composability advantage over separate transactions disappear — and what replaces it?
- If zkLogin creates a deterministic address from an OAuth identity, what happens when the OAuth provider revokes the identity?