Skip to main content

Install TelosZero Core

Telos block producers run TelosZero Core, the Telos-maintained continuation of Antelope Spring. The package provides the familiar nodeos, cleos, keosd, and spring-util commands and includes Savanna instant-finality support.

Post-Savanna guide

This is the steady-state installation path for a network where Savanna instant finality is already active. It does not cover the one-time Lightspeed/Savanna activation or switchtosvnn process.

Supported release

The current public production package is:

ItemValue
Releaseteloszero-v1.2.2
Packageteloszero-core_1.2.2_amd64.deb
SHA-256285fdfc1abde5104892d94b1f380c6d79aba35eac3413f139119ea88574c5007
Release-validated hostUbuntu 22.04, x86-64

Always use a tagged TelosZero Core release approved for the target Telos network. Do not deploy the repository's main branch or silently substitute a newer release without an operator notice and validation.

The project source also documents Ubuntu 20.04 builds, but the teloszero-v1.2.2 release notes record the package install smoke test on Ubuntu 22.04. Treat another host OS as an explicitly tested operator exception, not an assumed production target.

1. Download and verify the package

cd /tmp
curl -fLO https://github.com/telosnetwork/teloszero-core/releases/download/teloszero-v1.2.2/teloszero-core_1.2.2_amd64.deb

echo '285fdfc1abde5104892d94b1f380c6d79aba35eac3413f139119ea88574c5007 teloszero-core_1.2.2_amd64.deb' \
| sha256sum --check --strict

The checksum command must print OK. Stop if it does not.

2. Install TelosZero Core

sudo apt-get update
sudo apt-get install -y ./teloszero-core_1.2.2_amd64.deb

The package conflicts with historical leap, spring, and antelope-spring packages because they install the same command names. apt may replace an older package during installation.

Verify the installed binaries:

nodeos --full-version
cleos version client
spring-util version full

The version may contain a Telos-specific patch suffix when an operator-approved hotfix is deployed. Match the complete version and artifact checksum to the current Telos operator notice; do not infer the approved producer build from a random public RPC endpoint.

3. Create a dedicated service account and directories

The examples in the BP guides use these paths:

/etc/telos/mainnet-primary/     configuration
/var/lib/telos/mainnet-primary/ node data, blocks, and snapshots
/var/lib/telos/finalizers/mainnet-primary/ finalizer voting safety state

Create them with restrictive ownership:

id -u telos >/dev/null 2>&1 \
|| sudo useradd --system --home-dir /var/lib/telos --shell /usr/sbin/nologin telos

sudo install -d -o root -g telos -m 0750 /etc/telos/mainnet-primary
sudo install -d -o telos -g telos -m 0750 /var/lib/telos/mainnet-primary
sudo install -d -o telos -g telos -m 0700 /var/lib/telos/finalizers/mainnet-primary

The instance-specific finalizer directory must be on persistent local storage. Never place it on tmpfs or a shared filesystem, and never share one directory between mainnet, testnet, primary, or backup instances.

4. Obtain a current snapshot

A new producer should start from a recent snapshot supplied by a trusted provider and then sync to head through multiple trusted peers.

Use a provider-published checksum when available. Place the decompressed .bin file under /var/lib/telos/mainnet-primary/snapshots/ and make it readable by the telos user.

sudo install -d -o telos -g telos -m 0750 /var/lib/telos/mainnet-primary/snapshots
sudo chown telos:telos /var/lib/telos/mainnet-primary/snapshots/<snapshot-file>.bin

The Telos mainnet chain ID is:

4667b205c6838ef70ff7988f6e8257e8be0e1284a2f59699054a018f743b1d11

Create the producer configuration before starting the snapshot; continue with Set Up a Telos Block Producer.

5. First start from the snapshot

Scheduled replacement hosts

If this host replaces a producer that may still be scheduled, set pause-on-startup = true before the snapshot import. Do not enable K1 block production until the old signer is stopped and fenced. Use a new BLS key and fresh local finalizer safety state on the replacement.

After creating config.ini, perform the first launch in the foreground:

sudo -u telos /usr/bin/nodeos \
--config-dir /etc/telos/mainnet-primary \
--data-dir /var/lib/telos/mainnet-primary \
--snapshot /var/lib/telos/mainnet-primary/snapshots/<snapshot-file>.bin

Use --snapshot only on this first launch. Stop the foreground process cleanly after it has loaded the snapshot, then start the systemd service described in the setup guide without the flag.

Existing producer nodes

For a normal package update:

  1. Confirm the approved release and checksum.
  2. Stop nodeos cleanly.
  3. Preserve the configuration, block log, and the live finalizer directory.
  4. Install the tagged package.
  5. Follow any release-specific replay or snapshot instruction.
  6. Restart and complete every verification check.
Finalizer safety state

An existing finalizer must retain the complete, current finalizers/safety.dat associated with its BLS key. Never restore an older copy, copy it to another host, or reuse the BLS key when this file is missing or uncertain. Follow Finalizer Setup and Operations instead.

If the node is still running Leap or pre-TelosZero Spring, use the TelosZero upgrade guide for the package and snapshot-format migration, then return to the BP configuration and finalizer guides.

Source builds

Production BPs should prefer the published package so every operator can verify the same artifact. If a source build is explicitly approved, use the exact tagged source and build instructions in the TelosZero Core repository, record the commit, and publish a reproducible package checksum to the BP coordination channel before deployment.