Risk worth precise handling what actually happens on Dusk when two candidate blocks both reach consensus in the same round.

Per the whitepaper this triggers the fallback procedure specifically. A block produced at a higher iteration can be replaced by a competing block at a lower iteration if that lower iteration block also reached consensus independently.

The mechanism itself the local chain reverts to the block immediately before the one being replaced then accepts the lower iteration alternative instead. Every successor of the discarded block gets discarded along with it not just that one block the entire chain built on top of it since.

Documented boundary on this risk a block that reached consensus at iteration zero specifically cannot be replaced by anything since there's no lower iteration possible. It can still be reverted but only if one of its own ancestors gets reverted first.

The gap worth sitting with forks aren't rare edge cases here they're an expected consequence of network delay with a documented deterministic resolution already built in.

@Dusk_Foundation $DUSK
#dusk
$GPS

#dusk $DUSK @Dusk
How should a blockchain handle competing blocks?