Incentivized Testnet

Rolling Incentivized Testnet

As Dusk Network’s protocol evolves towards the next phase of Testnet, unique opportunities arise for those passionate (and savvy) enough to get involved in the process. The rolling Incentivized Testnet will be accompanied by a multitude of initiatives, each adding to the security of the network and opening the doors to compensation for participants but also educating the community on what is required to be a participant within the Dusk Network protocol. If you’re looking to spend your time strengthening the financial framework of the future while racking up rewards, keep reading to find out more about how to set-up your very own Dusk Network Testnet Node!

A step-by-step guide

Before we can run a node, we need to gather a couple of data points. We will need an address to send a starting amount of at least 1000 Dusk to and a provisioner key to give access to our staking contract. In the following steps we’ll explain how to go through the process of creating a wallet and gathering all the necessary information to run a node. This includes:

1. Setting up your CLI Wallet
2. Setting up your Node
3. Staking your testnet DUSK

If you’re interested in participating, be sure to follow our blog and our official Twitter account, or get involved with other participants in our Dusk Network Discord channel. Our team is always available to answer questions in the dedicated ITN thread.

It is no longer possible to join the ITN as a provisioner if you weren't selected already.

Setting up a Testnet Node

Step 1: Server

In this guide we’ll be using Vultr, but the same can be replicated on DigitalOcean, AWS or any other cloud infrastructure provider. While it is also possible to run the node on home infrastructure, this guide will not deal with those types of setups. We work under the assumption that you’ve already created an account for your respective service and topped it up with funds.

The Dusk node makes use of the Kadcast protocol to communicate messages between nodes in the network. This bespoke protocol makes use of UDP and runs on a custom port. Due to the nature of how UDP works, Kadcast is not automatically port forwarded. Regardless of where the node is hosted, it is important that this is done.

Depending on the cloud provider, we will need to either add a firewall rule on the instance you’re running or add a firewall group. If you’re running a local setup, you will need to enable port forwarding in your router.

Vultr works with firewall rules. If you’re logged in, navigate to the firewall tab and click on the ‘+’ button.










Give the firewall group a name and add it.

















Add a new IPv4 rule, enabling the UDP protocol on port 9000 from anywhere. Click the ‘+’ to add it. Do the same for SSH on port 22 as well. We’ll use SSH and SFTP later to transfer our consensus key to our node.

Next, we’ll deploy a new server instance. Navigate to the instances tab.

Click the Deploy Server button if you have no instances on Vultr. If you already have instances on Vultr, click on the ‘+’ button.







To increase decentralization, we opted for the first round to be primarily run by cloud hosted nodes. Cloud providers allow you to pick many different countries to run a node in. To help us increase decentralization and geographical diversity, please pick one of the underrepresented regions. To get an idea of where the current nodes are run, see the charts page of our block explorer. We would also support our community to use other providers beyond the one shown in this guide.

The cheapest Cloud Compute, General Purpose instance with Ubuntu 22.10 x64 should be enough to run a testnet node that only contributes to consensus. Select the option shown below.

At the bottom of the instance deploy page it’s possible to attach a firewall group to your instance. Select the group you set up before that gives access to Kadcast.










To reduce costs you can disabled Auto Backups. For ITN phase I, these should not be necessary.





Click on Deploy Now to create your instance. This can take some time. On the instance overview, you should now see your instance being installed.

Once the deployment is done, which can take several minutes, the status of your instance should be Running.


If you click on the instance, you’ll get an overview showing all sorts of statistics and information about your instance.

Step 2: Node

The next step is to connect to our server instance and install the node software. If you’re on Linux or Mac, you can directly SSH into the server instance. If you’re on Windows, please install a SSH client like PuTTY.

Collect the IP, username and password of your instance:

If you’re in the terminal, run the following command to connect to your instance:

ssh [email protected]<SERVER_IP>










If you’re using PuTTY, simply fill in the details and click on open. See this Digital Ocean for more details.


















If you’ve logged in and connected to your server instance successfully, you should now have access to its terminal.

For ease of use, we’ve created a script to install the node software and its dependencies as a service on your server instance. Copy the following command and run it in the terminal:

curl --proto '=https' --tlsv1.2 -sSfL https://github.com/dusk-network/itn-installer/releases/download/v0.0.3/itn-installer.sh| sudo sh

You should get the following output (see image):

The node will now start syncing. With the current size of the testnet, this can take a couple of days. 

As the output of the installer mentions, we’ll have to provide both the consensus keys and set the correct password. We cannot run the node without these.

Step 3: Wallet

With this new installer, we do not only install the node client and Rusk, but we also install the wallet CLI. You can simply run it by typing rusk-wallet in your terminal.

You will need an address that contains at least 1000 tDUSK and a provisioner key that has been given access to our staking contract to stake on our ITN. We assume that this is the case and you still have access to the original recovery phrase or wallet file.

