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.

Dash 0.13 Upgrade Procedure

Dash 0.13.0 implements DIP3, which introduces several changes to how a Dash masternode is set up and operated. A list of available documentation appears below:

It is highly recommended to first read at least the list of changes before continuing in order to familiarize yourself with the new concepts in DIP3. This documentation describes the commands as if they were entered in the Dash Core GUI by opening the console from Tools > Debug console, but the same result can be achieved on a masternode by entering the same commands and adding the prefix ~/.dashcore/dash- cli to each command.

Software update

Begin by updating the Dash software on your masternode following the procedure appropriate for your masternode, as described below. You can use either dashman or the manual procedure to update the software.

Option 1: Updating from dashman

To update Dash using dashman, log in to your server and enter the following commands:

~/dashman/dashman sync
~/dashman/dashman update

Check the status of your masternode:

~/dashman/dashman status

Option 2: Manual update

To update Dash manually, log in to your server using ssh or PuTTY. If your crontab contains an entry to automatically restart dashd, invoke crontab -e and comment out the appropriate line by adding the # character. It should look something like this:

# * * * * * pidof dashd || ~/.dashcore/dashd

Then stop Dash running:

~/.dashcore/dash-cli stop

Visit the GitHub releases page and copy the link to the latest x86_64-linux-gnu version. Go back to your terminal window and enter the following command, pasting in the address to the latest version of Dash Core by right clicking or pressing Ctrl + V:

cd /tmp

Verify the integrity of your download by running the following command and comparing the output against the value for the file as shown in the SHA256SUMS.asc file:

sha256sum dashcore-

Extract the compressed archive, copy the new files to the directory and set them as executable:

tar xfv dashcore-
cp -f dashcore-0.13.0/bin/dashd ~/.dashcore/
cp -f dashcore-0.13.0/bin/dash-cli ~/.dashcore/

Restart Dash:


You will see a message reading “Dash Core server starting”. We will now update Sentinel:

cd ~/.dashcore/sentinel/
git checkout master
git pull

Finally, uncomment the line to automatically restart Dash in your crontab by invoking crontab -e again and deleting the # character.

Dash is now updated.

Generate a BLS key pair

A public/private BLS key pair is required for the operator of the masternode. If you are using a hosting service, they will provide you with their public key, and you can skip this step. If you are hosting your own masternode, generate a BLS public/private keypair as follows:

bls generate

  "secret": "565950700d7bdc6a9dbc9963920bc756551b02de6e4711eff9ba6d4af59c0101",
  "public": "01d2c43f022eeceaaf09532d84350feb49d7e72c183e56737c816076d0e803d4f86036bd4151160f5732ab4a461bd127"

These keys are NOT stored by the wallet and must be kept secure, similar to the value provided in the past by the masternode genkey command. The public key will be used in following steps. The secret key must be entered in the dash.conf file on the masternode. This allows the masternode to watch the network for relevant Pro*Tx transactions, and will cause it to start serving as a masternode when the signed ProRegTx is broadcast by the owner (Step 5 below). Log in to your masternode using ssh or PuTTY and edit the configuration file on your masternode as follows:

nano ~/.dashcore/dash.conf

The editor appears with the existing masternode configuration. Add this line to the end of the file, replacing the key with your BLS secret key generated above:


Press enter to make sure there is a blank line at the end of the file, then press Ctrl + X to close the editor and Y and Enter save the file. We will now prepare the transaction used to register a DIP3 masternode on the network.

Prepare a ProRegTx transaction

First, we need to get a new, unused address from the wallet to serve as the owner address. This is different to the collateral address. It must also be used as the voting address if Spork 15 is not yet active. Generate a new address as follows:



Then either generate or choose an existing second address to receive the owner’s masternode payouts:



Next, we will prepare an unsigned ProRegTx special transaction using the protx register_prepare command. This command has the following syntax:

