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 user instead of running a node, check out the “Tockchain Testnet Guide for Users” for instructions.

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

Become a Node Operator

Interested in becoming a node operator for the Tockchain testnet? Follow these steps to get started:

1. Review This Guide: Familiarize yourself with the hardware, connectivity, and knowledge requirements outlined here to ensure you’re prepared.
2. Join the Valis Discord: Join the Valis Discord and contact Spelunker (Discord Username: _spelunker_) to request becoming a node operator.
3. Wait for Approval: Once approved, you'll receive the “Node Operator” role, granting you access to the private #op-node-operators channel on the Valis Discord.
4. Provide Your Email: Share the email address you’d like to use for Valis collaboration tools with Spelunker. Note that this email will be visible to other collaborators in shared Notion documents or Google Sheets. For privacy, consider using a dedicated alias (e.g., not your personal or work email).
5. Complete Your Node Operator Page: Once you receive a link to your “Node Operator” page, fill in your node information.
6. Follow the Guide: Proceed with the remaining steps in this guide to set up and run your node on the Qualification Testnet. Once qualified, you may join the 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 “Troubleshooting” at the end of this guide.

Get Help with an AI Assistant

To assist with your setup and answer questions about Unix commands 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-node-operators 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 about Valis software, transaction types, or testnet performance, contact us in the #op-node-operators channel on the Valis Discord.

Steps

Step 1: Understand Testnet Versioning

Tockchain uses a two-tier versioning system to track network and software changes clearly:

• Network Versioning (Testnet X.Y):
• X: Major network changes, triggered by a new genesis block.
• Y: Minor network updates or expansions, without a new genesis block.
• Software Versioning (Binary X.Y.Z):
• X: Major software changes.
• Y: Feature updates or minor enhancements.
• Z: Bug fixes or patches.

Please note that Testnet versions (e.g., Testnet 2.0) and software versions (e.g., tockchain-vusd-generator-2.0.0) use separate, independent numbering systems. Do not assume a testnet version matches a software version. Always check the specific requirements in this guide for each testnet phase.

Step 2: Understand Testnet Goals

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

The current testnet, 2.0, aims to achieve the following:

• Network Goals:
• Maintain the 8-node setup but replace VPS with dedicated hardware to test throughput improvements.
• Test dynamic addition of nodes and onboard new nodes as they become ready.
• Improve decentralization towards our “One Generator node per Operator” goal.
• Feature Goals:
• Test ETH and Qubic centralized bridges.
• Test arbitrage between liquidity pools and order book trading.
• Test trading with real-world prices.

Step 3: Understand Testnet Structure

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 4: Prepare the Hardware and Connectivity

Ensure you are using a dedicated server (no VPS), exclusively for Testnet (no unrelated workloads that could impact performance), running Unix, and meeting the minimum hardware requirements. The server can be self-hosted or colocated with a hosting provider.

Step 5: 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!

5.1. Set Timezone to UTC

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

dpkg-reconfigure tzdata

5.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.

5.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 6: 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. It’s not required to use Apache specifically, but /var/www/html must exist.

# Create a single valis directory in your home folder and move into it.
mkdir ~/valis

# Move into the valis directory.
cd ~/valis

# Download the Tockchain CLI tool.
wget https://raw.githubusercontent.com/valis-team/tockchain/main/CLI/tockchain-vusd-cli-v2.0.1

# Rename it to 'vcli' for easier use.
mv tockchain-vusd-cli-v2.0.1 vcli

# Make vcli executable (this lets vcli run as a program).
chmod +x vcli

# Note: 

Step 7: 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.

7.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).

7.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 7.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 7.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 .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.

7.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.

7.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 7.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 7.1.

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

7.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:

# Type or paste these lines, replacing placeholders with your values:
pw0 <password0>
addr0 <address0>
pw1 <password1>
addr1 <address1>

# Set your public IP address (replace <your_public_ip_address>).
ipaddr <your_public_ip_address>

# If using AWS or a cloud provider requiring 0.0.0.0 binding, add this option.
zerobind

# Provide your Infura Project ID (a.k.a. Infura RPC Key) for the ETH bridge.
infura <your_infura_project_id>

# Keep valis.conf in the valis directory (no need to copy it elsewhere)
# Note: Use a text editor like 'nano valis.conf' to create this file in ~/valis.

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 8: Submit Address & IP for Whitelisting

Once your configuration file (valis.conf) is ready, ensure that your generated address and IP pair are sent to the Valis team via the #op-node-operators channel on the Valis Discord. This is necessary for whitelisting and ensuring proper network connectivity.

