> For the complete documentation index, see [llms.txt](https://docs.dotone.online/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dotone.online/overview.md). # overview ![](https://dotonesmartchain.gitbook.io/files/KIswEucObbjEg4drZdsY) ## Validator Overview dotOne Smart Chain relies on a system of validators operating under a **Proof of Staked Authority (PoSA)** consensus mechanism, enabling short block times and low transaction fees. Validators are the backbone of the network — they propose and validate blocks, confirm transactions, and ensure the protocol runs securely and efficiently. ### What Is a Validator? Validators are nodes responsible for producing blocks and securing the dotOne network. They participate in packaging transactions, creating and validating blocks, and maintaining ledger consistency — earning **DOTO tokens** as rewards in return. A validator role is not purely technical. It is a long-term commitment to network reliability, uptime, and honest participation in consensus. ### Validator Election & Consensus dotOne conducts a **daily election** after 00:00 UTC to select the top active validators based on their staking rankings for block production. Among the elected set: * **Cabinets** — the validators with the highest staked amounts; more likely to be selected as consensus validators each epoch. * **Candidates** — the remaining active validators with a slightly lower probability of selection per epoch. Each epoch, a subset of Cabinets and Candidates is selected to form the **consensus validator set** responsible for producing blocks in that round. Validators not elected into the active set must wait for the next election cycle. > If a validator is selected for block production but fails to participate, it will face **slashing consequences**. ### Network Topology Validators on dotOne are interconnected via a peer-to-peer (P2P) network, supporting both direct and indirect connections. As a validator operator, you can choose between two deployment modes: **Mode A — Standard (Ease of Use)**\ Expose your validator's public IP directly to the P2P network. This mode offers high efficiency with fewer network hops. It is strongly recommended to disable HTTP access and protect your node's information to mitigate DDoS risks. **Mode B — Sentry Node (Enhanced Security)**\ Conceal your validator behind one or more **Sentry Nodes** — full dotOne nodes that act as a protective layer between your validator and the public network. This mode shields your validator from DDoS attacks and other external threats, and is the recommended configuration for production validators. ![](https://dotonesmartchain.gitbook.io/files/MamVPUNO01I7KSJdztqO) ### Economics Validator rewards come from two sources: * **Transaction fees** collected from blocks produced * **Commission fees** from delegators who stake DOTO to your validator As an example, assuming a block reward of 100 DOTO and a validator with 20% self-bonded DOTO and a 20% commission rate: | Distribution | Calculation | Amount | | ---------------------------- | ----------- | ----------- | | Commission (to validator) | 100 × 20% | 20 DOTO | | Remaining for delegators | 100 − 20 | 80 DOTO | | Validator's delegation share | 80 × 20% | 16 DOTO | | Other delegators' share | 80 × 80% | 64 DOTO | | **Total validator reward** | 20 + 16 | **36 DOTO** | Reward distribution is designed to encourage consistent performance, align validators with long-term network growth, and support decentralization over concentration. You can track validator activity and reward history on the [dotOne Explorer](https://explorer.dotone.network/txs). ### Risks & Slashing Validators who act dishonestly, behave maliciously, or fail to maintain uptime may face **slashing** — a penalty that reduces their staked DOTO. The severity of the penalty depends on the nature of the violation: **Double Sign**\ Running validator keys simultaneously on two or more machines constitutes a double-sign violation. Penalty: significant stake slash and an extended jail period preventing participation in consensus until manually unjailed. **Malicious Vote**\ Running the same consensus and voting keys concurrently across multiple machines is treated as a malicious vote violation. Penalty: stake slash and jail time; an unjail transaction may be submitted after the jail period expires. **Downtime**\ Missing a threshold number of blocks within a 24-hour window triggers an offline penalty. Continued downtime compounds the penalty and results in jail time, after which the validator must submit an unjail transaction to resume participation. **Low Self-Delegation**\ Validators must maintain a minimum self-delegation of DOTO. Falling below this threshold results in a jail period until the minimum is restored. > Anyone can submit evidence of double-sign or malicious vote violations and receive a reward for doing so, contributing to network-wide accountability. ### Validator Responsibilities Operating a validator means accepting responsibility for network integrity. Validators are expected to: * Maintain secure and stable infrastructure * Follow protocol upgrade procedures promptly * Avoid any malicious or manipulative behavior * Participate transparently in consensus at all times Network stability always takes priority. --- # 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.dotone.online/overview.md?ask=&goal= ``` `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.