Delegated staking on Constellation Network allows any $DAG holder to participate in network security and validation by staking their tokens with validators without needing to run a node. This enables more users to contribute to decentralization and governance while earning staking incentives. By choosing a validator, you help secure the network, support metagraph projects, and receive $DAG incentives for your participation. Some metagraph validators even offer additional L0 token rewards, increasing your potential incentives.

$DAG holders who participate in delegated staking may choose your node based on the commission percentage you set. This allows you, as a Node Operator, to generate additional rewards revenue from delegations.

This section explains how to use the Constellation Network Command Line Interface (CLI) utility, which provides a simplified way to run a node without requiring technical expertise or in-depth knowledge of the Tessellation Protocol’s architecture and operation.

What is nodectl?

Pronounced node control, node-c-t-l, or node-cuttle.

nodectl is a command-line utility designed to simplify the deployment and management of Constellation Network Validator nodes.

It eliminates the need for deep technical knowledge of the Tessellation Protocol, allowing both technical and non-technical users to run and maintain a Validator node on the Hypergraph and/or metagraph networks.

The utility is packed with powerful features that abstract away the complexities of node management.

These documents are specifically tailored for deploying Constellation Network nodes according to the configuration and integration requirements of each provider’s dashboard setup.

To offer your node for delegation on the Constellation Network, you must complete the delegated staking configuration.

This process allows Node Operators to make their nodes available for delegation.

Follow the steps in this guide to properly set up and enable delegation.

nodectl version

Delegated staking is supported by nodectl starting with version v2.17.0.

Verify your version

Issue the version command to output the current version of nodectl.

Upgrade if necessary

Please follow the correct upgrade path to ensure your node remains manageable by nodectl and does not encounter compatibility issues.

If there are multiple versions between your current version and v2.17.0, you must follow the correct upgrade path.

Take note of each intermediate version and run the upgrade_nodectl command sequentially for each version step using the -v <version> option.

Upgrade one version at a time. Do not skip versions until you reach v2.17.0.

This ensures compatibility and prevents potential issues with configuration or functionality.

Example: sudo nodectl upgrade_nodectl -v v2.13.0

When you reach a version that can be directly upgraded to the latest v2.17.0 you may exclude the -v option.

Node internal upgrade

If you are requested to upgrade the node, issue a Y and allow nodectl to upgrade the node so that all the features, changes, and updates can be properly applied.

This is important to ensure that all features of nodectl are enabled.

As a Node Operator, you can offer your node for delegation by following these steps:

• Configure delegated staking on your node.

• Create a delegation request to enable your node for delegation.

• Sign the delegation request using your p12 keystore private key.

• Submit the signed request to the metagraph and verify that it has been accepted.

The nodectl utility automates these steps for you. Follow this guide to complete the setup.

Since delegated staking is a financial decision, the configurator will not automatically commit your node to become available for delegated staking.

• This action must be manually initiated by the Node Operator.

• To validate your permission to update delegated staking settings on the metagraph, you will be prompted to enter your p12 passphrase.

Join the Constellation Network Official Discord

To stay fully informed and connected, you must join the Constellation Network Official Discord server.

This is the central hub for:

✅ Cluster update announcements

✅ Scheduled network restarts

✅ Operational instructions and technical alerts

✅ Validator program updates and governance notices

nodectl requires you to create a configuration file with the necessary parameters to properly enable delegated staking according to your preferences and requirements.

First time and future updates

Regardless of whether this is your first time configuring your node for delegation, you must create or update the configuration file to define the specific parameters you want to use when offering your node for delegation.

If you wish to change any delegated staking parameters in the future, you must update the configuration file first before submitting a request to apply those changes to your node’s delegated staking settings.

Become a Dor Operator

This document outlines the process for becoming a Dor Validator Node Operator, including the administrative steps, qualification requirements, and technical procedures.

If this is your first time configuring delegated staking you may to the next document page.

⌨️ Modify existing configuration

If delegated staking has already been configured, you will be asked if you would like to update the configuration. You can enter y.

In order to view your current delegated staking status, you may issue a status command at any time.

For a valid configuration, your node should report all parameter matches as True.

If any match is not True, please review your desired configuration and issue an as needed to ensure your desired settings and consistency with the cluster.

In the event that you have already issued an update with your current settings (no changes were necessary), nodectl will prevent an unnecessary cluster update, and decline your request.

If the nodectl utility responds without applying any changes, the most likely reason is that your node is already configured with the delegated staking settings you specified.

If this is not the case, review and and submit another to ensure your desired changes are applied.

