It’s best not to bind node control rights and full asset control rights to the same key.
When validating nodes, the key that signs consensus messages needs to be online frequently, while the key that holds ownership of staked assets is better suited for low-frequency use and offline storage. If these two permissions are fully bound to the same hot key, a single server compromise could simultaneously affect both node behavior and asset control, unnecessarily expanding the attack surface.
A reasonable key distribution should separate “participation in consensus on behalf of the node” from “transferring or managing ownership.” If the consensus key has a problem, operators can shut down, rotate, or reconfigure it—without exposing all assets to the online environment for the long term. Asset owners can also retain final control, without handing the highest privileges to day-to-day operators.
This design also changes accountability within an institution. The technical team is responsible for node availability, while the finance or security team manages the ownership key(s). Sensitive changes require approvals from multiple parties. Logs should record who initiated the rotation, when it takes effect, and when the old key becomes invalid. If the boundary between permissions exists only in documentation, and in practice the mnemonic is still kept on the same server, then the separation has no meaning.
The rotation process itself must also avoid any gaps. You need to define the order: when the new consensus key starts to be effective, whether the old key can still sign, and how the network recognizes the change. If ownership-key approval is required for operations, then the transactions must be prepared and rechecked in an offline environment. Key isolation is not a one-time configuration—it’s a lifecycle spanning creation, rotation, recovery, and exit.
Regular drills can verify that the documentation has not expired and confirm that, even when key personnel are absent, the organization can still complete recovery according to the established permissions.
I hope the @Dusk node tool keeps making key isolation the default path, rather than an option only for advanced users. A very practical acceptance criterion is: after the consensus server is completely damaged, can the operator safely recover without migrating staked assets? And while the ownership key is offline, can the node still perform its duties properly? Only when high-frequency operations are separated from high-value privileges will the network be able to put security principles into the daily configurations of every Provisioner. $DUSK #Dusk.
When validating nodes, the key that signs consensus messages needs to be online frequently, while the key that holds ownership of staked assets is better suited for low-frequency use and offline storage. If these two permissions are fully bound to the same hot key, a single server compromise could simultaneously affect both node behavior and asset control, unnecessarily expanding the attack surface.
A reasonable key distribution should separate “participation in consensus on behalf of the node” from “transferring or managing ownership.” If the consensus key has a problem, operators can shut down, rotate, or reconfigure it—without exposing all assets to the online environment for the long term. Asset owners can also retain final control, without handing the highest privileges to day-to-day operators.
This design also changes accountability within an institution. The technical team is responsible for node availability, while the finance or security team manages the ownership key(s). Sensitive changes require approvals from multiple parties. Logs should record who initiated the rotation, when it takes effect, and when the old key becomes invalid. If the boundary between permissions exists only in documentation, and in practice the mnemonic is still kept on the same server, then the separation has no meaning.
The rotation process itself must also avoid any gaps. You need to define the order: when the new consensus key starts to be effective, whether the old key can still sign, and how the network recognizes the change. If ownership-key approval is required for operations, then the transactions must be prepared and rechecked in an offline environment. Key isolation is not a one-time configuration—it’s a lifecycle spanning creation, rotation, recovery, and exit.
Regular drills can verify that the documentation has not expired and confirm that, even when key personnel are absent, the organization can still complete recovery according to the established permissions.
I hope the @Dusk node tool keeps making key isolation the default path, rather than an option only for advanced users. A very practical acceptance criterion is: after the consensus server is completely damaged, can the operator safely recover without migrating staked assets? And while the ownership key is offline, can the node still perform its duties properly? Only when high-frequency operations are separated from high-value privileges will the network be able to put security principles into the daily configurations of every Provisioner. $DUSK #Dusk.