> For the complete documentation index, see [llms.txt](https://docs.zetrix.com/en/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zetrix.com/en/architecture/consensus-mechanism/dpos/key-configuration.md).

# Key Configuration

| Parameter             | Value                  | Purpose                                                                                                                                                                                  |
| --------------------- | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Block lag threshold   | 2 blocks               | Maximum block sequence lag before a validator is frozen                                                                                                                                  |
| Heartbeat threshold   | 47 hits/hour           | Minimum cache heartbeat increments per hour to qualify as online. Math: PING every 15s, incremented every 3 PINGs (\~45s) → \~80 max/hr. 47/80 ≈ 58.75% uptime required within the hour. |
| Online rate threshold | 80%                    | Minimum percentage of hourly push slots a validator must appear in to qualify for daily reward                                                                                           |
| Forecast depth        | 3 blocks               | Number of blocks forecasted ahead for early freeze detection                                                                                                                             |
| Admin validator list  | (configured addresses) | Protected validators that are never frozen                                                                                                                                               |
| Freeze master switch  | configurable           | Enables or disables all freeze operations system-wide                                                                                                                                    |

### Operational Notes

#### Freeze policy

Freeze decisions are not based on a single signal source. The system can freeze validators due to forecast-based risk or due to actual sequence lag seen during the reconciliation job.

#### Protected validators

The admin exclusion list prevents certain validators from being frozen automatically. This is an explicit policy exception and should be reviewed carefully because it changes the behavior of automated health enforcement.

#### Reward qualification is not equivalent to active status

A validator may move between ACTIVE and FROZEN during the cycle yet still qualify for reward if its hourly online participation satisfies the contract threshold for the relevant period.

#### Record clearing is part of settlement

The heartbeat contract clears its stored timestamp records after extract() consumes them. That means the monitoring dataset is intentionally cyclical and aligned to the reward interval.

#### Batching and nonce handling

The extractTransfer(list\[]) phase uses batches of 10 validators and waits two minutes between batches. This indicates that operational safety around transaction sequencing is a deliberate part of the design.

### Summary

Zetrix DPOS operations are built around a layered control model:

* fast validator health monitoring,
* periodic online-state recording,
* contract-based reward qualification, and
* batched daily reward transfer.

The design separates monitoring evidence, validator state enforcement, and reward settlement while still connecting them through well-defined contract calls and scheduled jobs.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.zetrix.com/en/architecture/consensus-mechanism/dpos/key-configuration.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.