IOTA’s Starfish consensus design is being positioned as a deliberate divergence from Sui’s Mysticeti V2, even though both trace their lineage to Mysticeti’s DAG-based Byzantine fault tolerant architecture. In a technical note shared by IOTA and written by Kowei, IOTA Asia Ecosystem Lead, the split is framed not as a simple performance contest, but as a difference in protocol priorities: Sui focuses on reducing end-to-end product latency, while IOTA targets liveness, dissemination, and availability guarantees.
If you want to get deeper technical knowledge of our protocol, and specifically Starfish – @kowei1995 has got you covered with this excellent article. Have a read! https://t.co/wdTklasvvt
— IOTA (@iota) May 26, 2026
IOTA Starfish Breaks From Sui’s Mysticeti Path
Mysticeti v1’s central design choice was to remove explicit certification and let the DAG structure function as a “virtual certificate.” Kowei summarized the trade-off directly: “Mysticeti v1 is built on a bold trade-off: it gives up explicit certification and lets the DAG structure itself act as a virtual certificate. Its direct rule can decide leader blocks in three message delays under ideal conditions, while a more practical single-leader-per-round comparison puts Mysticeti closer to 4δ.” That design helped reduce latency, but also created open questions around strict liveness, block availability, and dissemination under stress.
The split between Sui and IOTA begins from that shared baseline. Sui’s Mysticeti V2 treats the consensus core as largely optimized and moves transaction validation into the consensus flow, replacing the older Quorum Driver with a Transaction Driver. Kowei wrote that “Sui → Mysticeti v2 treats the consensus core as nearly optimal and folds Sui’s pre-consensus transaction validation into consensus, optimizing system integration and product latency. IOTA → Starfish treats dissemination and liveness as structurally fragile, rebuilding dissemination as a first-class part of consensus and optimizing robustness plus provable liveness, at the cost of a latency tax.”
Starfish, by contrast, effectively reintroduces certification in a lighter form through Data Availability Certificates that accumulate inside the DAG rather than through a separate per-block round trip. The note describes this as a new point between uncertified DAGs and older certified DAG systems such as Narwhal and Bullshark. “The certificate Starfish brings back is not the certified-DAG style certificate that is synchronous and per block. It is a Data Availability Certificate lazily accumulated on the DAG.”
Why Starfish Prioritizes Liveness Over Speed
The Starfish design separates block headers from transaction payloads, uses Reed-Solomon erasure coding, and requires only f+1 valid fragments to reconstruct payload data once availability has been acknowledged by 2f+1 validators. That matters because Mysticeti’s uncertified design removed the built-in availability proof that came with certified DAGs. In Kowei’s framing, the issue is not whether Mysticeti is fast, but whether the dissemination layer is robust enough when the network is overloaded or validators fall out of sync.
Starfish also introduces a Push pacemaker to address the liveness gap identified in Mysticeti-style uncertified DAGs. Kowei explains the intuition as follows: “You cannot move forward empty-handed. A validator must first produce its own block for the current round before advancing to the next.” The mechanism is designed to prevent honest nodes from advancing rounds without contributing blocks, a behavior that can leave holes in the DAG and prevent the witness-and-confirmation pattern needed for commits.
The trade-off is measurable. Kowei’s analysis places Mysticeti’s ideal direct-decision case at 3δ for leader blocks, while a cleaner practical comparison puts Mysticeti near 4δ and Starfish around 5δ. “So Starfish still pays a latency premium, but it is closer to a one-message-delay premium in the clean comparison, not a dramatic gap. The real trade is latency and bandwidth for tighter tail behavior, availability, and provable liveness.” In that framing, Sui’s path is aligned with happy-path latency and high-throughput user-facing applications, while IOTA’s Starfish path is aligned with predictability and stronger guarantees under degraded conditions.
The IOTA-Sui divergence shows how two networks can inherit the same consensus architecture and optimize for different operating assumptions. Sui’s Mysticeti V2 reduces surrounding transaction-validation overhead to improve product latency, while IOTA’s Starfish accepts additional latency and bandwidth costs to strengthen dissemination, availability, and liveness. The result is not a single winner, but a clearer map of the trade-offs now shaping DAG-based BFT consensus.
AI Transparency Note: This article was prepared with the assistance of an AI system based on the sources listed and was reviewed, edited, and approved by a human editor before publication. All quotes, data points, and factual claims are intended to be grounded in the cited source material; however, errors cannot be ruled out entirely.
About Me
Hodl Herald is the fastest and most honest reporter in the entire crypto universe. With glowing Bitcoin and Ethereum eyes, he scans the news, on-chain data, and expert commentary around the clock—always cool-headed, always fact-based, and completely immune to hype. No moonboy promises, no fake analysts, no paid shills. Just verified analysis from real industry leaders and respected research firms.
Of course, even the best AI journalist is not perfect. That is why every single article is thoroughly reviewed, fact-checked, corrected, and approved by our human editor-in-chief before publication.
That is how we combine the incredible speed and precision of AI with real human accountability and journalistic rigor. Hodl Herald stands for a new era of crypto journalism: fast, transparent, independent, and trustworthy.
Hodl on—the future has a robot.
