Tockchain Testnet Guide for Node Operators

Join the Tockchain public testnet and gain early access to the infrastructure powering the next generation of stablecoins

Introduction

Welcome to the Tockchain Public Testnet!

Project Tockchain is a research initiative for a standalone Layer 1 blockchain with native Qubic integration. If our research proves successful, Tockchain will serve as the foundation for Valis Stablecoins. VUSD, our first stablecoin, will be issued on both Qubic and Tockchain.

This guide will walk you through the steps to set up and run your own node on the Tockchain testnet.

If you would prefer to participate as a tester instead of running a node, check out the “Tockchain Testnet Guide for Testers” for instructions.

By running a node, you will contribute to the network’s resilience and performance at scale.

Become a Node Operator

Ready to join the Tockchain testnet as a node operator? Follow these steps:

1. Review This Guide: Ensure you meet the knowledge, hardware, software, and connectivity requirements outlined in this guide.
2. Join the Valis Discord: Start by joining the Valis Discord.
3. Send your Application: Submit the Valis Collaboration Form.
4. Await Approval: Once your application is approved, you’ll receive the “Qualification Operator” role on the Valis Discord, unlocking private channels. You’ll also get a Discord message with a link to your personalized “Collaborator Dashboard”.
5. Verify Your Profiles: In the Collaborator Dashboard, confirm that your “Personal Info” and “Node Operator” profiles are correct and up to date.
6. Register Your Node: From the Collaborator Dashboard, select “Register a New Node” and provide the required details. To whitelist your node, we only need your node address and IP. However, full node details are required for testnet participation.
7. Await Approval: After your node registration is approved, your node will appear in your Collaborator Dashboard, where you can update its details. Stay tuned to the #op-qualification-testnet channel on the Valis Discord for announcements on the Qualification Testnet launch date and binary release.
8. Setup Your Node: Follow this guide to configure and run your node on the Qualification Testnet. Upon successful qualification, your node will be eligible for the next Core Testnet.

Unix Basics for Node Operators

Learn the Basic Unix Commands

You’ll use a Unix-based server (like Linux). Don’t worry if you’re new. We’ll guide you!

New to Unix? Don’t worry, here’s a quick guide. These basics will help you set up your node:

Understand the Prompts

The Command Line Interface (CLI) can show two different types of prompts to you:

• The terminal prompt: This is the prompt you first see when you open your Terminal. It looks like user@server:~/valis$ and lets you use Unix commands like ls.
• The binary interactive prompt: This is the prompt you see once you run a binary (e.g., ./vcli). It looks like vcli> (assuming you execute the vcli binary), and lets you use binary-specific commands. When you finish using the binary interactive prompt, type exit or Ctrl+C to return to the terminal prompt.

For more help when issues arise, see the “FAQ” section at the end of this guide.

Get Help with an AI Assistant

To assist with your setup and answer questions about Unix commands, opening ports, or basic node operation, we recommend using an AI assistant (use Grok for best results). This will save our small team’s time, allowing us to focus on Tockchain-specific support in the #op-testnet_qualification channel on the Valis Discord.

How to Use an AI Assistant:

1. Download the “Tockchain AI Reference”: Visit the “Downloads” section of this guide, download the .md file, and save it to your computer.
2. Upload to an AI: Load the file into Grok 3 (recommended) as a knowledge base. You can do this by uploading the .md file when interacting with the AI or pasting its contents, depending on the platform.
3. Ask Your Questions: Use the AI to ask questions about Unix commands, setup steps, or troubleshooting (e.g., “How do I use chmod +x?” or “What does sudo mean?”).
4. Escalate to Discord if Needed: If the AI can’t resolve your issue or you have questions that are not already answered in the FAQ section, contact us in the #op-testnet_qualification channel on the Valis Discord.

Steps

Step 1: Understand Testnet Types

Tockchain operates two separate testnets:

• Core Testnet: This the primary testnet network for existing testnet node operators to run and test Tockchain operations.
• Qualification Testnet: A separate testnet for qualifying new node operators, testing their hardware, network, and knowledge before they join the Core Testnet. If you’re a new node operator, you’ll start here.

Step 2: Understand Versioning

2.1. Version Numbers

Tockchain binaries use Semantic Versioning (SemVer) to indicate change compatibility. The version number (X.Y.Z) represents both network and software changes:

