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:
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
Related Pages¶
- Delegation — how voting weight is derived from XE balances
- Conflict Detection — equivocation detection and staging
- Voting — vote casting, validation, and encoding
- Quorum — tallying votes and confirming resolution
- Accounts and Keys — ed25519 key pairs used for signing
- Block Types — the
Representativefield on blocks