By Moamen Basel, September 2026, 4 labs, about 24 minutes

Sui

Sui from zero

Objects instead of account rows, and why independent state can finalize without one global order.

Sui went live in May 2023. One disagreement sits at its center. It refuses to treat ordering as something every transaction needs. This page explains the bet from nothing. Every machine on it runs real SHA-256 work in your browser, so you can check the structure instead of trusting my summary of it.

LIVE 00The mintHASH0.0s
Type a name. This toy hashes it into a repeatable ID, version, and owner so you can inspect the object fields.

Toy object generator, not a Sui mint. It uses real SHA-256 to turn your name into repeatable sample fields. Sui object IDs come from transaction context, not from a user chosen name. The useful part is the shape: identity, version, type, contents, and ownership.

01Where Sui comes from

Move, the programming language Sui runs on, was born inside Meta. Sam Blackshear wrote it for Diem, Meta's attempt at a payments blockchain. The idea that defined it was already set on day one. Money should be a value in the language that you cannot copy and cannot accidentally throw away. When that project's road ran out, the engineers scattered. In September 2021 a group of them from Novi, Meta's crypto unit, founded Mysten Labs, with Evan Cheng as CEO, Sam Blackshear as CTO, Adeniyi Abiodun as chief product officer, George Danezis as chief scientist. The venture firm a16z invested that December and led a $300 million Series B in 2022.

Sui mainnet launched on May 3, 2023. The split of work since then is simple. Mysten Labs builds the core protocol. The Sui Foundation, seated in Zug, Switzerland, funds and stewards the ecosystem around it. The language came along for the ride, though not unchanged. Sui runs a heavily modified dialect of Move, reshaped around the object model this page is about. If you have never read a blockchain teardown before, the Bitcoin page in this series builds the base layer of intuition. Everything below stands on it.

Lineage: Move written at Meta for Diem, Mysten Labs founded September 2021 by ex-Novi engineers, funded by a16z, Sui mainnet May 3 2023, then split between Mysten Labs building the protocol and the Sui Foundation stewarding the ecosystem Move at Meta written for Diem 2020, payments chain Mysten Labs founded 2021-09 ex-Novi engineers Funded a16z, 2021-12 $300M Series B, 2022 Sui mainnet live 2023-05-03 objects, not accounts Mysten Labs core protocol Sui Foundation Zug, ecosystem
Fig. 1.1 The line from a payments project inside Meta to a live chain: the language survived, the company around it was rebuilt.

02A ledger of objects

Most persistent state on Sui is represented as objects.

Ethereum organizes state under accounts in one authenticated state structure. Sui exposes application state as individually versioned objects. An object has a unique ID, a version, a type, contents, and ownership metadata. Look back at the LIVE box you just ran. It prints a reduced teaching view of those fields.

Your wallet's coin holdings can be represented by coin objects, each owned by an address and carrying its own version trail. A collectible is an object. Published packages and Move modules are immutable onchain code, while application state such as a liquidity position, domain name, or in game sword can live in objects. The opening toy prints only a few fields for clarity; real objects also carry a type and contents.

An account ledger holds one global spreadsheet of balances; an object ledger holds independent objects with IDs, versions, and owners Account ledger state root one shared trie, every writer queues 0xa1… balance 4.2 ETH 0xb7… balance 19 ETH 0xc2… balance 0.5 ETH a balance is a number in someone else's cell Object ledger id 0x9f2c… version 3 owner 0xa1… id 0x31de… version 1 owner 0xb7… id 0x88b0… version 12 shared id 0x04aa… version 7 immutable four records, four independent histories
Fig. 2.1 The account model funnels every write into one shared structure. The object model keeps millions of small records that never have to meet.

The version number is the quiet field that makes the rest of this page work. When an object changes, its version increments. The transaction that changed it names the version it acted on. Two transactions both claiming to move version 3 of the same object are in conflict. Two transactions touching different objects cannot conflict at all, ever. Hold onto that, because the entire architecture of Sui falls out of it.