protx register_prepare collateralHash collateralIndex ipAndPort ownerKeyAddr
  operatorKeyAddr votingKeyAddr operatorReward payoutAddress

Open a text editor such as notepad to prepare this command. Replace each argument to the command as follows:

  • collateralHash: The txid of the 1000 Dash collateral funding transaction
  • collateralIndex: The output index of the 1000 Dash funding transaction
  • ipAndPort: Masternode IP address and port, in the format x.x.x.x:yyyy
  • ownerKeyAddr: The new Dash address generated above for the owner/voting address
  • operatorKeyAddr: The BLS public key generated above (or provided by your hosting service)
  • votingKeyAddr: The new Dash address generated above, or the address of a delegate, used for proposal voting
  • operatorReward: The percentage of the block reward allocated to the operator as payment
  • payoutAddress: A new or existing Dash address to receive the owner’s masternode rewards

Note that the operator is responsible for specifying their own reward address in a separate update_service transaction if you specify a non-zero operatorReward. The owner of the masternode collateral does not specify the operator’s payout address.

Example (remove line breaks if copying):

protx register_prepare


  "tx": "030001000191def1f8bb265861f92e9984ac25c5142ebeda44901334e304c447dad5adf6070000000000feffffff0121dff505000000001976a9149e2deda2452b57e999685cb7dabdd6f4c3937f0788ac00000000d1010000000000c7fd27022913dd8505ae701e0fd56625c3fa9d2ff47802225faae562389e492c0100000000000000000000000000ffff8c523b334e1fad8e6259e14db7d05431ef4333d94b70df1391c601d2c43f022eeceaaf09532d84350feb49d7e72c183e56737c816076d0e803d4f86036bd4151160f5732ab4a461bd127ad8e6259e14db7d05431ef4333d94b70df1391c600001976a914adf50b01774202a184a2c7150593442b89c212e788acf8d42b331ae7a29076b464e61fdbcfc0b13f611d3d7f88bbe066e6ebabdfab7700",
  "collateralAddress": "yPd75LrstM268Sr4hD7RfQe5SHtn9UMSEG",
  "signMessage": "ycBFJGv7V95aSs6XvMewFyp1AMngeRHBwy|0|yc98KR6YQRo1qZVBhp2ZwuiNM7hcrMfGfz|yc98KR6YQRo1qZVBhp2ZwuiNM7hcrMfGfz|54e34b8b996839c32f91e28a9e5806ec5ba5a1dadcffe47719f5b808219acf84"

We will use the collateralAddress and signMessage fields in Step 4, and the output of the tx field in Step 5.

Sign the ProRegTx transaction

Now we will sign the content of the signMessage field using the private key for the collateral address as specified in collateralAddress. Note that no internet connection is required for this step, meaning that the wallet can remain disconnected from the internet in cold storage to sign the message. In this example we will again use Dash Core, but it is equally possible to use the signing function of a hardware wallet. The command takes the following syntax:

signmessage address message


signmessage yPd75LrstM268Sr4hD7RfQe5SHtn9UMSEG ycBFJGv7V95aSs6XvMewFyp1AMngeRHBwy|0|yc98KR6YQRo1qZVBhp2ZwuiNM7hcrMfGfz|yc98KR6YQRo1qZVBhp2ZwuiNM7hcrMfGfz|54e34b8b996839c32f91e28a9e5806ec5ba5a1dadcffe47719f5b808219acf84



Submit the signed message

We will now create the ProRegTx special transaction on the network to start the masternode. This command must be sent from a Dash Core wallet holding a balance, since a standard transaction fee is involved. The command takes the following syntax:

protx register_submit tx sig


  • tx: The serialized transaction previously returned in the tx output field from protx register_prepare in Step 2
  • sig: The message signed with the collateral key from Step 3


