Skip to content

Consensus

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.

When does consensus kick in?

Consensus is triggered exclusively when an account publishes two or more blocks at the same position in its chain — a fork. This is the only scenario that requires network-wide agreement.

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.

                    ┌──────────┐
              ┌────▶│ 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:

Stage Component Description
1. Detection Conflict Detection Node detects two blocks with the same Previous hash
2. Weight Delegation Representatives derive voting power from delegated XE balances
3. Voting Voting Representatives cast signed votes for the block they support
4. Resolution Quorum Once 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:

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.

Only XUSD confers voting weight

XE balances do not contribute to voting weight. Only XUSD balances delegated to a representative count toward that representative's voting power. See Delegation for details.

Conflict Lifecycle

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