03Owned and shared

An owner authorizes its object while competing writes to a shared object require an agreed order Owned object alice's key coin-111 version 4, owner one signature bob DAG validation, no total order with unrelated state Shared object p1 p2 p3 p4 pool-999, shared writes collide, order decides who wins consensus sequences the writes
Fig. 3.1 The split that defines the chain: one writer means a signature suffices, many writers mean an arbiter is required.

Sui sorts every object into one of four ownership kinds. Address owned. One address holds the key that can move it, like the coins in your wallet. Shared. Nobody's key alone can move it, and the object accepts writes from anyone, like a marketplace pool. Immutable is frozen forever, readable by all, writable by none, which is where published code usually lives. Object owned is an object belonging to another object, like a sword that belongs to a character.

Here's the move that makes Sui different. If transactions touch disjoint owned objects, their relative order cannot change either result. Shared objects are the mirror case. Writes can collide, so the network must serialize them. The original Sui Lutris design used a separate consensusless quorum path for owned objects. Since Mysticeti v2 became the default in node v1.60, transaction validation is integrated into the consensus DAG and transactions are finalized or rejected concurrently. The fast path remains, but it no longer uses the old separate certificate ceremony shown in early Sui diagrams.

04The fast path, then and now

LAB 01Two lanes, one operationSIG0.0s
Runs two owned transfers in both orders, then the same operation against a shared object.

Historical protocol toy. It models the original Sui Lutris split between a quorum certificate for owned objects and consensus ordering for shared objects. Current Mysticeti v2 integrates validation into its DAG. The lab uses real SHA-256, synthetic validator hashes, and a visible 450 ms pause; it is not an Ed25519 implementation, a network trace, or a latency benchmark.

The lab takes two payments that touch two different owned coins and executes them twice, once in each order. Both runs hash the same toy transaction records, then compare final ledger hashes. They match because the two transactions never meet. The second half aims an operation at one shared pool object, where sequence changes state. This isolates the data dependency lesson. It does not reproduce the current wire protocol.

In the historical Sui Lutris framing, broadcast bought safety while consensus bought order. Mysticeti v2 folded transaction validation into the same DAG used for consensus and made Transaction Driver the default submission path. The object model still lets independent transactions finalize concurrently. The implementation no longer sends each owned transaction through a separate consensusless quorum ceremony.

Historical Sui Lutris fast path: digest, signature check, quorum signatures, and finality without global ordering digest hash of the tx signature check owner's key quorum signs certificate forms final sub-second 0 ordering steps owned objects cannot collide with any other valid transaction, so order cannot change the outcome
Fig. 4.1 The historical Sui Lutris ceremony. Mysticeti v2 replaced this separate quorum path with transaction finalization inside its DAG.
Contents 01Where Sui comes from 02A ledger of objects 03Owned and shared 04The fast path, then and now 05One DAG, ordering where needed 06Six writers and one counter 07Move safety in one screen 08The type wall 09Sign in with Google, pay with a proof 10What landed in 2025 and 2026 11Sui, Solana, Ethereum

05One DAG, ordering where needed

Timeline of Sui consensus: launch in 2023 on Narwhal and Bullshark, Mysticeti in July 2024, Mysticeti v2 in November 2025, Odontoceti as research 2023-05-03 mainnet, Narwhal + Bullshark about 2 s to finality 2024-07 Mysticeti goes live about 400 to 500 ms 2025-11-06 Mysticeti v2 rollout validation inside the DAG 2025-10 Odontoceti on arXiv research only 2026-09 today v2 in production
Fig. 5.1 Three consensus generations in three years, each one attacking the same target: the delay before a shared object write is final.

