Skip to main content

Types of Nodes

The same TelosZero Core nodeos binary can serve several roles. Security, plugins, storage, and finalizer settings differ by role, so production operators should not combine every workload on one host.

RoleProduces blocksBLS keyVote threadsPublic service
Private producer/finalizerYes, when scheduledOne unique key per host4No
Backup producer/finalizerPaused until an exclusive failoverDifferent pre-registered key4No
Vote relay/sentryNoNo4P2P as required
Chain APINoNo0/unsetHTTP through a hardened proxy
State History (SHiP)NoNo0/unset unless also a vote relayWebSocket to trusted consumers
Seed/P2PNoNo0/unset unless also a vote relayP2P

Producer/finalizer nodes

An active BP's private producer signs scheduled blocks with a K1 key and finalizer votes with a BLS key. The BLS key, vote-threads, and persistent finalizers-dir make this role different from a legacy producer configuration.

Use minimal plugins and private networking. Public RPC, history, and indexing workloads belong on separate hosts. See Set Up a Telos Block Producer.

Vote relay/sentry nodes

Relays protect private producers from direct internet exposure and provide redundant P2P paths. Every intermediate relay that must carry Savanna votes needs a positive vote-threads setting, normally 4, but it does not hold a BLS key.

A generic public seed that is not on a producer's vote path can leave vote processing disabled.

API nodes

API nodes expose the chain API used by wallets, applications, exchanges, and monitoring. Bind nodeos HTTP locally and place TLS, access control, rate limits, and caching on a reverse proxy. API nodes do not need producer or finalizer keys.

State History nodes

SHiP nodes enable eosio::state_history_plugin and stream block, trace, table-delta, and optional finality history to Hyperion or other indexers. They require substantially more storage and I/O than a chain-only API node.

Do not use the removed history_plugin. For EVM history, see telos-reth.

Seed/P2P nodes

Seed nodes accept P2P connections and help new nodes discover and synchronize with the network. Use multiple independently operated peers and obtain the current list from validators.telos.net or the Telos node-template repository. Avoid copying static peer lists from old guides.