Step 9: Wait for Node Software Deployment

After collecting all IPs, 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 10: 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.

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

# Download the generator and validator nodes into the valis directory.
wget https://raw.githubusercontent.com/valis-team/tockchain/main/GeneratorNode/tockchain-vusd-generator-v2.0.0
wget https://raw.githubusercontent.com/valis-team/tockchain/main/ValidatorNode/tockchain-vusd-validator-v1.0.0

# Rename the files for easier use.
mv tockchain-vusd-generator-v2.0.0 generator
mv tockchain-vusd-validator-v1.0.0 validator

# Make the binaries executable (this lets generator and validator run as programs).
chmod +x generator
chmod +x validator

# Note: These binaries join vcli in ~/valis. Run them with './generator' and './validator' from here.

Step 11: 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.

11.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.

11.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).

11.3. Run the Validator Node

The Validator checks blocks 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.

If you need to synchronize the Validator Node from a specific hour instead of starting from genesis, use the -fast option:

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

Where <hour_number> is the UNIX timestamp divided by 3600. For example, to sync from hour 483186, run:

./validator -fast 483186

11.4. 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 &

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 12: 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.

12.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:

# Optionally, update system packages to ensure everything is up-to-date.
sudo apt update && sudo apt upgrade -y

# Download Websocat (version recommended by Valis).
wget https://github.com/vi/websocat/releases/download/v1.14.0/websocat.x86_64-unknown-linux-musl

# Rename the downloaded file to 'websocat' for easier use.
mv websocat.x86_64-unknown-linux-musl websocat

# Make websocat executable (this lets websocat run as a program).
chmod +x websocat

# Move Websocat to a directory in your PATH for global access.
sudo cp websocat /usr/local/bin

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

12.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 7.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:

# Download the latest version of the Valis Endpoint binary into the valis directory.
wget https://raw.githubusercontent.com/valis-team/tockchain/main/Endpoint/tockchain-vusd-endpoint-v1.1.0

# Rename the downloaded file to 'vpoint' for easier use.
mv tockchain-vusd-endpoint-v1.1.0 vpoint

# Make the binary executable.
chmod +x vpoint

# Start a WebSocket server on port 9999 using vpoint (runs in the background).
websocketd -devconsole -port=9999 ./vpoint &

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 5.2) and port 9999 is open in your firewall.

Step 13: 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.

13.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:

CHAIN_NUMBER.0 VUSD

initpubkeys 1739455200

# List of generator nodes with their IDs and IP addresses
GEN.0 NODEAVSCPVVIEDAWJQJZVWBOINJCKWXKTDKVSVODJAGOWANHODTNXQWDNRYH 93.190.140.231
GEN.1 FUMARNGCEYUSDCBLYNQRKNXNMXZCOFXXLNFKWKFXHEVTJGUGHYPLTZXCYKAO 192.64.113.26
GEN.2 LONDZVWYNUROKALJLZJOQPFBWFTBYFQUZTXUPGPUXGMOIEGZWMAXUCMBVTVK 194.164.216.198
GEN.3 SINSVUFOWUBHQBKPCDZBFTAZBBJDXASTEADTMXFALAJZIBBRMMDTFMRFQTXK 51.79.255.187
GEN.4 AUSXNKNPVOHWIEKAVZSRXUPXGDSBLWYWVUEUOVWBQCURZNSANBSLMZJGYUOO 139.99.155.105
GEN.5 ROUBHWDHQRDEDARUJRFZCZCQEYOARCJGLVDROHHAYCBIGVDIZIKBUXFFYGHC 51.75.247.147
GEN.6 MONTWJUCWCIPXFHJTARGAKHPGZGAYUBXWISBMNMDJGZQOWIYKOXWHAQGUIFB 167.114.129.148
GEN.7 CANIZWHLNUJTNCLKAHFHDNAUIPUBJTMGOVQCXYWDFFHNMMOTJDWVLFTCLGMA 144.217.240.163

# Confirmation that a saved state exists and is restored

d72ab3bf53a164a5 exists

restored from file subseeds/d72ab3bf53a164a5: NODEAVSCPVVIEDAWJQJZVWBOINJCKWXKTDKVSVODJAGOWANHODTNXQWDNRYH pkhash.TYPOBLIBBKFYQGIMFFUUCMUANMOAJMNHNBRIRLRYDDCLRPQQIBYPATAGDKWA cold.YXUQBTMTOMQCUCJYABMFUZQSCINGALMTRJCFOZFJXGLWHJVIGSXOFQSEUDOK depth.0

