#dusk $DUSK @Dusk

I was looking at Dusk’s Fallback mechanism and one thing stood out to me: the iteration number actually matters a lot when a fork happens.

Because Dusk’s consensus is asynchronous, messages can arrive late or get lost during congestion. So different parts of the network may see different blocks, and sometimes more than one candidate can get quorum in the same round.

The basic rule is that the lower iteration gets priority. If a block from iteration 1 gets accepted but an iteration 0 block later gets quorum, the lower-iteration block can replace it. The node reverts to the state before the old block and reorganizes the chain.

That makes iteration 0 interesting. Iteration 0 is the first attempt, followed by iteration 1, 2, and so on. Since there is no iteration -1, an iteration 0 block can't be directly replaced through Fallback by a lower iteration.

But I wouldn't call that complete finality. An iteration 0 block can still be affected if an ancestor is reverted. Actual finality comes through Rolling Finality.

So the way I see it, Fallback is more than just fork cleanup. The iteration number gives the network a deterministic way to choose between competing blocks, with iteration 0 sitting at the bottom of that priority order.