Skip to main content

Telos Consensus

Telos combines stakeholder-elected block production with Savanna instant finality. TelosZero Core implements both parts of the protocol.

Two coordinated roles​

Block producers​

TLOS stakeholders elect registered block producers (BPs). The active producer schedule determines which BP may publish at each time slot.

With the standard 21-producer schedule:

  • each producer receives a six-second production round;
  • up to 12 blocks are produced in that round;
  • the target block interval is 0.5 seconds.

The scheduled BP signs each produced block with its K1 block-signing key. Every full-validation node independently checks the block and its transactions.

Finalizers​

Active BPs also operate Savanna finalizers. A finalizer uses a separate BLS key to vote on valid blocks continuously, including while another BP is producing.

Finalizer votes propagate over the P2P network and are aggregated into quorum certificates (QCs). A QC proves that the configured finalizer-policy threshold supported a block. With 21 equally weighted finalizers, the Telos system contract sets the threshold to 15.

The BLS key is separate from both the BP account authority and K1 block-signing key. BLS signatures are designed to aggregate many finalizer votes compactly.

How a block becomes final​

At a high level:

  1. The scheduled BP publishes a block.
  2. Full nodes validate the block.
  3. Finalizers make a safety-checked strong or weak vote.
  4. Votes travel through P2P peers and vote-capable relays.
  5. A supermajority of finalizer weight forms a QC.
  6. The certified block chain advances finality, and the last irreversible block (LIB) moves forward.

Savanna removes the legacy need to wait through full producer-schedule confirmation rounds. Under healthy network conditions, LIB remains close to head and advances continuously. Applications should still use the chain's authoritative finality signals—such as last_irreversible_block_num or transaction-finality APIs—instead of assuming that elapsed wall-clock time proves finality.

Strong and weak votes​

Finalizers maintain local safety information about prior votes and locks. A strong vote indicates the proposal satisfies the normal safe-extension conditions. A weak vote can preserve liveness during specific timing or branch conditions without violating the finalizer's safety rules.

The quorum-certificate logic validates the weight and consistency of strong and weak votes. Operators should treat sustained weak or missing votes as a diagnostic signal, not interpret a single warning in isolation.

Finalizer policy​

The native finalizer policy identifies:

  • a policy generation;
  • the finalizer threshold;
  • each finalizer's BP description, weight, and BLS public key.

Telos system-contract schedule updates keep the producer schedule and finalizer policy coordinated. A BP needs an active registered finalizer key before it is ready to join the active schedule.

During a producer-schedule or BLS-key change, nodeos may report both active and pending finalizer policies. Operators must wait for a replacement key to become active in the native policy and produce advancing votes before retiring the old key.

Finalizer safety state​

Each producer-capable host stores voting history in finalizers/safety.dat. That history prevents a BLS key from signing an unsafe branch after a restart or recovery.

The file and key form a host-local safety boundary:

  • never reuse one BLS key on two hosts;
  • never copy or roll back safety.dat;
  • when safety history is missing or uncertain, rotate to a never-used key.

See Finalizer Setup and Operations for the operator procedure.

DPoS governance and Savanna finality​

DPoS governance and Savanna consensus solve different problems:

  • stakeholder voting and the Telos system contract select the producer schedule;
  • the schedule assigns block-production slots;
  • the corresponding finalizer policy certifies blocks and advances instant finality.

Schedule selection remains dynamic, while finalizer-policy transitions are QC-protected so the network can change membership without abandoning safety.

Inspect live consensus state​

# Head and irreversible block
cleos -u https://mainnet.telos.net get info

# Active/pending finalizer policies and recent votes
cleos -u https://mainnet.telos.net get finalizer_info

# Producer schedule
cleos -u https://mainnet.telos.net get schedule

Public RPC state can show schedules, policies, and tracked votes. It cannot prove a BP's private key custody, relay topology, configured vote threads, or local safety.dat continuity.