XityChain

Consensus, explained publicly

What you need to understand about how the chain agrees. We explain the model in full. We do not publish the operational internals that would help an attacker.

Public explanation · operational details are restricted.

Practical Byzantine Fault Tolerance

XityChain uses Practical Byzantine Fault Tolerance (PBFT). PBFT produces deterministic finality: once a block is committed it cannot be reverted, and the protocol tolerates up to one-third Byzantine validators.

The three phases

  1. Pre-prepare (leader proposes)
  2. Prepare (validators acknowledge)
  3. Commit (final, irreversible)

Safety under fault

PBFT requires a quorum of two-thirds of validators to commit a block. This is the mathematical safety guarantee under up to one-third faulty validators.

Current operating mode

XityChain currently runs in single-validator mode, where the operator is the sole proposer. This produces instant finality. Multi-validator operation is designed but not activated.

We explain what the consensus achieves, not how to break it. The view-change logic, the leader-selection details, and the failover procedures are operational and therefore classified.
What we publish
Public
Model and guarantees
PBFT, three-phase commit, quorum rule, current mode.
What we summarise
Partial
Validator transition plan
Multi-validator council operation is on the roadmap at a high level.
What we restrict
Restricted
Operational internals
Failover, leader-selection detail, topology, attack surface.
On the roadmap

A council of validators, in time

Single-validator operation is the honest current mode. Transition to a council of independent validators is designed, under review, and on the public roadmap.