Consensus
XE does not use consensus for normal operation. Consensus only activates for equivocation — when an account publishes two or more blocks at the same position (same Previous hash).
Four Stages
| Stage | Component | Description |
|---|---|---|
| 1. Detection | Conflict Detection | Detects two blocks with same Previous hash |
| 2. Weight | Delegation | Representatives derive voting power from delegated XUSD balances |
| 3. Voting | Voting | Representatives cast signed votes |
| 4. Resolution | Quorum | 67% of delegated weight agrees → winner confirmed |
Quorum Threshold
blockWeight * 100 >= totalWeight * 67Uses big.Int arithmetic. Deterministic tie-breaking: vote for lexicographically lowest hash.
Fallback Resolution
If 67% is unreachable (non-voting reps inflate total), a fallback triggers after 10 seconds when all actual voters agree unanimously.
Delegation
- Only XUSD balances contribute to voting weight
- Weight snapshots frozen at conflict detection time
- Persistent via DelegationStore interface
sync.RWMutexfor concurrency
Conflict Detection
- Max 10 block hashes per conflict
- Conflicting blocks placed in staging
- Conflict callback fires exactly once per conflict
Voting
- Per-conflict mutex prevents double-voting
- Vote buffering for votes arriving before local conflict detection (max 10 per conflict)
- ±5 minute timestamp window
- Vote wire format: 203 bytes (137 signing bytes + 2 length + 64 signature)
Quorum Manager
- Stale conflict sweep every 15 seconds
- Block status: Pending (0), Confirmed (1), Rejected (2)
- Block swap mechanism for staged winners