I went back through the Dusk documentation last night, and the incentive section made me slow down and read it twice.
What I first understood as a simple validator reward is more nuanced. Block rewards come from newly minted DUSK and transaction fees, with 80% going to the block generator, 10% to the voting committee, and 10% to Dusk. The generator’s 80% is split into a fixed 70% and a variable 10%, where the variable part depends on votes included in the block certificate. Voter rewards are based on credits, so voting power and incentives are closely connected.
That raised a question for me: does rewarding higher-credit voters strengthen participation, or could it gradually concentrate influence among already-strong provisioners?
The security side is also interesting. Minor faults can lead to suspension and soft slashing, while major faults such as invalid blocks, double voting, or conflicting blocks can trigger hard slashing.
Then I reached transactions. Dusk uses two models: Moonlight, an account-based model with public keys, and Phoenix, a UTXO-based model using ZK proofs for privacy. The contrast is clear, but I’m still wondering how these two models affect long-term decentralization and governance in practice.
How do you view the trade-off between voter credits, penalties, and decentralization?
@Dusk_Foundation #dusk $DUSK
What I first understood as a simple validator reward is more nuanced. Block rewards come from newly minted DUSK and transaction fees, with 80% going to the block generator, 10% to the voting committee, and 10% to Dusk. The generator’s 80% is split into a fixed 70% and a variable 10%, where the variable part depends on votes included in the block certificate. Voter rewards are based on credits, so voting power and incentives are closely connected.
That raised a question for me: does rewarding higher-credit voters strengthen participation, or could it gradually concentrate influence among already-strong provisioners?
The security side is also interesting. Minor faults can lead to suspension and soft slashing, while major faults such as invalid blocks, double voting, or conflicting blocks can trigger hard slashing.
Then I reached transactions. Dusk uses two models: Moonlight, an account-based model with public keys, and Phoenix, a UTXO-based model using ZK proofs for privacy. The contrast is clear, but I’m still wondering how these two models affect long-term decentralization and governance in practice.
How do you view the trade-off between voter credits, penalties, and decentralization?
@Dusk_Foundation #dusk $DUSK