Firedancer v26.10.5 fixes a rare epoch-boundary crash, its third release in a week
Victoria Shinder1 min readThe Firedancer team published v26.10.5 on 27 October, labelled a mainnet-ready release. It follows v26.10.3 on 20 October and v26.10.4 on 21 October, making three production builds in eight days.
The v26.10.5 notes list six changes: a fix for a rare issue that could crash the validator at the epoch boundary; better block-packing performance by eagerly dropping expired transactions; improved peer selection for snapshot downloads during validator boot; more reliable connections for voting validators; a GUI change that shows the vote count on the slot carrying the certificate rather than the slot being voted on; and a higher default shred_tile_count in the layout section, now 2.
The two earlier releases were narrower. v26.10.3 improved repair performance through better peer selection and timeouts and improved the performance and reliability of Firedancer's Alpenglow consensus implementation. v26.10.4 fixed a case where Firedancer's gossip table disagreed with Agave's, causing high traffic and busyness, and tuned the repair algorithm for nodes that are falling behind.
What it means
The cadence is the story: three mainnet-ready builds in a week, each fixing behaviour that appears only under live network conditions — gossip disagreement with the other client, a crash at the epoch boundary, catch-up repair. That is what running a second independent client looks like in practice. Operators who changed shred tile settings by hand should check the new default does not silently override their layout.