• X (Major) – New genesis block: Breaking changes requiring a fresh start, such as new genesis blocks, incompatible API changes, or feature removals.
• Y (Minor) – New testnet: Backward-compatible changes including new testnets with existing genesis blocks, feature additions, performance improvements, or feature deprecation notices.
• Z (Patch) – Changes in the same testnet: Minor updates like bug fixes, rebuilds, dependency updates, performance optimization, logging changes, or whitelist and genesis time adjustments.

2.2. Version Number Examples

Step 3: Understand Testnet Goals

Each testnet has two types of goals: network goals and feature goals.

The next Core Testnet, 3.1, aims to achieve the following:

• Network Goals:
• Test the performance of our largest network yet, with 17 nodes.
• Evaluate improvements to both Generator and Validator nodes:
• Generator: Achieve up to 4x faster processing.
• Validator: Ensure real-time synchronization, maintaining minimal delay using http://ipaddr/VUSD as fallback, even in the absence of a Generator node.
• Feature Goals:
• Test ETH and Qubic centralized bridges.
• Test arbitrage between liquidity pools and order book trading.
• Test trading with real-world prices.

Step 4: Prepare the Hardware, Software, and Connectivity

Make sure you are using a dedicated server (no VPS), hosted by a provider (not self-hosted), with a static IP (not dynamic), a minimum of 200 Mbps dedicated bandwidth, used exclusively for the Testnet with no other workloads, running Ubuntu 24 or higher, and meeting the minimum hardware requirements.

Step 5: Set Up Your Server Environment

Now that your server’s hardware, software, and connectivity are prepared, you need to set up your server environment. This involves verifying your operating system meets the requirements and ensuring the necessary ports are open for the generator and validator nodes to communicate with other nodes. If these ports are closed, your nodes may fail to sync or tock properly.

5.1. Verify Ubuntu Version

Tockchain Testnets require Ubuntu 24 (other Unix variants must have glibc version 2.38 or later). Verify your server is running the correct version before proceeding:

lsb_release -a

Look for the release number (e.g., 24.04). If you’re not running Ubuntu 24, you’ll need to upgrade your system or set up a new server.

5.2. Open the Required Ports

In order for generator and validator nodes to communicate with other nodes on the testnet, certain ports must be open to facilitate peer communication across the network. The list of required ports will vary per testnet, and any updates for future testnets will be communicated in this section.

For Core Testnet 3.1 (CT3.1), the required ports are: 12001, 9899, 9057, 9999, 31500, and SSH (typically port 22).

Use the following commands to enable the firewall and open the required ports on Ubuntu 24 using ufw (Uncomplicated Firewall):

# Enable and start the firewall
sudo ufw enable
sudo ufw start
sudo ufw reload

# Allow the required ports
sudo ufw allow 12001
sudo ufw allow 9899
sudo ufw allow 9057
sudo ufw allow 9999
sudo ufw allow 31500
sudo ufw allow ssh

5.3. Set Up a Web Server for File Sharing

To help other nodes sync and improve network performance (especially at high loads like 40k transactions/sec), you must set up a web server to share Tockchain files. The default directory is /var/www/html/VUSD/, which should be accessible at http://<your_ipaddress>/VUSD/

1. Install Apache2 (recommended default):
Copy

sudo apt update
sudo apt install apache2 -y

2. Verify the web server is running:
Copy

sudo systemctl status apache2

If it’s not active, start it with:

Copy

sudo systemctl start apache2

3. Ensure /var/www/html/VUSD/ exists and is accessible:
Copy

sudo mkdir -p /var/www/html/VUSD
# Give ownership to your user account ($USER is your username, e.g., 'ubuntu')
sudo chown -R $USER:$USER /var/www/html/VUSD
# Alternatively, replace $USER with your actual username (check with 'whoami')
# sudo chown -R $(whoami):$(whoami) /var/www/html/VUSD

Test it by visiting http://<your_ipaddress>/VUSD/ in a browser or with:

Copy

curl http://<your_ipaddress>/VUSD/

The directory will be empty for now; tocks and rawtocks directories will appear after running the generator and validator nodes (Step 12). If the URL doesn’t work (e.g., no directory listing), check that Apache2 is running (sudo systemctl status apache2) and that port 80 is open (sudo ufw allow 80). Restart Apache2 with sudo systemctl restart apache2 if needed.

