#dusk $DUSK @Dusk
Missed one vote by forty seconds last month and spent the next hour refreshing my dashboard convinced I'd lost my stake. Turned out I hadn't. That sent me down a rabbit hole into how Dusk's reward system actually works and the design answered that worry better than I expected.

The reward split gives the block generator up to eighty percent of it with a chunk of that extra portion tied to how many credits get included in the certificate. Ten percent goes to a development fund and the last ten splits evenly between validation and ratification committees. Nothing shocking there. What caught my attention was how deliberately weighted toward the generator it is. It felt strange at first that so much goes to one role but it makes sense once you think about who's actually doing the heavy lifting each block.

The part that actually matters is the fault system. Dusk separates minor faults from major ones instead of treating every mistake the same. Miss a vote because your node hiccuped and you get suspended for a bit with some stake temporarily locked. Nothing burned. Do something provably malicious like signing conflicting votes and that's a different category entirely with real stake burned. I remember reading protocols years ago that just torched stake for any downtime and honestly that always felt punitive rather than protective.

Maybe I'm overthinking it but this distinction feels like the real design insight here. It doesn't punish honest operators for infrastructure problems while still making intentional attacks expensive. Whether that balance holds up under real network stress at scale is something I'm still curious about. Slashing systems always look cleaner on paper than they behave once thousands of validators are actually running them.

$TUT
$ZRO
How should Dusk handle validator faults?