#dusk I re-examined Dusk’s penalty mechanism from scratch and found that the easiest thing to misread isn’t the severity of the penalties—it’s that “soft penalties” and “hard penalties” are fundamentally not the same. The official documentation clearly distinguishes them: soft penalties apply to failures in participating in consensus—for example, if a Provisioner doesn’t generate a block or cast votes within the specified time; hard penalties apply to provable malicious behavior—such as signing conflicting proposals for the same height, or running the same consensus secret key on multiple nodes at the same time.
The consequences of the two are vastly different. Soft penalties will suspend your $SNDKB Provisioner eligibility and transfer part of your active stake into locked stake. Note that locked stake still belongs to the staker—it’s just temporarily not involved in consensus and doesn’t generate rewards. This is completely different from having assets directly deducted. Hard penalties are what truly burn a portion of DUSK.
For users coming from the ETH ecosystem, there’s an intuition about ETH 2.0 slashing, but Dusk adds an extra layer of buffering through soft penalties. It gives operators a window to correct things: if you miss a vote due to network fluctuations, it won’t immediately burn coins—but you will be temporarily “benched.” If you deliberately do harm, though, that’s a different story.$SPCXB
For ordinary $DUSK holders, when running a node, what you should focus on isn’t the yield rate—it’s whether “my consensus secret key is running only on a single machine.” The documentation emphasizes this repeatedly, but many people think it’s convenient for cloud servers to set up automatic failover; the result is that the old instance isn’t fully shut down before the new one starts, so two instances are active at the same time—which directly triggers a hard penalty.
So I believe that after @Dusk , what should be displayed in the operations panel isn’t APY, but the node health status, the uniqueness check of the consensus secret key, and whether there’s any risk of soft penalties. Stakers shouldn’t have to dig through the documentation only after something goes wrong.
#dusk @Dusk
The consequences of the two are vastly different. Soft penalties will suspend your $SNDKB Provisioner eligibility and transfer part of your active stake into locked stake. Note that locked stake still belongs to the staker—it’s just temporarily not involved in consensus and doesn’t generate rewards. This is completely different from having assets directly deducted. Hard penalties are what truly burn a portion of DUSK.
For users coming from the ETH ecosystem, there’s an intuition about ETH 2.0 slashing, but Dusk adds an extra layer of buffering through soft penalties. It gives operators a window to correct things: if you miss a vote due to network fluctuations, it won’t immediately burn coins—but you will be temporarily “benched.” If you deliberately do harm, though, that’s a different story.$SPCXB
For ordinary $DUSK holders, when running a node, what you should focus on isn’t the yield rate—it’s whether “my consensus secret key is running only on a single machine.” The documentation emphasizes this repeatedly, but many people think it’s convenient for cloud servers to set up automatic failover; the result is that the old instance isn’t fully shut down before the new one starts, so two instances are active at the same time—which directly triggers a hard penalty.
So I believe that after @Dusk , what should be displayed in the operations panel isn’t APY, but the node health status, the uniqueness check of the consensus secret key, and whether there’s any risk of soft penalties. Stakers shouldn’t have to dig through the documentation only after something goes wrong.
#dusk @Dusk
软惩罚和硬惩罚你分清了吗
100%
Locked Stake能手动解锁吗
0%
共识密钥唯一性怎么验证
0%
1 votes • Voting closed