DPOS Lifecycle Flow

This chapter explains how Zetrix Delegated Proof of Stake (DPOS) operates from an application and contract-integration perspective.

• how validator rotation is triggered,

• how freeze and unfreeze decisions are made,

• how heartbeat statistics are accumulated and stored,

• how reward eligibility is derived, and

• how daily reward extraction and transfer are executed.

System Overview

Zetrix uses Delegated Proof of Stake (DPOS). Validators are elected to produce blocks in rotation. Around that core block-production model, the platform runs a continuous operational loop that:

• monitors validator health,

• freezes lagging validators,

• restores recovered validators,

• records hourly online-validator status, and

• distributes rewards once per day.

The model operates on three time scales:

• every 10 seconds for rotation and forecast-based protection,

• every 1 minute for local sequence reconciliation,

• every 1 hour for heartbeat aggregation, and

• daily at 18:00 for reward settlement.

End-to-End DPOS Lifecycle

The following diagram shows the full lifecycle from startup through continuous monitoring, hourly statistics, and daily reward extraction.

Lifecycle explanation

The DPOS lifecycle is split into continuous safety checks, hourly evidence collection, and daily reward settlement. Sequence lag drives operational freeze decisions, while heartbeat inclusion drives reward eligibility.

Operational Jobs

ValidatorsRotateJob

Frequency: every 10 seconds

Purpose: rotate validator participation when the configured block slice and rotation interval require it.

Behavior summary:

• read DPOS configuration from chain,

• read the latest block sequence,

• decide whether the rotation threshold has been reached,

• identify candidates that can move from freeze-related state back to active participation,

• call updateValidator(), and

• log the rotation event.

ValidatorsForecastCheckJob

Frequency: every 10 seconds

Purpose: forecast upcoming producers and freeze validators that are already lagging.

Behavior summary:

• read current chain sequence,

• read the active validator list,

• calculate the next three expected producers,

• compare projected validators against local sequence progress,

• mark lagging validators as abnormal,

• skip protected admin validators, and

• call setFreeze(true) for the affected validators.

ValidatorsLocalSeqCheckJob

Frequency: every 1 minute

Purpose: reconcile validator state using current local and on-chain sequence numbers.

Behavior summary:

• read local validator sequence values,

• compare them with the latest on-chain values,

• restore frozen validators that have caught up,

• freeze active validators that exceed the lag threshold, and

• log any resulting state changes.

ValidatorsHeartStatisticJob

Frequency: every 1 hour

Purpose: convert raw heartbeat counts into an hourly online-validator snapshot.

Behavior summary:

• read configured validator addresses,

• read heartbeat counts from cache,

• check whether each validator reaches the hourly threshold,

• build the online validator list,

• push that list with the timestamp to the Heartbeat contract,

• persist the heartbeat statistic record, and

• reset counters for the next hour.

ValidatorExtractJob

Frequency: daily at 18:00

Purpose: finalize the daily reward cycle.

Behavior summary:

• reset heartbeat statistics in cache,

• call extract(),

• trigger on-chain reward calculation,

• read validator fund addresses,

• batch them in groups of 10,

• call extractTransfer() for each batch, and

• log the resulting transaction hashes.