As a Dor Validator Node Operator, you are eligible to earn rewards for supporting the Dor metagragh.

Dor validator Node Operators are eligible for two types of rewards.

What Is a VPS?

A Virtual Private Server (VPS) is a virtualized computing environment that runs on a physical server hosted in the cloud. It functions like a standalone server but shares physical hardware with other VPS instances.

☁️ Key Characteristics

• Virtualized Environment A VPS runs independently with its own operating system, file system, allocated CPU, RAM, and storage; despite being hosted on a shared physical machine.

• Cloud-Hosted The underlying infrastructure is managed by a cloud provider, meaning you do not need to maintain or understand the physical server itself.

• Private and Isolated Your VPS instance operates in isolation from other virtual machines on the same host, offering consistent performance and greater security than shared hosting.

🛠️ Role in Constellation Network

In the context of running a Constellation Network Validator Node, the VPS:

• Hosts the full node stack, including Tessellation binaries, keystores, and supporting services

• Connects directly to the Constellation Hypergraph or metagraph cluster

• Acts as your validator’s public-facing presence on the network

A VPS offers a reliable, flexible, and cost-effective way to run your node 24/7 without managing physical hardware, making it ideal for decentralized infrastructure participation.

Introduction

One of the lesser defining characteristics of a Constellation Network Validator Node is its ephemeral nature. This means that nodes are designed to be easily rebuildable, making re-deployment a cleaner and often more efficient solution compared to deep troubleshooting.

Whether you're:

• Experiencing inconsistent OS behavior,

• Choosing to upgrade your distribution via a fresh VPS (rather than an inline upgrade),

• Switching cloud providers,

• Or facing any other scenario that requires spinning up a new instance,

Rebuilding your node is not only possible, it’s encouraged.

🔄 Rebuilding with Your Existing .p12 Keystore

This guide will walk you through the process of reinstalling your existing .p12 keystore on a new VPS instance so your validator node can resume operation quickly and securely.

By the end of this process, your new instance will be configured with your existing wallet, allowing you to seamlessly rejoin the network without starting from scratch.

Step 1️⃣

Connect to your OLD VPS and backup ( obtain ) your current p12 keystore.

Step 2️⃣

Rebuild your VPS

Step 3️⃣

Restore your p12 to the new VPS prior to begin an installation.

Step 4️⃣

Follow either the Quick Install or Normal Installation guide up to the migration section.

At that point:

1. When prompted, select y to proceed with the keystore migration.

2. nodectl will automatically scan your VPS for any available .p12 keystore files.

3. In this scenario, it should detect only one .p12 file, the one you uploaded during the earlier step.

Select the identified .p12 keystore and continue following the installation guide as normal to complete your validator node setup.

This guide is intended for restarting your Validator node following a Hypergraph or metagraph cluster restart.

Cluster restarts may occur for a variety of operational reasons, including:

✅ Network upgrade

✅ Seed list access updates

✅ Cluster-wide error resolution

🔁 Optional: Auto Restart Feature

If you have the auto_restart feature , your node may have already recovered automatically.

SSH Keys Explained

What Are SSH Keys?

When a Node Operator (Administrator) builds a VPS (Virtual Private Server) in the cloud, they need a secure method to access and administer that instance. This is typically done by connecting to the VPS from a local machine (e.g., a laptop or desktop) over the Internet.

Why Do We Use SSH?

Data traveling across the Internet is vulnerable to interception by malicious actors who may attempt to steal, monitor, or manipulate the connection. To defend against this, we use encryption to create a secure tunnel between the local and remote systems.

How SSH Keys Work

SSH keys are a pair of cryptographic keys:

• A public key, which is shared with the remote server

• A private key, which is kept securely on your local machine

These keys are used to:

• Authenticate your identity

• Establish an encrypted connection

• Securely transmit commands and data

Create SSH keys

Encryption in Action

In the context of connecting to a cloud VPS:

• The public key (stored on the VPS) is used to encrypt the data

• The private key (on your local machine) is used to decrypt it

This ensures that only your local machine—with the private key—can access and interpret the data sent by the server.

🛡️ SSH key authentication is significantly more secure than using a password alone and is the standard method for managing Constellation Network nodes in cloud environments.

nodectl Installation Types

Introduction​

The following documentation will help guide a new Node Operator understand the differences between turning a newly created VPS into a Constellation Network validator node with the use of nodectl.

There are three options:

Normal Install

A normal installation is a more detailed and interactive method of installing nodectl on your VPS. The process will guide you through each step of the installation interactively with details on each step, along the way.

Quick Installation