# Initializing the generator
launch G.0x7fb130bb6010 genid.0 size 1867508190

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

# Establishing connections between nodes
connect to L0 sock for tcp://192.64.113.26:12000
NNG PULL at tcp://93.190.140.231:12000 1
connect to L0 sock for tcp://194.164.216.198:12000
start sendloop 1
connect to L0 sock for tcp://51.79.255.187:12000
start sendloop 2
PULLSOCK server on (tcp://93.190.140.231:12000)
connect to L0 sock for tcp://139.99.155.105:12000
start sendloop 3
connect to L0 sock for tcp://51.75.247.147:12000
start sendloop 4
connect to L0 sock for tcp://167.114.129.148:12000
start sendloop 5
connect to L0 sock for tcp://144.217.240.163:12000
start sendloop 6

genid.0 START

start sendloop 7

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:

# Example of an empty tock due to insufficient quorum.
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 VOTES[1739430139] for 1 numcandidates.1
0 v1, 1739430139 numcandidates.1 maxi.0 maxvotes.1 1739430139
50d4c21a 50d4c21a 0 0 0 0 0 0 lagging votesigs 1739430134 numfinalsigs.2 havequorum.0
50d4c21a 50d4c21a 0 0 0 0 0 0 lagging votesigs 1739430137 numfinalsigs.2 havequorum.0
votesig_protocol tock.1739430137 empty
EMPTY TOCK.1739430137
1739430137 NOT FINALIZED and will be EMPTY.4 (0 0 0 4) vs FINALIZED.0, subsets fixed.0 failed.0 chaos.0
00000000.0    00000000.0    00000000.0    00000000.0    00000000.0    00000000.0    00000000.0    00000000.0    fullXOR 1739430146 num.1 matches.1 maxmatches.1 LAGGING.-1

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:

0: finalized 1739429323 rollups.0 lag.-2 elapsed.406 TX.0 R.0 S.16271 extreme.0 tocking.407 50d4c21a chaos.0 0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    1739429323
0: finalized 1739429324 rollups.0 lag.-2 elapsed.407 TX.0 R.0 S.16309 extreme.0 tocking.408 50d4c21a chaos.0 0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    1739429324
0: finalized 1739429325 rollups.0 lag.-2 elapsed.408 TX.0 R.0 S.16349 extreme.0 tocking.409 50d4c21a chaos.0 0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    1739429325
0: finalized 1739429326 rollups.0 lag.-2 elapsed.409 TX.0 R.0 S.16388 extreme.0 tocking.410 50d4c21a chaos.0 0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    1739429326
0: finalized 1739429327 rollups.0 lag.-2 elapsed.410 TX.0 R.0 S.16428 extreme.0 tocking.411 50d4c21a chaos.0 0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    1739429327

13.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:

_HASHTABLE_LIMIT 75 75 argstr.() sizeof L1 71544648 firstutime.1739455200 hour.483182
1d298554f75dbf79 exists
restored from file subseeds/1d298554f75dbf79: FUMARNGCEYUSDCBLYNQRKNXNMXZCOFXXLNFKWKFXHEVTJGUGHYPLTZXCYKAO pkhash.MAUQPIKLCPRLTEYEJXPWNVFJHQTFGNIYOLADJPEYDESIHMXFQKCTODLCITEK cold.MUIUUVIEDSVZEAVHXIZQVJIDTCFCUIDAKUOTJDNRBDSVIRPMBIOWRXGCYIJH depth.0
initpubkeys 1739455200
GEN.0 NODEAVSCPVVIEDAWJQJZVWBOINJCKWXKTDKVSVODJAGOWANHODTNXQWDNRYH 93.190.140.231
GEN.1 FUMARNGCEYUSDCBLYNQRKNXNMXZCOFXXLNFKWKFXHEVTJGUGHYPLTZXCYKAO 192.64.113.26
GEN.2 LONDZVWYNUROKALJLZJOQPFBWFTBYFQUZTXUPGPUXGMOIEGZWMAXUCMBVTVK 194.164.216.198
GEN.3 SINSVUFOWUBHQBKPCDZBFTAZBBJDXASTEADTMXFALAJZIBBRMMDTFMRFQTXK 51.79.255.187
GEN.4 AUSXNKNPVOHWIEKAVZSRXUPXGDSBLWYWVUEUOVWBQCURZNSANBSLMZJGYUOO 139.99.155.105
GEN.5 ROUBHWDHQRDEDARUJRFZCZCQEYOARCJGLVDROHHAYCBIGVDIZIKBUXFFYGHC 51.75.247.147
GEN.6 MONTWJUCWCIPXFHJTARGAKHPGZGAYUBXWISBMNMDJGZQOWIYKOXWHAQGUIFB 167.114.129.148
GEN.7 CANIZWHLNUJTNCLKAHFHDNAUIPUBJTMGOVQCXYWDFFHNMMOTJDWVLFTCLGMA 144.217.240.163
start sendloop 0
start sendloop 1
start sendloop 2
start sendloop 3
start sendloop 4
start sendloop 5
start sendloop 6
start sendloop 7
Allocate new hashtable 9999989
numaddrs.2 after init_sweep
my addr FUMARNGCEYUSDCBLYNQRKNXNMXZCOFXXLNFKWKFXHEVTJGUGHYPLTZXCYKAO fast.0 archive.0 id.1
rollups_loop 0x7fb226091010 1739430249
start multisig loop  after 1739455200 processed
NNG PULL at tcp://192.64.113.26:9899 0
NNG PULL at tcp://192.64.113.26:9057 1
connect to L0 sock for tcp://93.190.140.231:12000

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

March 4, 2025

Tockchain VUSD CLI 2.0.1

March 5, 2025

Tockchain VUSD Endpoint 1.1.0

March 3, 2025

Tockchain VUSD Generator 2.0.0

March 3, 2025

Tockchain VUSD Validator 2.0.0

March 3, 2025

Qualification Testnet

Binaries coming soon. Stay tuned!

Latest Releases

7 views

Latest Releases

All Releases

CLI

Generator Node

Validator Node

Endpoint

AI Guide

Tockchain AI Reference

March 4, 2025

Troubleshooting

‘Command Not Found’ Error

If a command (e.g., vcli, generator, validator, vpoint) isn’t recognized, you may have mistyped, skipped making it executable, be in the wrong folder, or omitted the ./ prefix needed to run binaries from the current directory.

To fix it, ensure:

1. You have typed the command correctly (e.g., ./generator, not generator).
2. You have made the binary executable. E.g.: chmod +x vcli (in ~/valis).
3. You are in the valis directory: cd ~/valis (for all commands like ./vcli, ./generator, ./validator, ./vpoint).
4. You use ./ before the command (e.g., ./generator). This tells Unix to run the binary from the current folder, as it’s not in the system’s default search paths.

Node software cannot update

If the node software cannot update /var/www/html, it may lack proper privileges.

To fix it:

1. Change ownership to your user (sudo chown -R youruser:youruser /var/www/html), or
2. Run as root (less secure) (sudo <node_software_command>).

Node does not start

If the ./generator or ./validator commands do not run, it might miss valis.conf or your internet might be down.

To fix it, ensure:

1. The valis.conf file is in the current directory (folder): ls valis.conf should show it.
2. Your internet connection is active: ping google.com should get replies.

Support

For troubleshooting and support, please reach out to Qsilver in the #op-node-operators channel on the Valis Discord.

Thank you for contributing to Tockchain’s success!

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 Versioning
• Step 2: Understand Testnet Goals
• Step 3: Understand Testnet Structure
• Step 4: Prepare the Hardware and Connectivity
• Step 5: Install Prerequisites
• 5.1. Set Timezone to UTC
• 5.2. Install Dependencies
• 5.3. Install Secp256k1 Library
• Step 6: Download Tockchain CLI
• Step 7: Generate Wallet & Configuration File
• 7.1. Generate Wallet Files
• 7.2. Generate a Public Key
• 7.3. Backup the Seed and Manage Your Password
• 7.4. Initialize the Second Password
• 7.5. Create valis.conf
• Step 8: Submit Address & IP for Whitelisting
• Step 9: Wait for Node Software Deployment
• Step 10: Download the Nodes
• Step 11: Run the Nodes
• 11.1. Run the Generator Node
• 11.2. Monitor the Generator Node
• 11.3. Run the Validator Node
• 11.4. Monitor the Validator Node
• Step 12: Enhance node communication
• 12.1. Install Websocat
• 12.2. Optional: Configure Websocat to use a specific Websocket server
• Step 13: Start the Testnet
• 13.1. Start the Generator Nodes
• 13.2. Start the Validator Nodes
• Downloads
• Core Testnet
• Qualification Testnet
• Troubleshooting
• ‘Command Not Found’ Error
• Node software cannot update
• Node does not start
• Support