What do contending shared objects pay for? A common order. Consensus is the protocol by which independent machines agree on that order even if some of them crash or lie. Sui launched in May 2023 with two components doing that job. Narwhal was a mempool, meaning the waiting room for pending transactions. It was structured as a directed acyclic graph so validators could gossip many transactions at once without waiting on each other. Bullshark read positions off that graph into an order for shared object work. Shared object transactions finalized in about two seconds. It was visibly slower than the separate owned object path.

July 2024 brought Mysticeti. The earlier consensus design made each DAG block carry a certificate before it could commit. Mysticeti removed that explicit block certification round and reached roughly 400 to 500 ms consensus commits in published measurements. On November 6, 2025, Mysticeti v2 integrated transaction validation into the DAG and introduced Transaction Driver. Validators explicitly vote on rejections while DAG ancestry supplies implicit acceptance votes. Sui's own test results report hundreds of thousands of transactions per second; that is a benchmark, not observed public chain demand.

Underneath the consensus churn, the plumbing is stable. Consensus output gets packed into checkpoints, with no fixed interval. Validators may split or merge commits to build them. A system Clock object at address 0x6 ticks on every commit. That gives contracts a shared sense of time. Time itself is sliced into epochs, meaning 24-hour windows at whose boundary staking rewards are paid out. The validator set is 100-plus machines. Staking, meaning locking coins as collateral to earn the right to validate, paid about 2 percent as of September 2025. A March 2026 writeup by the researchers put post Mysticeti consensus commit latency near 500 ms at world scale.

06Six writers and one counter

Contention is the whole story of this section. Here it is with numbers.

LAB 02The shared counterPOS0.0s
Runs every party's increment through the shared counter, then runs the same count of owned transfers that never meet.

Conceptual serialization model, not a protocol trace. Each pause makes a dependency visible. The hashes and counters are computed in your browser, while validator votes, network timing, and Mysticeti's DAG are simplified away. Increase the slider to see one hot shared object serialize while disjoint owned transfers remain independent.

One shared counter means one version trail. Every increment depends on the version produced by the previous increment, so the toy serializes six writes. The owned side uses six disjoint coins, so those state transitions can complete independently. Current Mysticeti v2 handles both through its DAG rather than issuing the toy certificates printed here. The invariant survives the simplification: contention creates a dependency chain, while disjoint objects do not.

Conceptual dependency model: six writes to one shared counter serialize, while six disjoint transfers can proceed concurrently parties p1 p2 p3 p4 p5 p6 counter-0 version 0 -> 6 6 ordering rounds one serving window coin-400 coin-401 coin-402 coin-403 coin-404 coin-405 0 ordering steps disjoint coins never meet
Fig. 6.1 Toggle the two lanes: contention, not cryptography, is the only thing that differs.

07Move safety in one screen

The object model sets the stage. Move is the language that keeps actors honest on it. The linear resource is the point. A value that represents an asset can be used exactly once. The compiler refuses to copy it, and it refuses to let that value silently fall out of scope at the end of a function. Every code path has to explicitly transfer it somewhere. If a function takes a Coin as an argument, that coin must end up returned, sent, or destroyed by an explicit, typed operation, on every branch, or the program does not compile. There are no pointers you can alias behind the compiler's back. There's no way to reach into another module's storage. A module can only move resources through the public entry points other modules choose to expose.

Types carry the guarantees. A Coin<SUI> and a Coin<BTC> are built from the same struct definition, but the type parameter makes them as incompatible as two unrelated types. The check happens before anything executes. Generic containers stay honest the same way. A bag that holds Sui coins cannot silently accept a Bitcoin coin. Its slot has a type. The value has a type. The two have to agree. That's the entire subject of the next lab.

The third layer is verification. The Move Prover, a formal verifier with lineage going back to the original Move work at Meta, takes a contract plus a list of invariants, statements like "this pool's reserves can never decrease without a matching withdrawal", and either proves them across all possible executions or returns a counterexample. Testing samples behaviors. A prover exhausts them. Sui's side of this lineage went public in January 2026, when a Sui Prover was open sourced. Certora, a company that has sold formal verification for Ethereum contracts for years, ships its own Sui prover as a product. None of this makes contracts correct. It makes specific, stated properties checkable by a machine, which is a different and more durable promise.

