I was looking at Dusk’s node security docs and one detail made me stop.
Dusk recommends separating the consensus key from the owner key: the node uses the consensus key to vote and sign blocks, while only the owner key can unstake or withdraw the stake.
That sounds like a clean security boundary.
But then I noticed the important part: Dusk says the separate owner key can be another address derived from the same mnemonic, and the setup is most effective when that mnemonic is not stored on the server. The node itself only needs the consensus key file.
So the interesting security boundary may not actually be “two keys” — it’s really about where the recovery secret lives, and what each key can and can’t do if compromised.
If an attacker compromises the node but never gets the mnemonic or owner key, they can’t withdraw the stake. But they can still control the consensus key — which creates a different risk: consensus-level penalties for invalid or conflicting votes.
The owner key protects the principal from direct withdrawal, but it can’t prevent consensus-level penalties if the consensus key is compromised.
That’s a meaningfully different risk profile than simply thinking “two keys = safe.”
Does Dusk’s documented slashing-recovery process fully address a compromised consensus key, or is key rotation still the main practical response? #dusk @Dusk