protx register_submit 030001000191def1f8bb265861f92e9984ac25c5142ebeda44901334e304c447dad5adf6070000000000feffffff0121dff505000000001976a9149e2deda2452b57e999685cb7dabdd6f4c3937f0788ac00000000d1010000000000c7fd27022913dd8505ae701e0fd56625c3fa9d2ff47802225faae562389e492c0100000000000000000000000000ffff8c523b334e1fad8e6259e14db7d05431ef4333d94b70df1391c601d2c43f022eeceaaf09532d84350feb49d7e72c183e56737c816076d0e803d4f86036bd4151160f5732ab4a461bd127ad8e6259e14db7d05431ef4333d94b70df1391c600001976a914adf50b01774202a184a2c7150593442b89c212e788acf8d42b331ae7a29076b464e61fdbcfc0b13f611d3d7f88bbe066e6ebabdfab7700 IMf5P6WT60E+QcA5+ixors38umHuhTxx6TNHMsf9gLTIPcpilXkm1jDglMpK+JND0W3k/Z+NzEWUxvRy71NEDns=



Your masternode is now upgraded to DIP3 and will appear on the Deterministic Masternode List. You can view this list on the Masternodes -> DIP3 Masternodes tab of the Dash Core wallet, or in the console using the command protx list valid, where the txid of the final protx register_submit transaction identifies your DIP3 masternode. Note again that all functions related to DIP3 will only take effect once Spork 15 is enabled on the network. You can view the spork status using the spork active command.

Updating Masternode Information

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 change in percentage of the reward allocated to an operator. 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.


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 scriptOperatorPayout field in the ProUpServTx. If scriptOperatorPayout is not set and operatorReward is non-zero, the owner gets the full masternode reward. The ProUpServTx takes the following syntax:

protx update_service proTxHash ipAndPort operatorKey (operatorPayoutAddress)


  • proTxHash: The hash of the initial ProRegTx
  • ipAndPort: IP and port in the form “ip:port”
  • operatorKey: The operator BLS private key associated with the registered operator public key
  • operatorPayoutAddress (optional): The address used for operator reward payments. Only allowed when the ProRegTx had a non-zero operatorReward value.


protx update_service d6ec9a03e1251ac8c34178f47b6d763dc4ea6d96fd6eddb3c7aae2359e0f474a 4308daa8de099d3d5f81694f6b618381e04311b9e0345b4f8b025392c33b0696 yf6Cj6VcCfDxU5yweAT3NKKvm278rVbkhu


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


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. The ProUpRegTx takes the following syntax:

protx update_registrar proTxHash operatorKeyAddr votingKeyAddr payoutAddress


  • proTxHash: The transaction id of the initial ProRegTx
  • operatorKeyAddr: An updated BLS public key, or 0 to use the last on-chain operator key
  • votingKeyAddr: An updated voting key address, or 0 to use the last on-chain operator key
  • payoutAddress: An updated Dash address for owner payments, or 0 to use the last on-chain operator key

Example to update payout address:

protx update_registrar cedce432ebabc9366f5eb1e3abc219558de9fbd2530a13589b698e4bf917b8ae 0 0 yi5kVoPQQ8xaVoriytJFzpvKomAQxg6zea


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). The ProUpRevTx takes the following syntax:

protx revoke proTxHash operatorKey reason


  • proTxHash: The transaction id of the initial ProRegTx
  • operatorKey: The operator BLS private key associated with the registered operator public key
  • reason (optional): Integer value indicating the revocation reason


protx revoke 9f5ec7540baeefc4b7581d88d236792851f26b4b754684a31ee35d09bdfb7fb6 565950700d7bdc6a9dbc9963920bc756551b02de6e4711eff9ba6d4af59c0101

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:


Adding a masternode to DashCentral

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:


Adding voting privkeys to DashCentral

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:


Verifying ownership of your masternode to DashCentral

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:


Signing a message from the Trezor Wallet

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.


Masternode ownership has been successfully verified

Installing the DashCentral monitoring script