4. Secure your web server with a basic configuration to prevent unauthorized access while allowing file sharing:
Copy

sudo nano /etc/apache2/sites-available/000-default.conf

Inside the <VirtualHost> block (e.g., after the DocumentRoot line), add:

Copy

DocumentRoot /var/www/html
<Directory /var/www/html>
    Options -Indexes
</Directory>

<Directory /var/www/html/VUSD>
    Options +Indexes
    AllowOverride None
    Require all granted
</Directory>

Save and exit (Ctrl+O, Enter, Ctrl+X), then restart Apache2:

Copy

sudo systemctl restart apache2

Step 6: Install Prerequisites

Ready to install the prerequisites on your Unix-based system? You will use the Unix commands from “Unix Basics for Node Operators” above. Don’t worry. We’ll guide you!

6.1. Set Timezone to UTC

Set your system's timezone to UTC to ensure accurate timestamps for the node.

dpkg-reconfigure tzdata

6.2. Install Dependencies

Install tools your node needs to run and stay secure. These are like building blocks for Tockchain. Don’t worry if the names look technical, we’ll explain.

# Update your system to get the latest tools.
sudo apt update && sudo apt upgrade -y

# Install tools for building, networking, security, and downloading files
sudo apt install -y apache2 gcc gdb cmake nethogs libnanomsg-dev websocketd libgmp-dev uuid-dev libssl-dev curl

These tools help your node compile code, connect to the network, and secure transactions. If you see errors, check your internet is working with ping google.com.

6.3. Install Secp256k1 Library

Secp256k1 is a security tool that helps sign transactions and verify them on Tockchain. Specifically, Secp256k1 is a cryptographic library used for elliptic curve cryptography (ECC). ‘ECC’ is a secure math method for transactions, like a digital lock. This step installs it on your server.

# Clone the secp256k1 library (used for secure transactions).
git clone https://github.com/bitcoin-core/secp256k1
cd secp256k1

# Set up for signing transactions securely.
cmake -DSECP256K1_ENABLE_MODULE_RECOVERY=ON .

# Build and install it.
make
sudo make install
sudo ldconfig

# Return to the previous directory.
cd ..

Step 7: Download Tockchain CLI

Your node tools will live in a valis directory. This step sets up the Tockchain CLI tool.

The necessary files will be created in the valis directory and /var/www/html/VUSD, which must be accessible via a web server (set up in Step 5.3) to allow other nodes to fetch missing files using http://<your_ipaddress>/VUSD/. It’s not required to use Apache2 specifically; other web servers like Nginx are fine as long as the URL works.

For the Tockchain Core Testnet:

For the Tockchain Qualification Testnet:

Step 8: Generate Wallet & Configuration File

Now, create your wallet and config file in ~/valis. This prepares your node’s identity.

Each node operator must generate their wallet files, along with their public key, address, and IP address.

The following table explains the key concepts you'll encounter in this step:

8.1. Generate Wallet Files

Create a wallet with a seed and address for your node. This step uses vcli in ~/valis.

Run the vcli program to generate wallet files and a new address. This will create a wallet with a seed, public key, and address, which are securely stored in a subseeds directory which will be automatically created in ~/valis in a subseeds directory.

You’ll need to specify a password to encrypt your seed. Don’t type <password0> literally. Replace it with your own strong password, using letters and numbers, at least 8 characters (e.g., ./vcli MySecurePass123).

# Run vcli to generate a wallet, replacing <password0> with your strong password (e.g., MySecurePass123).
./vcli <password0>

Running the vcli program will start the vcli binary interactive prompt. If you’re new to Unix, you might think you’re still in the terminal, right? However, you’ll notice you’re no longer seeing the terminal prompt (e.g. user@server:~/valis$). Instead, now you are seeing the vcli binary interactive prompt, which looks like this (vcli>). Make sure you understand how prompts work (see “Unix Basics for Node Operators” at the beginning of this guide).

8.2. Generate a Public Key

Pick your node’s unique address from the wallet seed.

Your public key is like your node’s unique address on the Tockchain network. It’s what identifies your node to others. This public key is generated from a secret seed, which you created in Step 8.1. Keep your seed safe. It’s the key to recovering your address if needed.

If you’re running ./vcli <password0> for the first time (from Step 8.1), vcli will start its binary interactive prompt and offer you 5 options to create your public key (node address). Here’s what each option means and how to use it:

