What consensus mechanism does Sui use?
October 29, 2026
Sui uses Mysticeti, a DAG-based Byzantine fault tolerant (BFT) consensus protocol. It runs on a delegated proof-of-stake validator set. SUI holders stake with validators, and each validator's voting power follows its stake. Mysticeti replaced Sui's earlier Narwhal and Bullshark stack on mainnet in July 2024. Since node v1.60, transactions are submitted through the Mysticeti v2 path, which folds transaction validation into consensus.
Two layers: who votes, and how they agree
Delegated proof of stake decides who runs consensus and how much each vote counts. The validator committee is fixed for each epoch, which lasts about 24 hours on mainnet. Stake changes and validators joining or leaving take effect only at the epoch boundary. Any decision needs a quorum of validators holding more than two-thirds of voting power, so the network tolerates up to one-third faulty or malicious stake. See staking.
Mysticeti decides how those validators agree on the order of transactions. Every validator proposes blocks in parallel. Each block references earlier blocks from other validators, which forms a directed acyclic graph (DAG). A commit rule reads the DAG and picks leader blocks, and all validators then derive the same total order from them. Mysticeti needs three message rounds to commit, which its authors describe as the theoretical lower bound for BFT consensus.
What goes through consensus
Under Mysticeti v2, a full node's Transaction Driver sends each transaction to one validator. That validator checks it and includes it in its next consensus block. From there:
- Owned-object-only transactions (a SUI transfer, say) can be finalized on the fast path. Validators vote on them inside the DAG, without waiting for the transaction to be ordered.
- Transactions with shared objects wait for a consensus commit. The commit order fixes the order of all transactions on each shared object, and execution then runs in parallel across unrelated objects.
Validators turn consensus output into checkpoints, which are certified, hash-linked batches of executed transactions that full nodes and indexers sync from.
Why it matters for developers
- Latency. Sui's docs put end-to-end finality at typically 400–700 ms. See how fast Sui is.
- Contention. Many transactions writing to one hot shared object have to be sequenced one after another. If one commit asks for too much execution on an object, Sui can cancel the excess transactions after consensus. Spread writes across objects where you can.
- No reorgs. Finality is deterministic. Once the effects are certified, the transaction is irreversible, so there's no need to wait for confirmations.
Check it on-chain
The current committee and epoch are visible through GraphQL:
curl -s -X POST https://graphql.mainnet.sui.io/graphql \
-H 'content-type: application/json' \
-d '{"query":"{ epoch { epochId startTimestamp protocolConfigs { protocolVersion } } }"}'At epoch 1291 (25 October 2026) mainnet ran protocol version 139. For more on the protocol itself, see What is Mysticeti?.
Sources
- Consensus, Sui documentation
- Mysticeti v2, Sui blog
- Mysticeti: Reaching the Limits of Latency with Uncertified DAGs, arXiv
- Epochs, Sui documentation