#dusk $DUSK @Dusk Dusk's consensus, Succinct Attestation (SA), is a committee-based, permissionless proof-of-stake protocol. Eligible provisioners are chosen through deterministic, stake-weighted sortition to form small committees per round; these committees propose, validate, and ratify blocks using aggregated signatures rather than requiring the full validator set to weigh in on every block. Dusk's documentation describes transactions progressing through four states: Accepted (received and valid), Confirmed (included in a block with later blocks building on it), Stable (buried deep enough to be very unlikely to reverse), and Final (deterministically, cryptographically guaranteed irreversible). This is explicitly contrasted with Nakamoto-style consensus, where blocks are never absolutely final and are treated as "probably safe" after enough confirmations pile up.
Most chains give users exactly one signal — confirmation count — and leave it to the user to decide what's "enough." Dusk's four-stage model makes explicit what's usually left implicit: different actors need different certainty thresholds at different times. A retail transfer might reasonably treat "Confirmed" as sufficient; a securities settlement almost certainly needs "Final." Compared to purely probabilistic systems, SA trades some decentralization surface (only a committee attests per block) for an explicit, bounded point where finality stops being probabilistic and becomes absolute.
Exposing four finality states is more honest about how settlement actually works, but it also pushes a decision onto the user or application layer — which stage is "enough" for this transaction. Does surfacing the real structure of finality help users make better-calibrated decisions, or does the added granularity mostly get abstracted away by wallets and apps anyway?
Most chains give users exactly one signal — confirmation count — and leave it to the user to decide what's "enough." Dusk's four-stage model makes explicit what's usually left implicit: different actors need different certainty thresholds at different times. A retail transfer might reasonably treat "Confirmed" as sufficient; a securities settlement almost certainly needs "Final." Compared to purely probabilistic systems, SA trades some decentralization surface (only a committee attests per block) for an explicit, bounded point where finality stops being probabilistic and becomes absolute.
Exposing four finality states is more honest about how settlement actually works, but it also pushes a decision onto the user or application layer — which stage is "enough" for this transaction. Does surfacing the real structure of finality help users make better-calibrated decisions, or does the added granularity mostly get abstracted away by wallets and apps anyway?