Sui’s Consensus Explained: How Narwhal and Mysticeti Finalize in 0.5 Seconds

How Sui achieves sub-second finality without cutting corners on security.

Half a second to finalize a transaction. That number isn’t the result of a security trade-off. It’s the result of eliminating the architectural constraints that forced every other blockchain to be slow. Two protocols make it possible: Narwhal and Mysticeti.

This article is part of a series on Sui:

• Discovering Sui: A Blockchain With Multiple Innovations
• Under the Hood of Sui: Validators, Consensus and Staking
• Sui: The Object Model, or Rethinking Blockchains Through Data
• Sui Governance: Upgrading Without Breaking

What Sui Does Differently

Sui doesn’t treat all transactions the same way. Those that only affect objects owned by a single user bypass consensus entirely via Byzantine Consistent Broadcast. Those that touch shared objects go through full consensus.

That distinction — not an optimization trick, but a core property of the object model — is what makes everything else possible.

Narwhal and Mysticeti: Two Roles, One Blurry Line

For transactions that do require consensus, Sui separates two responsibilities.

Narwhal handles dissemination: receiving transactions, organizing them into batches, and building a DAG (Directed Acyclic Graph) where every validator emits blocks in parallel. The network is no longer bottlenecked by a single validator proposing the next block.

Mysticeti handles ordering. It takes that DAG, applies deterministic rules, and every validator independently reaches the same conclusions — no additional back-and-forth required.

One important nuance: the boundary between the two isn’t perfectly clean. Mysticeti doesn’t passively order a pre-built DAG. It incorporates its own block validation and propagation logic. The “dissemination vs. ordering” framing is useful, but it slightly oversimplifies the reality.

Another commonly misquoted figure: Narwhal headers are not 32 bytes. They contain signatures, references to previous rounds, and batch digests — several hundred bytes in practice. The 32 bytes refer to the cryptographic digest of an individual batch, not the header itself.

The DAG, Concretely

Everything rests on this data structure. A DAG (Directed Acyclic Graph) is a graph with directed edges and no cycles: you can’t return to your starting point by following the arrows.

A concrete example. Alice sends 10 SUI to Bob. At the same time, Charlie buys an NFT from his own wallet. These two transactions share no objects: two unconnected nodes in the DAG, processed in parallel. Now suppose Bob immediately uses those 10 SUI to pay Charlie. His transaction causally depends on Alice’s. In the DAG, Bob’s node points to Alice’s. Alice goes first.

What this changes: there’s no longer any need to impose an arbitrary global sequence. Order emerges from real dependencies. Everything that can run in parallel does.

Narwhal: How It Works

The Problem

In a classic blockchain, transactions pile up in a global mempool. A single validator picks from it, proposes a block, and the entire network re-executes it to validate. Sequential by design. It hits a ceiling fast.

Narwhal removes the single coordinator. All validators broadcast in parallel every round.

The Mechanics

A round is a time window during which all validators do the same thing: collect transactions, create headers, broadcast. A synchronized work session. When enough validators signal the end of a round, the network moves to the next one. A lagging validator catches up in the following round.

Each validator’s workers continuously collect transactions and pack them into batches of up to 512 KB. The constraint: each batch can only contain causally independent transactions — ones that don’t modify the same objects. These batches go directly to the counterpart workers of other validators over a peer-to-peer network.

The primary collects metadata from its workers and creates a header: a fingerprint containing the cryptographic digests of those batches and references to the parent headers from the previous round. Only these headers travel between primaries — not the raw transaction data.

How the DAG Gets Built

Each header becomes a vertex. Edges encode the causal dependencies between groups of transactions. If header A contains transactions that modify objects read by transactions in header B, then B references A. Logical ordering is preserved automatically.

The 2f+1 Rule

To advance to the next round, a validator must prove it has processed at least 2f+1 headers from the current round — where f is the maximum number of faulty validators the network can tolerate.

Why that formula: in the worst case, f malicious validators send corrupted headers. But among the 2f+1 received, at least f+1 are honest. That’s the minimum Byzantine safety threshold. With 100 validators and a tolerance of 33 failures, the threshold is 67.

Fast validators don’t abandon slow ones. Slow ones don’t stall the network.

Catch-Up Links

A temporarily slow validator can create links pointing to older headers. These links don’t count toward round progression, but they let that validator’s data get included in the DAG without blocking anyone else.

