Data center goes offline for ten minutes, and with the same key you can produce two conflicting results—can they be punished with the same severity? If the answer is “burn all the coins,” I’m actually afraid to run a node.
I rechecked the current staking rules for @Dusk . Dusk divides consensus penalties into two categories: soft and hard, but the real boundary is not whether the node owner’s mouth says anything malicious—it’s the evidence left on-chain.
Soft penalties target failed participation, such as being unable to produce a valid candidate block. The protocol can pause a node’s eligibility and move part of the active stake into locked stake. The chips still belong to the staker, but temporarily they lose the ability to participate in consensus and earn rewards.
Hard penalties deal with provably invalid behavior, including invalid votes and duplicate signature(s) for conflicting proposals or repeated voting. In addition to pausing eligibility, the protocol can directly destroy part of the stake, because the signature itself already constitutes evidence of breaking consensus.
The protocol does not judge for the node whether it was an attack or a slip of the hand. The official especially reminds that the same consensus key must not be running on two active nodes at the same time. During migration, if the old node hasn’t stopped yet and the new node starts signing, operational accidents can also generate conflict messages and trigger hard penalties.
So staking risk can’t be judged only by APY. Soft penalties affect effective staking and downtime-related earnings, while hard penalties may hit the principal. I’ll watch fault count, locked stake, suspension duration, and conflicting signatures. $DUSK staking is not a deposit; it’s a guarantee of a production system that stays online continuously, with keys that are unique.
#dusk $DUSK