This installation method installs nodectl with minimal prompts or user interaction. You will only be asked a few questions:

• Which cluster you would like your node to join

• Whether you want to migrate an existing .p12 keystore

• Passphrase for the .p12 keystore:

.

Manual Installation

This new installation can be preformed if desired by advanced users.

nodectl is recommended.

Before You Begin

You should now have access to the Constellation Network Official Discord server via an invite provided for Node Operators.

At this point, your VPS should be fully configured and operating as a Constellation Validator Node.

If you believe any steps were missed, please revisit the previous documents to ensure all required tasks are completed before moving forward.

Introduction

This guide walks you through upgrading your Validator node to the latest version of Tessellation using nodectl, leveraging non-interactive mode with recommended defaults. Please refer to the full upgrade guide for a more detailed walk-through.

What Is a Tarball File?

A tarball file is a type of archive commonly used on Unix-based systems such as Linux and macOS. These files typically carry extensions like .tar, .tar.gz, or .tgz.

📦 Purpose and Usage

To update your current delegated staking parameters or to commit them for the first time to the metagraph, you will need to implement an update.

This command finalizes your configuration by submitting it to the metagraph, making your node available for delegated staking based on the parameters you've set.

Copy Your Public Key for Upload

When it's time to upload your public SSH key to your VPS, you can return to this section as a quick reference.

🔐 How to Locate and Copy Your Public SSH Key

Prerequisite Steps Before Node Creation

Discord Account

You will need a Discord account.

If this is NOT your first time configuring delegated staking, and you are looking for a way to update your delegating staking parameters, you may skip to the .

✨ Welcome first time delegators!

If this is your first time configuring delegated staking on your node, you will be presented with a CONFIGURATION NOTICE screen.

Simply read through the notice and press any key to continue.

Forks in the Constellation Network

In the context of the Constellation Network's Hypergraph or metagraph clusters, the concepts of majority fork and minority fork relate to how the network reaches consensus during discrepancies, synchronization issues, or splits in transaction history.

What is a Majority Fork?

A majority fork occurs when the majority of validator nodes in the network agree on a particular version of the transaction history. This version becomes the canonical chain and is recognized as the valid state of the network.

Unlike traditional linear blockchains, Constellation uses a Directed Acyclic Graph (DAG) architecture. In this system, the majority fork represents the most widely accepted state of the DAG, ensuring consistency, correctness, and security.

Majority forks typically occur during routine operations—such as when one of the three source nodes in a cluster is restarted during an upgrade or maintenance cycle.

Examples:

• Tessellation is upgraded from version vX.0.0 to vX.0.1.

• Two conflicting transaction histories emerge, and the one accepted by most validators becomes part of the official ledger.

What is a Minority Fork?

A minority fork occurs when a smaller subset of nodes deviates from the consensus and follows an alternate transaction history. This version of the DAG is generally considered invalid or non-authoritative because it lacks sufficient validator support.

Minority forks may arise due to:

• Network partitioning

• Incomplete upgrades

• Misconfigurations

• Malicious behavior

In the Constellation Network, these forks are automatically disregarded by consensus protocols, as they fail to meet the quorum thresholds for validation.

Example:

• Tessellation is upgraded to vX.0.1, but one or more nodes remain on vX.0.0, resulting in those nodes temporarily diverging into a minority fork.

Considerations

• Transactions included in a minority fork may temporarily appear valid to affected nodes.

• Once consensus re-aligns with the majority, those transactions are rejected and excluded from the network’s official state.

Implications in Constellation’s Network

Security and Stability

Prioritizing the majority fork ensures that only the most secure and validated version of the ledger is retained, which protects against double spending and preserves network reliability.

Fork Resolution

The network includes automated mechanisms to reconcile forks. Nodes on a minority path are guided back to the consensus-approved chain, restoring full alignment across the network.

Final Thoughts

The majority fork represents the unified, authoritative state of the Constellation Network. The minority fork is a temporary divergence, typically caused by upgrades or desynchronization, and is automatically corrected through the network’s consensus process.

You should now be in the configurator and at the section where you're prompted to enter the necessary parameters to enable delegation.

These parameters will define how your node appears to other delegated staking participants, allowing them to discover and delegate to your node based on the options you set.

✅ Enter Delegation Parameters​

🏁 Final Instructions

Your configuration will be created or updated to match your requested parameters and final instructions will appear.

Press any key and you will be returned the main menu of the configurator.

❌ Quit Configurator

Your configuration is complete, you may issue a q to exit the configurator and return to your node's command line interface.

Introduction

