Masternodes require regular maintenance to ensure you do not drop off the payment queue. This includes promptly installing updates to Dash, as well as maintaining the security and performance of the server. In addition, masternodes should vote on proposals and perform other tasks in the interest of the network and the value of the Dash they hold.

A Provider Update Revocation Transaction (ProUpRevTx) is used by the operator to terminate service or signal the owner that a new BLS key is required. It will immediately put the masternode in the PoSe-banned state. The owner must then issue a ProUpRegTx to set a new operator key. After the ProUpRegTx is mined to a block, the new operator must issue a ProUpServTx to update the service-related metadata and clear the PoSe- banned state (revive the masternode). A ProUpRevTx can be created from DMT by clicking the Revoke operator button, or from Dash Core using the following syntax:

A Provider Update Registrar Transaction (ProUpRegTx) is used to update information relating to the owner. An owner can update the operator’s BLS public key (e.g. to nominate a new operator), the voting address and their own payout address. A ProUpRegTx can be created from DMT by clicking the Update operator key , Update voting key or Update payout addr. buttons, or from Dash Core using the following syntax:

The masternode is now removed from the PoSe-banned list, and the IP:port and operator reward addresses are updated.

A Provider Update Service Transaction (ProUpServTx) is used to update information relating to the operator. An operator can update the IP address and port fields of a masternode entry. If a non-zero operatorReward was set in the initial ProRegTx, the operator may also set the operatorPayoutAddress field in the ProUpServTx. If operatorPayoutAddress is not set and operatorReward is non-zero, the owner gets the full masternode reward. A ProUpServTx can be created from DMT by clicking the Update service button, or from Dash Core using the following syntax:

Configuration changes which affect the provision of service to the network, such as the BLS operator key and IP address, will reset your position in the payment queue. Changes to the voting or various payout addresses will not reset your position in the payment queue.

Periodically, it may be necessary to update masternode information if any information relating to the owner or operator changes. Examples may include a change in IP address, change in owner/operator payout address or changes to the nominated voting/operator keys. It is also possible to revoke a masternode’s registered status (in the event of a security breach, for example) to force both owner and operator to update their details.

Once you are certain these settings are correct, you can update your service status on the network and return to the valid set of masternodes by creating a ProUpServTx . Monitor your masternode closely using masternode status and/or the debug.log file after restoring service. This information can help you pinpoint the specific misconfiguration that is causing the masternode to be banned. The masternode will be banned again if it continues to fail to provide service.

If your masternode fails to provide service to the network in accordance with the current consensus rules, it will receive a Proof of Service Ban . If your masternode is in the POSE_BANNED status, you should check the following settings are configured correctly:

DashCentral voting, verification and monitoring¶

DashCentral is a community-supported website managed by community member Rango. It has become a de facto site for discussion of budget proposals and to facilitate voting from a graphical user interface, but also offers functions to monitor masternodes.

Adding your masternode to DashCentral¶ Dashcentral allows you to vote on proposals from the comfort of your browser. After completing registration, go to the masternodes page and click the Add masternode now button. Enter your collateral address on the following screen: Click Add masternode. Your masternode has now been added to DashCentral.

Enabling voting from DashCentral¶ Click Edit under Voting privkeys to enter your masternode private key to enable voting through the DashCentral web interface. Enter a voting passphrase (not the same as your login password, but equally important to remember!) and enter the private key (the same key you used in the dash.conf file on your masternode) on the following screen: It is important to note that the private key to start your masternode is unrelated to the private keys to the collateral address storing your 1000 DASH. These keys can be used to issue commands on behalf of the masternode, such as voting, but cannot be used to access the collateral. The keys are encrypted on your device and never stored as plain text on DashCentral servers. Once you have entered the key, click Store encrypted voting privkeys on server. You can now vote on proposals from the DashCentral web interface.

Verifying ownership¶ You can also issue a message from your address to verify ownership of your masternode to DashCentral. Click Unverified under Ownership and the following screen will appear: Instructions on how to sign your collateral address using a software wallet appear. If you are using a hardware wallet other than Trezor, you will need to use the DMT app to sign the address. If you are using the Trezor hardware wallet, go to your Trezor wallet, copy the collateral address and click Sign & Verify. The following screen will appear, where you can enter the message provided by DashCentral and the address you wish to sign: Click Sign, confirm on your Trezor device and enter your PIN to sign the message. A message signature will appear in the Signature box. Copy this signature and paste it into the box on DashCentral and click Verify ownership. Verification is now complete.