DashCentral offers a service to monitor your masternode, automatically restart dashd in the event of a crash and send email in the event of an error. Go to the Account settings page and generate a new API key, adding a PIN to your account if necessary. Scroll to the following screen:


Setting up the DashCentral monitoring script

Copy the link to the current version of the dashcentral script by right- click and selecting Copy link address. Open PuTTY and connect to your masternode, then type:


Replace the link with the current version of dashcentral-updater as necessary. Decompress the archive using the following command:

tar xvzf dashcentral-updater-v6.tgz

View your masternode configuration details by typing:

cat .dashcore/dash.conf

Copy the values for rpcuser and rpcpassword. Then edit the dashcentral configuration by typing:

nano dashcentral-updater/dashcentral.conf

Replace the values for api_key, your masternode collateral address, rpc_user, rpc_password, daemon_binary and daemon_datadir according to your system. A common configuration, where lwhite is the name of the Linux user, may look like this:


DashCentral updater configuration file

# dashcentral-updater configuration

our %settings = (
    # Enter your DashCentral api key here
    'api_key' => 'api_key_from_dashcentral'

our %masternodes = (
    'masternode_collateral_address' => {
        'rpc_host'           => 'localhost',
        'rpc_port'           => 9998,
        'rpc_user'           => 'rpc_user_from_dash.conf',
        'rpc_password'       => 'rpc_password_from_dash.conf',
        'daemon_autorestart' => 'enabled',
        'daemon_binary'      => '/home/<username>/.dashcore/dashd',
        'daemon_datadir'     => '/home/<username>/.dashcore'

Press Ctrl + X to exit, confirm you want save with Y and press Enter. Test your configuration by running the dashcentral script, then check the website. If it was successful, you will see that an update has been sent:


Manually testing the DashCentral updater


DashCentral updater has successfully sent data to the DashCentral site

Once you have verified your configuration is working, we can edit the crontab on your system to schedule the dcupdater script to run every 2 minutes. This allows the system to give you early warning in the event of a fault and will even restart the dashd daemon if it hangs or crashes. This is an effective way to make sure you do not drop off the payment queue. Type the following command:

crontab -e

Select an editor if necessary and add the following line to your crontab after the line for sentinel, replacing lwhite with your username on your system:

*/2 * * * * /home/lwhite/dashcentral-updater/dcupdater

Editing crontab to run the DashCentral updater automatically

Press Ctrl + X to exit, confirm you want save with Y and press Enter. The dcupdater script will now run every two minutes, restart dashd whenever necessary and email you in the event of an error.

Masternode monitoring tools

Several sites operated by community members are available to monitor key information and statistics relating to the masternode network.

Block Explorers

Since Dash is a public blockchain, it is possible to use block explorers to view the balances of any Dash public address, as well as examine the transactions entered in any given block. Each unique transaction is also searchable by its txid. A number of block explorers are available for the Dash network.

Dash Masternode Tool

Written and maintained by community member Bertrand256, Dash Masternode Tool (DMT) allows you to start a masternode from all major hardware wallets such as Trezor, Ledger and KeepKey. It also supports functions to vote on proposals and withdraw masternode payments without affecting the collateral transaction.

DASH Ninja

DASH Ninja, operated by forum member and Dash Core developer elbereth, offers key statistics on the adoption of different versions of Dash across the masternode network. Several features to monitor governance of the Dash, the masternode payment schedule and the geographic distribution of masternodes are also available, as well as a simple blockchain explorer.


DashCentral, operated by forum member rango, offers an advanced service to monitor masternodes and vote on budget proposals through an advanced web interface. An Android app is also available., operated by forum member and Dash Core developer moocowmoo, offers sequential reports on the price, generation rate, blockchain information and some information on masternodes.

Dash Masternode Information

This site, operated by forum member and Dash Core developer crowning, offers a visual representation of many key statistics of the Dash masternode network, including graphs of the total masternode count over time, price information and network distribution.