A Move function that takes a Coin by value must hand it off on every branch: return it, transfer it, or destroy it explicitly; a branch that lets the coin drop out of scope does not compile a Move function coin: Coin<SUI> return it caller receives the coin transfer it public_transfer(coin) destroy it explicit, typed, last resort drop it compile error: value not used
Fig. 7.1 Linear resources in one screen: every code path must hand the coin somewhere, and the compiler checks all of them before anything runs.

08The type wall

LAB 03Type checked transferHASH0.0s
Hashes the two type tags, tries both transfers, then replays the wrong one with the type wall switched off.

A toy of the type system, honestly labeled: the type tags are hashed with real SHA-256 and compared nybble by nybble, and the slot rule (a Bag<T> accepts only T) is the real structural rule. Move's compiler does this check statically before a transaction ever runs; the lab does it at transfer time so you can watch it refuse.

The lab hashes the type tag of Coin<SUI> and the tag of Coin<BTC> into two fingerprints. It shows you how far apart they land. Nybble by nybble, almost all of them differ. Then it offers a Sui coin to a bag whose slot demands Bitcoin coins. The transfer refuses. There's no error message after the fact. It refuses to exist, because no valid transaction can even be formed that moves the wrong type into that slot. The third act is the one to sit with. Replay the same wrong transfer on an untyped ledger, where a balance is just bytes in a cell, and it goes through silently. The bag now believes it holds more Bitcoin than anyone ever deposited. Nothing anywhere is going to complain.

Two states: with the type wall the Bitcoin slot accepts the Bitcoin coin and refuses the Sui coin before anything moves; without it a balance is bytes and the wrong coin slips in silently Coin<BTC> 1.3, type-tagged Coin<SUI> 1.3, type-tagged type wall accepted refused: ETypeMismatch Bag<Coin<BTC>> 4.2 -> 5.5 BTC, honestly accepted accepted too balance cell bytes, no types bag claims 5.5 BTC, 1.3 of it is SUI
Fig. 8.1 The type wall in two states: with it the wrong transfer refuses to exist; without it the same bytes move and the ledger lies quietly.

09Sign in with Google, pay with a proof

zkLogin flow: an OAuth login produces a JWT, the wallet derives an address from the JWT and a salt, and a Groth16 proof lets the chain verify account ownership without revealing identity claims you Google sign-in JWT + secret salt derives your address Groth16 zk proof built in your wallet Sui verifies the proof against Google's published keys, sees no identity app pays the gas sponsored transaction No seed phrase is ever shown or typed up to 1,024 calls in one atomic block
Fig. 9.1 zkLogin in one pass: the login you already have becomes the key you never see, and the chain learns the proof, never the person.

Every blockchain has an onboarding wall. It's usually the seed phrase. Twelve or twenty four words, and those words are the actual master key, written on paper. A normal person finds that terrifying. Sui's answer is zkLogin, shipped and audited by zkSecurity. You sign in with Google, Apple, or Twitch. Ordinary OAuth flow. You approve an app and it receives a credential called a JWT, a signed token asserting who you are. Your wallet combines that JWT with a secret salt to derive your Sui address. I know the next question. Does Google now sit between you and your money?

No. That's where the word zero knowledge earns its place. When you transact, your wallet builds a Groth16 zero knowledge proof, the same family of proof systems the Zcash page explains from scratch. The proof takes four private inputs, the JWT, its randomness, your salt, and a maximum epoch after which the login expires. The chain verifies the proof against the public keys Google already publishes for its JWTs. It confirms that some valid Google login stands behind this address, and that the same salt which derived the address signed this transaction. It doesn't learn which Google account, which email, or anything else the JWT asserts. Google is never asked to approve a transaction and holds no custody of anything. The proof carries the authority. The identity claims stay off chain entirely.