The Numbers

Each worker independently processes a subset of transactions. Bandwidth scales roughly linearly with the number of workers. The 32-byte digests replace full transaction data for circulation between primaries, with a typical compression ratio of 1000:1. The underlying data is only fetched on demand.

Mysticeti: Why 3 Rounds Are Enough

Mysticeti takes Narwhal’s DAG and determines the final execution order. No deliberation between validators: deterministic rules applied to the same structure, same conclusions everywhere.

Uncertified DAGs

Narwhal headers feed directly into the consensus process without additional signatures. Validation happens through structural and connectivity rules in the DAG. If a block satisfies those criteria, it’s automatically accepted and can be committed.

Why Exactly 3 Rounds?

It’s a mathematical constraint of BFT systems, not an arbitrary design choice.

With 1 round, it’s impossible to distinguish a malicious silence from a simple network delay. With 2 rounds, inconsistencies can be detected, but there’s no certainty that all honest validators have converged on the same view. The third round is what lets each validator know that the others have seen the same thing — the minimum condition for a safe commit.

In practice:

1. “Here is my proposal”
2. “I received yours, here is mine”
3. “We agree on the full set”

Three rounds. No fewer. That’s the theoretical lower bound.

The Commit

A block is committed when it’s connected to enough other blocks in the DAG, its causal dependencies are satisfied, and it meets temporal consistency rules. Multiple independent blocks can be committed simultaneously.

The Fast Path

For simple transfers (objects owned by a single user), Mysticeti-FPC bypasses full consensus via Byzantine Consistent Broadcast. This isn’t a verification shortcut. It’s the elimination of the coordination problem at the root. These transactions are still integrated into the main DAG.

The Real Numbers

Mysticeti replaced Bullshark in 2024. Latency dropped by roughly 40% on shared-object transactions. The 80% figure sometimes cited compares Bullshark under degraded conditions to Mysticeti under optimal ones — fair, but worth contextualizing.

In real WAN conditions: finality in 0.5 seconds for shared objects. The 200,000 or 400,000 TPS figures come from controlled benchmarks (local networks, synthetic load). On mainnet, Sui typically runs between 5,000 and 20,000 TPS under real conditions.

The Two Running in a Pipeline

Narwhal and Mysticeti don’t wait for each other. They’re pipelined.

Narwhal collects transactions, forms batches, disseminates lightweight headers, builds the DAG incrementally. Meanwhile, Mysticeti identifies ready blocks, commits them in parallel when they’re independent, and finalizes in sub-second time.

While Mysticeti is committing round N, Narwhal is already preparing round N+1.

Adding workers increases Narwhal throughput. Optimizing Mysticeti speeds up finalization. The two levers are independent.

How It Compares to Ethereum

On Ethereum, a block is an ordered list of transactions selected by a single coordinator, ranked by gas price. The entire network re-executes everything to validate. Order is imposed — even across transactions that have nothing to do with each other.

On Sui, what gets committed is a checkpoint: a subset of the Narwhal DAG on which Mysticeti has applied its commit rules. Order isn’t imposed by any single actor. It emerges from the causal dependencies declared in Move. Unrelated transactions execute in parallel. The size of a checkpoint depends on DAG connectivity, not an arbitrary limit.

Ethereum’s bottleneck — one coordinator, one sequence, one global re-execution — simply doesn’t exist in this architecture.

A Side-by-Side Look at the Transaction Lifecycle

Ethereum. A transaction enters a global mempool, sorted by gas price. A single validator picks it, broadcasts the full block. The entire network re-executes it to validate. Consensus runs through Casper FFG: 2 to 10 minutes to finality. Execution is sequential, in the order the coordinator imposed.

Sui. A transaction is routed directly to the appropriate validator based on the object it touches, and collected into a structured batch. All validators participate in parallel each round. Only lightweight headers travel across the network. Consensus runs through 3 Mysticeti rounds: 0.5 seconds for shared objects, sub-second for owned objects. Independent transactions execute in parallel.

Half-second finality isn’t the result of loosened security guarantees. It’s the result of removing the architectural constraints that forced sequentiality in the first place. Narwhal builds a parallel DAG. Mysticeti orders it in 3 rounds. Move’s object model makes both possible.

Sui’s Consensus Explained: How Narwhal and Mysticeti Finalize in 0.5 Seconds was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.