As nodectl evolves, the upgrade process also changes.

This guide helps bring your outdated nodectl installation up to the current recommended version using a versioned, step-by-step upgrade path.

Directly From The nodectl Utility

Manual Download

🧠 Understanding the Issue

The EdgePointDown status typically indicates a failure in establishing communication between your node and the network’s edge points.

A known root cause is the system resolving outbound connections using IPv6 instead of IPv4, which can happen in scenarios such as:

• The cloud provider defaults to IPv6 or uses IPv6-to-IPv4 translation

• The network infrastructure between your VPS and Constellation’s edge points mishandles IPv6

• DNS resolution or routing forces IPv6 where IPv4 is required for compatibility

Check IPv6 Status

⚠️ If either status is already disabled, your issue is not IPv6-related. Stop here and seek assistance from a Team Lead via the .

Restart Auto Restart (Optional)

To ensure the monitoring service is in sync with the updated configuration:

Conclusion

✅ Your node should now resume connection attempts using IPv4.

If the EdgePointDown issue was caused by IPv6, it should be resolved.

If problems persist, please reach out to the Constellation Network support team or a Team Lead in Discord.

For a more descriptive build guide, please start here:

Introduction

This guide provides a streamlined process to upgrade your nodectl utility to the latest supported version, while following the recommended upgrade path.

🎉 Congratulations!

Your node is now running the latest version of nodectl, fully updated and ready for continued participation in the Constellation Network.

You can confirm your version using:

Enabling this configuration allows your node to:

• Automatically monitor and restart services if they become unresponsive or disconnected from the cluster

• Automatically check for and apply updates via nodectl when new versions of Tessellation are available (based on your configuration preferences)

This ensures your node remains healthy, up-to-date, and engaged in network operations with minimal manual intervention.

This guide walks you through the fully automated “quick-install” of a Constellation validator node using nodectl’s --quick-install mode. All defaults are recommended settings, and you’ll see a live progress bar throughout.

Begin Quick Install

System Requirements

To run a Metagraph Validator Node, ensure your machine meets the following minimum requirements:

• Memory (RAM):

Introduction

This guide provides a series of basic troubleshooting steps to help you resolve issues with the alerting module associated with the auto_restart feature in nodectl.

Qualifications

To qualify as a Dor Validator Node Operator, you will need to complete a few administrative tasks as part of the onboarding process.

Please refer to the following document for detailed instructions on how to become a Dor Validator Node Operator:

📄

This guide outlines the necessary steps, requirements, and submission process to get started. Be sure to review it thoroughly to ensure a smooth and successful onboarding experience.

⚠️ Guide Usage

This guide assumes that you have properly created and connected to your VPS successfully and installed the nodectl utility.

🧰 Prerequisites

Before beginning, ensure you’ve reviewed the full checklist and profile documentation.

• This guide uses dag-l0 as the profile name.

• Replace dag-l0 with your node’s actual profile name if it differs.

  • For example dor-dl1 for Dor data layer1 validator nodes.

🔐 SSH Into Your VPS

Use the following command to connect to your VPS via SSH:

📄 Verify Your Node Is on the Seed List

To confirm that your node is recognized by the network, run:

Expected Output:

🛑 If you are not on the seed list, stop here and contact a Discord Administrator Team Lead via the Constellation Network Official Discord. You must wait for the next cluster restart that includes a seed list update before continuing.

⬆️ Perform a Node Upgrade

Use the upgrade command to prepare your node for the cluster connection:

The -ni flag enables non-interactive mode, accepting default values automatically.

⚙️ For Single Layer1 Nodes

If you're operating a Layer1-only Metagraph Validator, you may skip directly to the Join Layer1 step at the bottom of this guide.

🧬 For Hybrid Nodes

Hybrid nodes must reach a Ready state on Layer0 before joining Layer1.

⚠️ Expected Behavior:

After your node completes Layer0 connection steps, it will attempt to join the Layer1 profile and fail. This is expected and not a concern at this stage.

This happens because Layer1 participation is blocked until your node fully syncs the Layer0 snapshot chain.

During this period, your node will transition through the following statuses:

• SessionStarted

• DownloadInProgress

📥 Monitor for DownloadInProgress State

After upgrading, verify your node has reached the correct syncing phase:

Expected Output:

If you see SessionStarted, continue running the command periodically until it transitions to DownloadInProgress.

⏳ Wait for Ready State

Your node will now download the entire snapshot chain from the Layer0 cluster. This process may take several days.

You have two options:

• Wait for your node to reach the Ready state.