1. Option 1: Input a 55-character seed to restore an existing address: Paste the exact seed from Step 8.1 to recover an address.
2. Option 2: Input “BIP39” (without quotes) to generate a new BIP39 seed: This creates a new seed using the BIP39 standard, which vcli will use to generate a new public key.
3. Option 3: Input a vanity prefix (up to 7 characters) for a custom address: Type a short prefix (e.g., PARIS) to customize your address (e.g., PARISXXEWR…). This can help identify your node’s location (like your city or data center), but longer prefixes (up to 7 characters) can take longer to generate—be patient!
4. Option 4: Press Enter (leave blank) for a random seed: This automatically generates a random public key (node address) for you. No input needed.
5. Option 5: Restore an existing seed longer than 55 characters: Paste an existing long seed if you have one to restore a specific address.

Choose one of these options by typing the required information in the vcli prompt and pressing Enter. vcli will guide you through the process. Don’t worry, it’s interactive and gives clear instructions.

After selecting your option and generating your public key, you’re done with this step for now. Since we haven’t finished setting up your node, type exit or press Ctrl+C to return to the terminal prompt (e.g., user@server:~/valis$). You’ll use vcli again later for transactions (like maketx), but not yet.

8.3. Backup the Seed and Manage Your Password

The seed, private key, and password are all securely encrypted to ensure their protection.

The seed must be retrieved from the encrypted subseeds directory for future use.

Passwords can be of considerable length and should consist of printable text. It is recommended to limit passwords to letters and numbers, as the system has been tested primarily with simpler passwords.

8.4. Initialize the Second Password

For testing the public testnet, the generator and validator nodes are combined into one and must share the same address. To ensure addr0 (generator) and addr1 (validator) match, both addresses must come from the same seed.

In the future, generator and validator nodes will operate separately, each with its own unique address and password. This will enhance flexibility and security for node operators. The valis.conf file already requires two addresses, as it is prepared for this future scenario.

# Run vcli to set a second password, replacing <password1> with your strong password (e.g., MySecurePass123).
./vcli <password1>

# Note: This uses the same seed from Step 8.1 to keep generator and validator addresses the
# same. Enter the seed when prompted. For Testnet 2.0.0, use the same password as Step 8.1.

Paste the seed generated by the first vcli run for the pw0 address.

8.5. Create valis.conf

nano is a simple text editor. Ensure you have it installed (sudo apt install nano if not).

Use the nano text editor to open a new valis.conf file in the ~/valis directory:

# To be sure you’re in ~/valis (in case you’ve navigated elsewhere), run:
cd ~/valis

# Open valis.conf in ~/valis with a text editor (e.g., nano).
nano valis.conf

Populate the valis.conf configuration file with the following details:

Notes:

• Passwords: Can be any printable text (letters/numbers). Private keys are encrypted and securely stored.
• Infura Project ID: Required for the ETH bridge. Sign up at app.infura.io and replace <your_infura_project_id> with your assigned ID.
• Websocat Configuration: Users can specify any WebSocket server, improving decentralization. Ensure the chosen server retains required data.

Step 9: Register your New Node

Once your configuration file (valis.conf) is ready, it’s time to register your new node. Visit your Collaborator Dashboard, click on the “Register a new node” button, and complete the details of your node. Your node IP and address will be automatically used to whitelist your node for the next testnet, so please ensure this information is correct and always up to date. Full node details are still required for testnet participation.

Step 10: Wait for Node Software Deployment

After collecting all node IPs and addresses, the Valis team will:

• Generate a whitelist of approved IPs.
• Integrate the whitelist into the node software.
• Upload the node software to this Tockchain Testnet Guide and provide further instructions.

Step 11: Download the Nodes

Once the whitelist is created and integrated into the node software, the Valis Team will announce the availability of the binaries in the #team-valis channel on the Qubic Ecosystem Discord. You will then be able to download the nodes.

For the Tockchain Core Testnet:

For the Tockchain Qualification Testnet:

Step 12: Run the Nodes

Now, start your Generator and Validator Nodes to join the testnet. Both run from ~/valis and use real-time logs for debugging.

12.1. Run the Generator Node

The Generator creates blocks and broadcasts them for validation.

Run the Generator Node in the foreground to see live updates:

# Run the Generator Node, checking logs in real-time.
./generator

