Guys, Yesterday I went back through the $DUSK documentation last night, and the more I read about Rolling Finality, the more I realized that “final” is not one vote.

The document describes a block moving through accepted, attested, confirmed, and finally final states. What caught my attention is that finality can depend on the sequence of higher- and lower-priority iterations, rather than a single fixed confirmation count. I’m still trying to understand how this behaves under delayed or failed attestations.

The incentives section was even more interesting. Block rewards are split into 80% for the block generator, 10% for the voting committee, and 10% for Dusk. The generator’s 80% itself has a 70% fixed portion and a 10% variable portion linked to votes included in the certificate. Voter rewards are proportional to credits, with the voting reward divided into 64 quotas.

That makes me wonder about decentralization: does rewarding higher-credit voters strengthen participation, or could it gradually concentrate influence?

The transaction section also separates Moonlight, an account-based model, from Phoenix, a UTXO based model using zero knowledge proofs for privacy.

My questions are: how quickly does Rolling Finality resolve edge cases, and how robust is the reward design against validator concentration?

#dusk $DUSK @Dusk