Docs
30%22%18%16%14%67%100%

Consensus

How XE reaches consensus across the lattice

#Overview

XE does not use consensus for normal operation. Unlike traditional blockchains where every transaction must be globally ordered and agreed upon, XE's block lattice architecture means each account maintains its own chain. Blocks are validated locally using cryptographic signatures, balance checks, and proof-of-work — no global agreement is required.

Consensus only activates when something goes wrong: equivocation.

#The Problem: Equivocation

An equivocation (also called a double-publish or fork) occurs when an account signs two different blocks that both reference the same Previous hash. This is the block lattice equivalent of a double-spend: the account is trying to create two conflicting histories.

diagram
                    ┌──────────┐              ┌────▶│ Block A  │  (send 100 XE to Alice)              │     └──────────┘┌──────────┐  ││ Previous │──┤     ← same Previous hash = CONFLICT└──────────┘  │              │     ┌──────────┐              └────▶│ Block B  │  (send 100 XE to Bob)                    └──────────┘

Only one of these blocks can be accepted. The network must decide which one wins and which one is rejected.

#How It Works

XE uses delegated voting to resolve conflicts. The process has four stages:

StageComponentDescription
1. DetectionConflict DetectionNode detects two blocks with the same Previous hash
2. WeightDelegationRepresentatives derive voting power from delegated XE balances
3. VotingVotingRepresentatives cast signed votes for the block they support
4. ResolutionQuorumOnce 67% of delegated weight agrees, the winner is confirmed

#Quorum Threshold

A conflict is resolved when a single block accumulates votes representing 67% of total delegated XE weight. This is computed as:

text
blockWeight * 100 >= totalWeight * 67

All weight calculations use big.Int to prevent overflow with large XE supplies.

#Deterministic Tie-Breaking

When a representative detects a conflict, it votes for the block with the lexicographically lowest hash. This ensures that honest representatives converge on the same block regardless of network propagation order, preventing an attacker from manipulating which block wins by controlling message ordering.

#Design Principles

Minimal consensus surface. The vast majority of blocks never touch consensus. A well-behaved account simply appends blocks to its chain, and peers validate them independently. Consensus machinery only runs when an account misbehaves.

Weight snapshots. When a conflict is detected, the current delegation weights are snapshotted and frozen for that conflict. This prevents an attacker from manipulating delegation between detection and resolution.

Fallback resolution. If non-voting representatives inflate the total weight such that 67% is unreachable, a fallback mechanism resolves the conflict after a delay when all actual voters agree unanimously.

#Conflict Lifecycle

diagram
Account publishes Block B with same Previous as existing Block A    │    ▼checkAndRecordConflict() detects equivocation    │    ├── Block B stored in staging (not main chain)    ├── Weight snapshot taken    │    ▼ConflictCallback fires → VoteManager.OnConflict()    │    ├── Local representative votes for lowest hash    ├── Vote signed with ed25519 and broadcast    │    ▼Votes arrive from network → VoteManager.ReceiveVote()    │    ├── Signature verified    ├── Weight looked up from snapshot    │    ▼QuorumManager.OnVote() retallies after each vote    │    ├── blockWeight * 100 >= totalWeight * 67 ?    │    ▼confirmConflict()    │    ├── Winner: StatusConfirmed (promoted from staging if needed)    ├── Losers: StatusRejected    ├── Votes, staged blocks, conflict record cleaned up    └── Confirmation height updated