Running ./generator starts the generator’s binary interactive prompt.

If you see a “Permission denied” error, you may need admin privileges the first time to create necessary directories. This happens because some system folders (like /var/www/html/) are restricted. Use sudo to run Unix commands with admin rights (sudo lets you perform tasks as an administrator), but be cautious with it. Try:

# Use admin privileges to run the Generator Node, checking logs in real-time.
sudo ./generator

If you see logs scrolling, congratulations. Your generator is running! You’re helping power the Tockchain testnet.

You'll see real-time printouts directly in the terminal. In other words, the log is continuously updated as the node performs actions, which is useful for debugging.

12.2. Monitor the Generator Node

Run the Generator Node in the background (a.k.a. as a daemon) to keep it running continuously without tying up your terminal, then check its logs.

# Run Generator in the background and monitor logs, saving to generator.log.
nohup ./generator > generator.log &

This will save the output to generator.log. To monitor the logs of the Generator Node in real-time, use:

# Watch Generator logs live
tail -f generator.log

Generator Node Debug Output includes the following key terms and metrics:

When you are finished using the generator binary interactive prompt, type exit or press Ctrl+C to return to the terminal prompt (e.g., user@server:~/valis$). Make sure you understand how prompts work (see “Unix Basics for Node Operators” at the beginning of this guide).

12.3. Run the Validator Node

The Validator checks blocks (or “tocks”, as we call them) for accuracy.

Run the Validator Node in the foreground:

# Run the Validator Node, checking logs in real-time.
./validator

Running ./validator starts the validator’s binary interactive prompt

You'll see real-time printouts directly in the terminal. In other words, the log is continuously updated as the node performs actions, which is useful for debugging.

12.4. Synchronize the Validator Node

To synchronize your Validator Node, you can use one of two methods:

12.4.1. Synchronize Using the Fast Method

Use the -fast method to synchronize your Validator Node after genesis, such as when starting late or recovering from a power outage. As long as a quorum of nodes is running, this method automatically finds the latest available hour to sync from, making it ideal for late-arriving nodes.

# Sync Validator with auto-search for the latest available hour
./validator -fast

Optionally, you can specify a starting hour (where <hour_number> is a UNIX timestamp divided by 3600):

# Sync Validator from a specific hour, replacing <hour_number>
# with your UNIX timestamp / 3600 (e.g., 483186 for a past hour)
./validator -fast <hour_number>

This method is ideal for catching up without needing a jumpstart file, as it fetches data from other nodes to synchronize efficiently.

12.4.2. Synchronize Using the Jumpstart Method for Core Testnet 2.1

Jumpstart files are built for specific testnets. For Core Testnet 2.1 (launched on April 15, 2025, at 09:00 UTC), you could use the jumpstart method to synchronize your Validator Node at genesis, resuming from where Testnet 2.0 stopped. This method is optional but recommended for validators who joined at the launch of Core Testnet 2.1.

For the Tockchain Core Testnet:

If you see no output after starting the validator, it may be waiting for the genesis tock to begin. This is expected behavior if you start before the testnet launch time (e.g., April 15, 2025, at 09:00 UTC for Core Testnet 2.1). Check your logs in Step 12.5 once the testnet starts.

For the Tockchain Qualification Testnet, there is no need to use the -jumpstart method.

12.5. Monitor the Validator Node

To run the Validator Node as a daemon (in the background), use:

# Run Validator in the background and monitor logs, saving to validator.log.
nohup ./validator > validator.log &

If you’re using the jumpstart method (from Step 12.4.2), include the -jumpstart flag:

# Run Validator with jumpstart in the background
nohup ./validator -jumpstart 484640 > validator.log &

This will save the output to validator.log. To monitor the logs of the Validator Node, use:

# Watch Validator logs live
tail -f validator.log

Validator Node Debug Output includes the following key terms and metrics:

When you are finished using the validator binary interactive prompt, type exit or press Ctrl+C to return to the terminal prompt (e.g., user@server:~/valis$). Make sure you understand how prompts work (see “Unix Basics for Node Operators” at the beginning of this guide).

Step 13: Enhance node communication

Once your generator and validator nodes are running, you can enable WebSocket functionality to improve communication with the network. This involves websockets (the tech for real-time talk, like a phone line), Websocat (a tool to send messages, like a messenger), and Websocketd (a tool to turn your node into a server others can connect to). Below, you’ll set up these tools to enhance your node’s capabilities.