Note: If the wallet reports a Connection to Rusk Failed, some operations won't be available error, do not worry. The wallet tries to connect to your node, but your node hasn’t been started yet. We first need to set the provisioner keys and configure the node properly.

If you still have the recovery phrase, simply select the `Access a lost wallet` option and fill it in.



Select the address you submitted to participate in ITN:

Next, select the Export provisioner key-pair option. This option will export the public and private key pair used for the staking process. By default, it will be saved in the directory where the wallet CLI will store its data.













This will be displayed.

Fill in a password to protect your provisioner key and navigate to the location where the keys are stored.





There should be two files now, a .keys file and a .cpk file. Keep the .keys file secret, do not share it with anyone. Think of it like the keys that you use to sign off on blocks being valid. 

The next step is to rename the consensus keys. We will use the mv command to move the exported consensus keys from the Rusk wallet folder to Dusk node configuration folder:

mv /root/.dusk/rusk-wallet/<ADDRESS>.keys /opt/dusk/conf/consensus.keys

If you lost your recovery phrase but still have the .keys file, you can follow the steps below:

Install FileZilla and run the software. You should now have access to an interface similar to this one: 

At the top of the window, you should see Host, Username, Password and Port. For the host, fill in the IP address of your instance. You can find this, and the username and password, in the overview of your instance.



Fill in the details and use port 22. Click on Quickconnect. If you set the firewall permissions correctly at the start, and if you filled in the correct details, you should be able to access your server's file system. Navigate to the Wallet CLI configuration folder on your local computer and select your renamed consensus key. On your node, navigate to the /opt/dusk/conf folder. Right click on the consensus.keys file and select upload. FileZilla will now ask you to overwrite the file on your server. Click on Ok.

If everything went correctly, FileZilla will tell you the file transferred successfully. 

The next step is to update the password used to access your consensus keys. Open the terminal of the server and paste in the following commands where <your_password> is the password you set for your consensus keys earlier: 

echo 'DUSK_CONSENSUS_KEYS_PASS=<your_password>' > /opt/dusk/services/dusk.conf

Once you’ve provided your consensus keys and set the password, you can run the node. Run the following commands to boot up Rusk and the Dusk node:

service rusk start

service dusk start

You can check the status of your node by running service rusk status and service dusk status. If everything works as expected, it should report your services as active (running).

If the node is configured properly and running, it should now start gathering the chain state. To find out more details on the actively running nodes, you can find the logs in the /var/log folder. There will be dusk.log, dusk.err, rusk.log, rusk.err files that can be viewed to see what the node is up to.

To see the syncing progress check the latest seen block on the explorer and compare it to the last synced block by your node. To see which one that is, run the following command:

tail -F /var/log/dusk.log | grep "accept_block"

Note: If your node is NOT synced up, it is possible that your connected wallet will display a balance of 0 UNTIL it is synchronized to the block where you received your tDUSK.

Note: The kadcast public address is your public IP, the one that other peers use to contact you. The kadcast listen address is the address where your node binds to, and it should match an available IP, which can be a local IP.

Usually a VPS has a direct DMZ, where both the IP addresses are the same. Some providers use segregated networks instead, and therefore report different values for the public IP and local IP.

If your node doesn’t connect to the network properly and reports an Unable to bind address in the error logs, you’ll need to set the addresses manually. Find both the public IP address of your instance (Usually in the VPS dashboard) and run ifconfig to find the local interface IP.

The configuration file should look like this, but with your own IPs:

KADCAST_PUBLIC_ADDRESS=34.87.42.130:9000

KADCAST_LISTEN_ADDRESS=10.148.0.3:9000

Step 4: Stake

Now that we’ve configured and set up our node, we can move on to the final step: Stake our testnet Dusk. Open the wallet CLI again and Access your wallet. Select the address you used before.

Your balance should have an amount of at least 1003 tDUSK to cover the minimum amount to stake and to pay for the gas fee. If your node is still syncing, it’ll most likely display 0 until it is synced up. If this is the case, select the Stake Dusk option.

You will be prompted to stake a given amount. Do not stake everything, else you won’t be able to unstake or execute any further transaction. Accept the default gas price and limit. Once you’re done, proceed with the transaction.







Your transaction will be generated, this will take a couple of seconds. Once it goes through successfully, you can view your transaction on the block explorer.


















You can also observe your current stake and accumulated rewards in the wallet CLI by selecting the Check existing stake option. It will take two full epochs before your stake matures, which is at minimum 4320 blocks, up to 6479.

If you did everything correctly, your node should be participating in consensus and accumulate rewards in the coming days. To see if your node is accepting blocks type in the following command:

tail -F /var/log/rusk.log | grep ExecuteStateTransition

Or to see if it did so in the past:

cat /var/log/rusk.log | grep ExecuteStateTransition

Still have questions on how to set up your own node? Don’t hesitate to join our Discord Channel and post in the dedicated #Node thread for help. The team is always there to help!

Thank you for participating in the first phase of the Dusk Network Incentivized Testnet!