What is Mysticeti?

Mysticeti is the consensus protocol Sui validators use to agree on the order of transactions. It's a DAG-based Byzantine fault tolerant protocol, designed by Mysten Labs researchers, that commits blocks in three message rounds, which is the theoretical minimum. It went live on Sui mainnet in July 2024, replacing Narwhal and Bullshark. Mysticeti v2, the default since node v1.60, moved transaction validation into consensus itself.

How it works

Every validator proposes a block each round. A block contains transactions and references to blocks from the previous round, so the blocks together form a directed acyclic graph (DAG). Two design choices make Mysticeti fast:

• Uncertified DAG. In Narwhal, each block needed a quorum of validator signatures before it could be shared. In Mysticeti, validators just sign their own blocks and broadcast them. Votes are implicit: a block that references another block counts as support for it. That removes a round trip per round.
• Multiple leaders per round. Bullshark committed only every two rounds or so, and only through one leader. Mysticeti's commit rule can treat several blocks in each round as leaders and commit them directly. A leader that's offline doesn't add much latency.

Once a leader is committed, every validator walks the DAG the same way and gets the same order of transactions.

The fast path

The Mysticeti paper describes two variants. Mysticeti-C is the consensus protocol. Mysticeti-FPC adds a fast commit path for transactions on owned objects, so votes for those transactions ride inside DAG blocks instead of needing separate signatures. On Sui, the mysticeti_fastpath feature flag is enabled on mainnet in the protocol config. Transactions that touch only owned objects can finalize as soon as they collect enough votes in the DAG. Transactions on shared objects wait for a commit.

Mysticeti v2

Mysticeti v2 kept v1's commit rule and changed how transactions get in:

• Validators sign transaction validity as part of signing consensus blocks. Explicit votes are cast only to reject a transaction.
• The full node's Transaction Driver sends each transaction to one chosen validator, picked by observed latency. The old Quorum Driver broadcast every transaction to all validators twice.
• Multiple rounds can vote on a transaction, so one sent through a poorly connected validator can still finalize.

Mysten Labs reported end-to-end latency dropping from about 0.55 s to 0.40 s for full nodes in Europe, and from about 1.00 s to 0.65 s in Asia.

Numbers to read carefully

The paper reports about 0.5 s commit latency and over 200,000 TPS in WAN benchmarks. Sui's docs quote 300,000–400,000 TPS for 10- and 50-node test setups. Those are benchmark figures, not mainnet load. For production timing, Sui's docs say end-to-end finality is typically 400–700 ms; see how fast Sui is.

What developers notice

You don't call Mysticeti directly. You notice it as sub-second finality, no reorgs, and different behaviour for owned and shared objects. Consensus output becomes checkpoints, which is what indexers and full nodes consume. For the bigger picture, see Sui's consensus mechanism.

Sources

• Mysticeti: Reaching the Limits of Latency with Uncertified DAGs, arXiv
• Mysticeti set to supercharge consensus on Sui, Sui blog
• Mysticeti v2, Sui blog
• Consensus, Sui documentation
• sui-protocol-config, MystenLabs/sui on GitHub