- IOTA’s Starfish sends key data early, helping validators avoid long waits for missing blocks when the network comes under pressure.
- IOTA uses Reed-Solomon encoding and DAG checks to recover payloads without pushing full transaction data to every validator.
IOTA has moved Starfish consensus onto Mainnet through the v1.21.1 release and protocol version 24. The upgrade gives the network a new consensus design built for real-world conditions, where validators must keep data moving even when nodes slow down, messages arrive late, or some participants behave incorrectly.
Consensus usually centers on agreement. Validators must agree on the same history, even under pressure. However, Starfish treats synchronization as part of that same problem. A validator cannot vote on a block it has not seen. It can also not certify transaction data that it cannot rebuild. For that reason, Starfish places data movement inside the protocol rather than leaving it as a separate network task.
"The honest move is to help the network advance."
Starfish is live on the IOTA Mainnet – and @NaitsabesMue from our Research team breaks down the technical design decisions, the tradeoffs, and what the data shows on the IOTA blog. pic.twitter.com/78f0x5f8wz
— IOTA (@iota) May 7, 2026
IOTA’s directed acyclic graph (DAG) records how blocks refer to earlier blocks. Those links show what validators have already seen and where the network still has gaps. When references appear across many validators, the network shows shared knowledge, and when they go missing, the structure exposes where synchronization failed.
IOTA’s earlier Mysticeti consensus model relied more on pull behavior. In that setup, a validator asked peers for missing blocks after it detected a gap. Pull saves bandwidth in calm conditions but adds latency when the network runs under stress. Each missing item creates another request, another wait, and another recovery step.
IOTA activated its Starfish consensus upgrade on mainnet as part of its push to support real-world trade infrastructure tied to a $35 trillion global market. The upgrade helps the network stay resilient when some nodes lag or disconnect.
IOTA’s Starfish Uses Push to Reduce Recovery Delays
Starfish changes that pattern with a push-based approach. Validators move useful information forward before others request it. This gives lagging nodes the data they likely need before the missing-history problem reaches the critical path. IOTA’s outbound request graph shows this change clearly, with Starfish reducing pull requests by about one order of magnitude compared with Mysticeti.
The design does not push everything in full. Starfish separates metadata from transaction payloads. Headers carry references, votes, acknowledgments, timing details, and payload commitments. Transaction data moves separately. This keeps the consensus path lighter while still giving validators enough information to keep the DAG healthy.
Reed-Solomon encoding supports that structure. Starfish breaks a block’s transaction payload into fragments, with one fragment assigned per validator. The original payload can be rebuilt from any sufficient subset of valid fragments. In Starfish, any f+1 valid fragments can reconstruct the payload, while 2f+1 acknowledgments create the availability condition needed for safety under Byzantine assumptions.
Therefore, Starfish does not require every validator to hold the full payload at the same time. Instead, it proves that enough verified pieces exist across honest validators to rebuild the data. As the DAG grows, later blocks carry the evidence that earlier payloads remain recoverable.
Performance data explains why IOTA accepted that trade-off. Starfish uses more bandwidth than Mysticeti during the tested period, but the added communication happens earlier and follows a structured path. Instead of waiting for validators to request missing data, the protocol sends useful information ahead of time, which lowers recovery costs later and helps the network stay aligned under pressure
The performance picture also concerns variance. Starfish adds an availability step before sequencing, which can slightly raise ordinary transaction latency. However, the slower cases improve, and the network spends less time recovering from missing information.