13.1. Install Websocat

Websocat is a simple tool that lets you send and receive messages over websockets—like a messenger using a phone line to talk to your node. You can use it to communicate with a Tockchain node once it’s deployed.

To install Websocat, follow these steps:

Now Websocat, your messenger, is installed and ready to send messages to your node.

13.2. Optional: Configure Websocat to use a specific Websocket server

This optional step lets you connect your Tockchain CLI (vcli) to a specific WebSocket server for real-time network communication—handled by Websocketd, a tool that turns your node into a WebSocket server others can connect to. By choosing your own server (instead of a default), you help make the network more decentralized. The server you pick needs to keep all transaction data (not delete it) so vcli can work properly. You’ll update your valis.conf file and set up a WebSocket service using a new binary.

First, update your valis.conf file from Step 8.5 to include the WebSocket server URL. Open it with a text editor (e.g., nano valis.conf) from the ~/valis directory and add the websocat field:

# To be sure you’re in ~/valis (in case you’ve navigated elsewhere), run:
cd ~/valis

# Open valis.conf in ~/valis with a text editor (e.g., nano) to add the WebSocket server URL.
nano valis.conf

Add or update this line at the end of the valis.conf file, replacing the URL if using your own server:

websocat "ws://93.190.140.231:9999"

Save and exit: Press Ctrl+O, Enter, then Ctrl+X.

