#dusk $DUSK @Dusk $DUSK

Proposal, Validation, Ratification: Dusk's Three-Step Path to a Final Block

i kept assuming block finality on Dusk worked like a single vote — propose, confirm, done.

it's actually three separate steps, and i had to walk through each one to see why.

the Proposal step picks one provisioner, via deterministic sortition, to generate a candidate block and broadcast it. if nothing arrives before the timeout, that iteration just fails — no candidate, and as far as i can tell from what's documented, no fallback generator steps in either.

i traced what happens next. the output feeds into Validation: a fresh committee, also randomly selected, checks the candidate against the current chain tip and votes Valid or Invalid. a quorum needs two-thirds voting Valid, or a simple majority voting Invalid — either threshold ends the step.

third step, and this is the one i almost missed the point of: Ratification. yet another committee, voting specifically on whether Validation actually reached a real quorum, not on the block's content again. same two-thirds-or-majority rule applies here too.

three committees, three separate judgments — i couldn't find any step repeating a job the previous one already did.

what stood out to me is how much scrutiny this sequence got before mainnet. Dusk ran ten audits across its whole stack, over two hundred pages of reporting. one of those ten, by Oak Security, covered SA specifically, flagging issues around slashing incentives and voting logic — all critical ones resolved before launch.

so "finalizing a block" isn't one decision, as far as i can tell. it's three independently-verified checks stacked in sequence, each capable of restarting the process — up to fifty iterations per round — if it doesn't pass.

does that level of pre-launch scrutiny actually reduce risk here, or does it just mean any flaw that slips through is that much harder to find later?