I went back through the @Dusk documentation last night, specifically the section on their Succinct Attestation consensus. It’s a permissionless, committee-based proof-of-stake setup run by provisioners....anyone who locks at least 1000 DUSK as stake.

A stake is just the amount plus the block height it was included at. Eligibility isn’t immediate. There’s a maturity period calculated as M = 2 × epoch − (height mod epoch), and the epoch is currently 2160 blocks. Only after that maturity window, and if the amount meets the minimum, does the stake enter the deterministic sortition lottery that picks the block generator and the voting committees for each round.

The process itself runs in rounds and iterations. Each iteration has three steps: proposal (one provisioner is selected to put forward a candidate block), validation (a committee votes Valid, Invalid, or NoCandidate, needing a 2/3 supermajority for Valid or a simple majority for Invalid), and ratification (a fresh committee confirms the result). A round can go through up to 50 iterations before it fails.

What I’m still turning over is how the non-interactive sortition and the rotating committees actually affect long-term decentralization and the risk of committee capture. The fixed parameters....1000 DUSK minimum, 2160-block epochs, 50-iteration cap
....feel deliberate, but I couldn’t find a clear discussion of how they might be adjusted later or what governance process would control that.

Curious how others read the security assumptions around the voting committees and the maturity delay. Does the design feel robust to you, or are there edge cases I’m missing?

#dusk $DUSK