Skip to content
Tenzro
← All tutorials
Tutorial · Operate

Run a validator node

Run a Tenzro DAG Consensus validator on any TPM 2.0 machine: hardware-derived keys, self-registration, activation at the next epoch and a 7-day unbonding period.

Advanced45 min

Validators order transactions and sign finality for Tenzro Network 1. They run Tenzro DAG Consensus (TDC), our post-quantum consensus protocol: every validator proposes in parallel each round, validators talk over channels keyed by X25519 and ML-KEM-768, and every finalized checkpoint carries a finality certificate signed with ML-DSA-65.

Joining the validator set is permissionless. Any machine with a TPM 2.0 can run a validator. There is no key file to generate, copy or lose: the node derives its signing keys from the TPM on demand, uses them in memory and wipes them.

Prerequisites

  • A Linux machine with a TPM 2.0 (or a Mac with a Secure Enclave), kept online.
  • Inbound TCP and UDP on port 9000 for peer traffic.
  • TNZO for the validator self-stake plus gas, in the account the node derives (step 4). The current minimum is published on chain and shown by the node.
  • The tenzro-node and tenzro binaries from Downloads or built from source.

1. Install the node

Build from source if you are not using a release binary:

bash
git clone https://github.com/tenzro/tenzro-network.git
cd tenzro-network
cargo build --release -p tenzro-node -p tenzro-cli
sudo cp target/release/tenzro-node target/release/tenzro /usr/local/bin/
tenzro-node --version

Every validator on the network must run a compatible release. A node running a different build or a different genesis computes a different state root and its messages are rejected.

2. Check the TPM

The node uses the TPM to root its identity. Confirm the device is present and readable by the user that will run the node:

bash
ls -l /dev/tpmrm0
tenzro hardware

tenzro hardware reports the machine profile the node sees, including its hardware security capability.

3. Start the node as a validator

bash
tenzro-node \
  --roles validator \
  --data-dir /var/lib/tenzro \
  --listen-addr /ip4/0.0.0.0/tcp/9000,/ip4/0.0.0.0/udp/9000/quic-v1

With no --genesis or --boot-nodes flags the node finds Network 1 through its bootstrap peers and verifies the chain against the built-in Network 1 genesis. On first start it:

  1. Derives its validator identity from the TPM. The consensus key (ML-DSA-65 with P-256) is derived from the hardware on demand; nothing is written to disk.
  2. Opens authenticated, post-quantum channels to its peers.
  3. Syncs to the head of the chain, verifying finality certificates as it goes.

Until it is registered and activated, the node runs as a non-voting node: it verifies and relays but does not propose or vote. That is expected.

The RPC listens on 127.0.0.1:8545 by default. Leave it on loopback, or put it behind a reverse proxy; admin methods on it require the operator's admin token.

4. Fund the validator account

The node's validator account is derived from the same hardware root. Find its address in the node status, send it enough TNZO for the self-stake plus gas, and check the balance:

bash
tenzro node status
tenzro wallet balance --address <your-validator-address>

5. Register as a validator

Restart the node with a self-stake in wei (1 TNZO is 10^18 wei). The node signs its own registration transaction with its hardware-derived keys; there is nothing to paste or export.

bash
tenzro-node \
  --roles validator \
  --data-dir /var/lib/tenzro \
  --validator-self-stake <self-stake-in-wei>

Registration is rejected if the stake is below the on-chain minimum or the account cannot cover it plus gas. Check that the registration landed:

bash
tenzro validator get <your-validator-address>
tenzro validator list --status Candidate

6. Wait for epoch activation

New validators enter the active set at an epoch boundary, after a short activation delay. Your status moves from Candidate to PendingActive to Active:

bash
tenzro validator list --status PendingActive
tenzro validator list-active

Once active, the TPM certifies an in-memory session key once per epoch, and your node signs its votes with that key. The hardware is used at the start of each epoch, never on the hot path of every vote.

7. Monitor the validator

bash
tenzro node status
tenzro node syncing
curl -s http://127.0.0.1:8545 -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tenzro_getFinalizedBlock","params":[]}'

A healthy validator has peers, is not syncing, and sees the finalized height advance. Prometheus metrics are served at /metrics on the web API port.

Run the node under systemd with automatic restart. After a crash or reboot it re-derives the same identity from the same TPM, so it comes back as the same validator. Never run two nodes from the same identity: signing two conflicting checkpoints is provable from the finality certificates and is slashed.

8. Rewards and slashing

Validators earn rewards paid from a finite genesis pool; TNZO is not minted, and its supply is fixed at 1,000,000,000. Rewards and unbonded principal settle to the validator's withdrawal address.

Slashing burns the offender's bond. The provable offences are double-signing (two conflicting finality signatures) and the faults described in Slashing.

To add stake later:

bash
tenzro validator increase-stake --from <your-validator-address> --additional <wei>

9. Exit and unbond

Leaving is a signed exit transaction. The validator leaves the active set at the next epoch boundary, and the stake unbonds over 7 days. The stake stays slashable during unbonding, so evidence of a fault committed while active can still be acted on.

bash
tenzro validator exit --from <your-validator-address>
tenzro validator get <your-validator-address>

Next steps