I went back through the Dusk whitepaper last night, focusing on the emergency mode, fallback, and rolling finality sections. The details were more nuanced than I first expected.

Emergency mode activates after 16 failed iterations. Step timeouts are then disabled, and open iterations continue until a candidate block reaches quorum in both validation and ratification. Multiple iterations can run at once, which improves the chance of producing a block but also increases the possibility of forks. If several candidates reach consensus, the lowest iteration is selected. At the last iteration, provisioners can request an emergency block, but it requires provisioners holding a majority of total network stake.

The fallback rules also caught my attention: a block from iteration J > 0 can potentially be replaced by a lower-iteration block that later reaches consensus, while iteration 0 cannot be replaced this way.

Then rolling finality adds another layer. If n previous iterations failed attestation, a block is accepted and needs 2×n consecutive attested or confirmed blocks to become confirmed. The paper's example uses iteration 5, n=2, meaning 4 more blocks are required.

I’m still wondering: does this design create any meaningful centralization risk around stake-weighted emergency recovery?

@Dusk #dusk $DUSK