Note: This updates valis.conf in ~/valis, where it belongs—no copying needed. Use your own server’s IP (e.g., ws://<your_public_ip_address>:9999) if you set up vpoint below.

Next, set up your own WebSocket service by downloading and running the vpoint binary.

For the Tockchain Core Testnet:

For the Tockchain Qualification Testnet:

This starts a WebSocket server at ws://<your_public_ip_address>:9999. Now Websocketd, your server, is running and ready for others to connect over the websockets phone line connection.

You can test it by updating the websocat field in valis.conf to your own IP (e.g., websocat "ws://<your_public_ip_address>:9999").

For a secure SSL connection, use certificates and modify the command:

websocketd -devconsole -port=9999 --ssl --sslcert=/path/to/cert --sslkey=/path/to/key ./vpoint &

Then update valis.conf to websocat "wss://<your_public_ip_address>:9999" and recopy it as above.

Other Tockchain tools can also use this WebSocket URL by reading valis.conf. For connection errors, ensure websocketd is installed (Step 6.2) and port 9999 is open in your firewall.

Step 14: Start the Testnet

To initiate the testnet, all generator and validator nodes must be running. While only a quorum is strictly necessary, having some nodes offline results in inefficiencies, as those nodes must later request every single tock from the ones that remained online.

To avoid this, set a genesis tock in the future, giving all generator nodes ample time to start. As long as the generators are active, validators can catch up as they come online.

14.1. Start the Generator Nodes

To update the generator, use the following launch script:

# To be sure you’re in ~/valis (in case you’ve navigated elsewhere), run:
cd ~/valis

# Stop any running generator process.
pkill generator

# Start the generator process and log output to a file.
nohup ./generator > generator.log &

# Display live logs to monitor startup.
tail -f generator.log

For launching a new testnet, execute the following steps:

1. Clear existing blockchain data: This ensures you're starting from a clean slate.
Copy

sudo rm -rf /var/www/html/VUSD

2. Run the launch script: The script that starts the testnet is called launch. It contains the critical three lines that initialize the testnet and trigger the process.
Copy

./launch

Once the generator starts, it will log outputs for each tock. The most critical logs appear at the beginning and should resemble:

If you see your node address and corresponding genid in the logs, initialization was successful:

restored from file subseeds/d72ab3bf53a164a5: NODEAVSCPVVIEDAWJQJZVWBOINJCKWXKTDKVSVODJAGOWANHODTNXQWDNRYH

genid.0 93.190.140.231:12000 sock.0 NODEAVSCPVVIEDAWJQJZVWBOINJCKWXKTDKVSVODJAGOWANHODTNXQWDNRYH sent.0

After initialization, tocks will start generating immediately. However, until a quorum of nodes is reached, all tocks will remain empty:

As more nodes come online and begin running the generators, the numfinalsigs value will increase. Instead of 0, you will see 50d4c21a finalsigs, which represents the rawtock hash when no transactions are present.

Once enough nodes are active, these errors will disappear, and you should observe a steady tocking process every second, displaying relevant statistics. Before starting the validator, ensure the printouts resemble the following, with only occasional exceptions:

14.2. Start the Validator Nodes

Once all generators are producing printouts like these, you can start the validators. If you cannot start all validators before the genesis tock, you must update the validator with a later genesis tock. Ideally, all validators should be running at genesis. While only a quorum of nodes is required to advance the tockchain, late-starting validators will require extra overhead to sync back up.

To start the validator at genesis, run:

# To be sure you’re in ~/valis (in case you’ve navigated elsewhere), run:
cd ~/valis

# Run the Validator Node, checking logs in real-time.
./validator

Both the generator and validator must be executed in the same directory as valis.conf. Additionally, a subseeds subdirectory must be present to store wallets. The data files will be created in /var/www/html/VUSD, and these directories will be automatically generated as needed.

If a validator node is launched before genesis, it will display initialization messages and then wait:

These messages indicate that the validator is successfully initializing and awaiting the network to reach the genesis time.

Downloads

Core Testnet

Latest Releases

7 views

Latest Releases

All Releases

CLI

Generator Node

Validator Node

Endpoint

AI Guide

Tockchain AI Reference 2025/04/14

2025/04/14

Tockchain VUSD Core CLI 3.0.0

2025/05/07

Tockchain VUSD Core Endpoint 3.0.0

2025/05/07

Tockchain VUSD Core Generator 3.1.4

2025/06/09

Tockchain VUSD Core Keygen 3.0.0

2025/05/07

Tockchain VUSD Core Multisigner 3.0.0

2025/05/07

Tockchain VUSD Core Validator 3.1.9

2025/06/09

Qualification Testnet

Latest Releases

7 views

Latest Releases

All Releases

CLI

Generator Node

Validator Node

Endpoint

AI Guide

Tockchain AI Reference 2025/04/14

2025/04/14

Tockchain VUSD Qualification Endpoint 1.1.0

2025/04/21

Tockchain VUSD Qualification CLI 1.1.0

2025/04/21

Tockchain VUSD Qualification Generator 1.3.1

2025/04/29

Tockchain VUSD Qualification Validator 1.3.0

2025/04/29

FAQ

General

Collaboration Form

Node Setup

Node Registration

Node Qualification

Support

On this Page

• Tockchain Testnet Guide for Node Operators
• Introduction
• Become a Node Operator
• Unix Basics for Node Operators
• Learn the Basic Unix Commands
• Understand the Prompts
• Get Help with an AI Assistant
• Steps
• Step 1: Understand Testnet Types
• Step 2: Understand Versioning
• 2.1. Version Numbers
• 2.2. Version Number Examples
• Step 3: Understand Testnet Goals
• Step 4: Prepare the Hardware, Software, and Connectivity
• Step 5: Set Up Your Server Environment
• 5.1. Verify Ubuntu Version
• 5.2. Open the Required Ports
• 5.3. Set Up a Web Server for File Sharing
• Step 6: Install Prerequisites
• 6.1. Set Timezone to UTC
• 6.2. Install Dependencies
• 6.3. Install Secp256k1 Library
• Step 7: Download Tockchain CLI
• Step 8: Generate Wallet & Configuration File
• 8.1. Generate Wallet Files
• 8.2. Generate a Public Key
• 8.3. Backup the Seed and Manage Your Password
• 8.4. Initialize the Second Password
• 8.5. Create valis.conf
• Step 9: Register your New Node
• Step 10: Wait for Node Software Deployment
• Step 11: Download the Nodes
• Step 12: Run the Nodes
• 12.1. Run the Generator Node
• 12.2. Monitor the Generator Node
• 12.3. Run the Validator Node
• 12.4. Synchronize the Validator Node
• 12.5. Monitor the Validator Node
• Step 13: Enhance node communication
• 13.1. Install Websocat
• 13.2. Optional: Configure Websocat to use a specific Websocket server
• Step 14: Start the Testnet
• 14.1. Start the Generator Nodes
• 14.2. Start the Validator Nodes
• Downloads
• Core Testnet
• Qualification Testnet
• FAQ
• General
• Collaboration Form
• Node Setup
• Node Registration
• Node Qualification
• Support