The second half of the wall is gas, the small fee every transaction pays. Sponsored transactions make the gas payer a separate party from the sender, natively at the protocol level, so an application can pay for you. Services like Shinami exist just to operate that faucet at scale. Put the two together. A person signs in with an account they already have, clicks send, never sees a seed phrase, and never had to buy a coin to pay for their first action. Stack on Programmable Transaction Blocks, which bundle up to 1,024 Move calls into one all or nothing transaction, and multi step operations like swap then deposit then register become a single click that cannot half fail.

10What landed in 2025 and 2026

A protocol is a claim. A stack is evidence. This is what the fact sheet confirms has actually shipped, with dates, as of September 2026.

The headline 6,086,766 figure above is an offchain channel peak, not sustained mainnet throughput. Closed channels settle their mutually signed result to Sui. That makes the experiment useful evidence for the channel design, but it cannot be compared directly with base layer transactions per second.

The money design underneath is worth one paragraph. Gas has separate computation and storage components. The storage component flows into the Storage Fund, which shifts storage rewards across epochs so future validators can be paid for retaining old data. Deleting eligible objects can return a storage rebate. These are protocol rules described in the Sui tokenomics paper, unlike market activity figures that change every day.

The shipped stack as of September 2026, layer by layer: core consensus, storage, markets, access, privacy core Mysticeti v2 - 2025-11 storage Walrus - 2025-03 Seal - 2025-09 markets DeepBook V3 - 2024-10 TSUI ETF - 2026-02 access zkLogin - 2023 gasless transfers - 2026-05 privacy Tunnels stress-test - 2026-07 Confidential Transfers - beta
Fig. 10.1 The stack as it actually stands: each layer is a shipped thing with a date, not a roadmap item.

11Sui, Solana, Ethereum

The same question about order gets three answers, one from each chain.

EthereumSolanaSui
State shapeaccounts in one global trieaccounts under one global orderobjects, each with an owner
What gets a total orderevery transactionevery transactioncontending shared object traffic
A plain owned coin transferwaits in the global sequencewaits in the global sequenceDAG integrated validation, no total order against unrelated state
Safety fromconsensus on every stepconsensus on every stepMysticeti v2 DAG finalization, with serialization where state contends

Ethereum and Solana expose one broad execution order. Solana's bet, the Proof of History clock described in its page here, is a hardware and pipeline bet on making that sequence run quickly. Sui's object model reveals when transactions are independent. Mysticeti v2 still finalizes them through its DAG, while avoiding a single serial execution queue for disjoint state.

The honest ledger has entries on both sides. Mysticeti's published production measurement put consensus commit latency near 400 ms after the 2024 rollout. The data model makes parallel execution natural because disjoint objects cannot interact. The onboarding path combines zkLogin and sponsored transactions. Against it, the chain is young. Mainnet has been live since May 2023. The validator set is a hundred plus rather than thousands. The 6 million headline came from offchain channels, not base layer demand. Shared state such as one order book still creates a serialization point. The object model also moves complexity into application design: developers must decide which state is owned, shared, or immutable.

The closing comparison refuses to crown a winner. The ranking depends entirely on what your transaction touches. If your ledger is a pile of property that changes hands, Sui's fast path fits the dependency pattern. If your transaction lives inside one hot pool with a thousand other traders, those writes still need serialization. The difference between chains then narrows to how fast their arbiters run. For the economics of paying validators to be those arbiters at all, read the proof of stake essay. For the chain that emphasizes one fast global order, the Solana page is next door.

Three answers to what gets ordered: Ethereum and Solana pass every transaction through one global sequence, Sui routes owned transfers around the sequence and orders only contended shared-object writes Ethereum one global order final Solana one order + PoH clock final Sui owned: DAG fast path, no total order consensus if shared final
Fig. 11.1 The same question, three answers: what each chain forces through its single sequence, and what Sui lets go around it.