Dendra

Operator guide

Update your kit

Kit v0.2.2 is required from 24 October 2026, 12:00 UTC. This page is for anyone who installed a Dendra miner or judge before v0.2.2: the update takes two commands, from your clone.

Check your kit Update it

Operator guides

The deadline

reading the season service

From 24 October 2026, 12:00 UTC (KIT_DEADLINE), the network’s floor is kit v0.2.2 (KIT_MIN=3).

  • The relay refuses the work of a kit older than v0.2.2.
  • The Final Testnet Season stops paying an identity on such a kit, from the season day that begins closest to the deadline. The season status names that day (kit_rules_from_day).
  • A kit on v0.2.0 or v0.2.1 does not update itself, and its miner does not tell you it is behind.

...

first season day under the kit rules (kit_rules_from_day)

...

kit floor in the season rules (rules.kit_min)

The network publishes the floor and the deadline itself. Read them yourself: if they differ from the sentence above, the network’s values are the ones that count.

Read the floor and the deadlineany terminal
$ curl -sf https://testnet-api.dendranetwork.com/network-info.txt | grep -E '^KIT_(MIN|DEADLINE)='

A full node or a validator declares no kit, so the deadline does not apply to it: update a node.

Check your kit

In your clone: ~/dendra-network when an installer made it. On Windows, open Ubuntu from the Start menu first.

Check the kitLinux, WSL 2
$ cd ~/dendra-network
$ bash deploy/testnet-miner/miner_health.sh

It compares the kit of your clone and of your running miner with the kit version the network publishes, and prints the update command for this machine, with the path of your clone. On v0.2.0 this script does not exist yet: go to Update.

The kit number of the clone alone: head -1 docker/KIT_VERSION prints 3 for v0.2.2, 2 for v0.2.1 and 1 for v0.2.0. It says what the clone holds, not what runs: only miner_health.sh reads the running miner.

Update: two commands

  1. Move the clone to the new release

    Run it from your clone, as in Check your kit. On v0.2.1, miner_health.sh prints the update line of this machine, with your clone’s path: when it differs from this one, use it. The tree you leave stays on the branch kit-before-update. This alone changes nothing that runs.

    Step 1from your clone
    $ git fetch origin && git branch -f kit-before-update && git checkout -B main origin/main

  2. Run join.sh again, with your first options

    It restarts the miner on the new kit. From v0.2.1, this prints your command, after DENDRA_KIT_RERUN=:

    Step 2aprints your first command
    $ grep DENDRA_KIT_RERUN deploy/testnet-miner/.env

    On v0.2.0 nothing is recorded: type the command you first used. If the installer set it up without any option, run this one:

    Step 2bno option at install
    $ CONFIG_URL=https://testnet-api.dendranetwork.com/network-info.txt bash deploy/join.sh

    On v0.2.2 the judge is on by default on a machine that can judge, even if your first command did not ask for it. With a GPU, add --no-judge to keep mining only.

  3. Check again

    Step 3from your clone
    $ bash deploy/testnet-miner/miner_health.sh

After v0.2.2. From v0.2.2 on, the kit checks once a day for a newer signed release and updates itself, with the options it recorded; --no-auto-update turns this off. A HiveOS rig is the exception: it updates through its package.

Special cases

HiveOS

Set the flight sheet’s Installation URL to the v0.2.2 package and keep the other fields:

Installation URLHiveOS flight sheet
https://github.com/DendraNetwork/dendra-network/releases/download/v0.2.2/dendra-0.2.2.tar.gz

Installed with install.sh --ref

The installer in your clone is the old one, and it does not pass --miner on correctly. Download the v0.2.2 installer, read it, then run it with the options you first gave it, such as --miner to keep mining only:

Downloadfrom your home folder
$ cd ~ && curl -fsSLO https://raw.githubusercontent.com/DendraNetwork/dendra-network/v0.2.2/deploy/install.sh
Read itquit with q
$ less install.sh
Run itadd your first options
$ bash install.sh --yes --ref v0.2.2

A machine without a GPU

Kit v0.2.2 runs no mining model on the CPU. Without a GPU, a machine joins only as a judge, from MOE_CPU_MIN_RAM_MB of system RAM, and --no-judge is refused. After step 1, the probe says which case is yours: its first line is judge, refused or unknown, and the second command prints the floor in MB.

Which role fits this machineafter step 1
$ bash deploy/hw_probe.sh --role
$ bash deploy/hw_probe.sh --judge-floor-mb

Below the floor, join.sh refuses and changes nothing, and the old miner keeps running on its old kit, whose work the relay refuses from the deadline. Take it off the network instead: the exit returns its stake to the key that registered it. Read the steps first:

Read the exit stepschanges nothing
$ bash deploy/testnet-miner/exit-miner.sh --help

A v0.2.0 kit

It has no miner_health.sh and no recorded command, and head -1 docker/KIT_VERSION prints 1. Do steps 1 and 2 with the command you first typed; miner_health.sh is there once the clone has moved.

Windows

Everything runs inside Ubuntu: open it from the Start menu, then follow the same steps.

Common mistakes

git pull

It fails with “refusing to merge unrelated histories”: each release republishes the repository. Use step 1.

Only step 1

The clone moves, and the old miner keeps running. Run join.sh again.

docker compose down -v

Never: it deletes the volume that holds your miner’s keys.

Help

Ask in #operator-support on the Discord, with the output of bash deploy/testnet-miner/miner_health.sh. What changed in v0.2.2: the v0.2.2 section of CHANGELOG.md.

Miner and judge

A new install, the checks and the judge.

Open the miner page

Node and validator

Join, bond, open the port, update.

Open the node page

Season rules

The kit floor, the judge reward and the probation.

Open the season rules