• Proceed to the optional next step to speed up the snapshot process using the Starchiver utility.

🚀 Optional: Execute Starchiver to Speed Up Sync

To accelerate snapshot syncing:

👀 Monitor your node closely to ensure the process completes without error.

🚧 Caution: Starchiver is a community-supported tool and not officially supported by Constellation Network. Use at your own risk. For issues, contact the tool's maintainer via GitHub or seek help on the Constellation Discord.

📊 Verify Node Status

Once your node has completed downloading the snapshot chain, it will enter the Ready state and begin participating in consensus.

To verify:

Look for the following:

For Layer1:

🔄 To monitor the transition in real time:

Use the q key to exit the watch command gracefully.

🔗 Join Layer1 (For Hybrid Nodes Only)

If Layer1 displays ReadyToJoin, you may initiate the join process:

If your node is in any other state, restart the profile before retrying:

Once the above steps are complete and your node is fully synced and participating in consensus, your first-time connection process is complete.

This guide outlines the steps required to collateralize your node’s hot wallet, meeting the staking requirements needed to join the Constellation Network Hypergraph or a metagraph.

Before Be Begin

From now on, all instructions will be executed on your remote VPS, not on your local system.

Please make sure to set up and connect to your remote VPS before continuing.

Download the nodectl binary

Before you Begin​

If you’ve chosen to use nodectl to create your node, excellent choice! You should skip this section of the instructions.

Users leveraging nodectl do not need to perform any of the steps outlined here, as nodectl handles all of them dynamically and automatically.

Manual Installation

Environment variables chart

Cluster Removal

Leave Cluster

To leave the cluster after a process has been started and joined.

Stop jar processes

Find the process(es) associated with your node

Kill the process(es)

🔐Backup P12 Keystore File

Maintaining an up-to-date and secure backup of your .p12 file is essential for protecting access to your Validator node and wallet. This guide will walk you through securely backing up and restoring your .p12 file using a macOS or Windows system.

🔄 Restore P12 Keystore File

Before We Begin:

IntegrationNet vs. MainNet Node Setup

When building your Validator node, it’s important to understand the key distinction between IntegrationNet and MainNet from a node operator perspective.

While both environments serve critical roles in the Constellation ecosystem, the primary difference during setup is related to collateral staking.

🔄 IntegrationNet Overview

• IntegrationNet is a non-production environment used for development.

• It operates on a separate, non-economic Hypergraph cluster.

• $DAG tokens used in IntegrationNet have no monetary value and cannot be transferred to MainNet.

💼 Hot Wallet Behavior

• The hot wallet on an IntegrationNet node does not hold real $DAG tokens.

• As such, collateral staking is not required or validated directory from the node, in this environment.

• This allows new Constellation specific metagraphs, Enterprise metagraphs, and Eco-system develped metagraphs test metagraph functionality and behaviors, before moving into production.

🧩 Required: Lattice Integration

To operate a node on IntegrationNet:

1. Create an account on the .

2. Connect a DAG wallet address through the IntegrationNet Node Operator Program.

3. This wallet is used for tracking your staking collateral.

1. Build your IntegrationNet node, using the guide options presented below.

🛠️ Summary

Understanding this distinction will help you correctly prepare your node for the appropriate environment and avoid unnecessary confusion during setup.

Quick Start Guide Options

To build your IntegrationNet node, you may either use two options:

1. Detailed Build your Node guide (recommended).

1. Expert minimalistic guide

Before we begin

Please make sure you created your SSH key pairs prior to starting these steps.

VPS Build Procedure

Introduction

This guide walks you through configuring basic alerting and reporting for your Validator node using the nodectl utility. It enables email notifications if your node drops from the cluster (excluding local network outages).

Introduction

This guide is designed to help you troubleshoot and restore SSH access to your Validator node when it was previously working but is now unreachable.

Common Steps

🤔Terminology

Table of Contents

Prerequisites

• VPS IP address ( )

This page provides a step-by-step guide on how to create SSH (Secure Shell) keys for securely accessing your VPS or server. SSH keys are a more secure alternative to password-based authentication and are essential for managing your Constellation Network validator node.

You’ll learn how to generate a key pair. This guide is ideal for both new and experienced operators looking to establish a secure and reliable connection to their node infrastructure.

Securing Your Validator Node in an Open Internet Environment

In traditional, centralized server infrastructures, critical systems that require direct internet access are protected by layered security controls.

These environments typically include a full suite of professionals; System Administrators, Site Reliability Engineers, Network Engineers, Security Engineers, and others. These experienced professionals are responsible for hardening systems and defending them from external threats.