Docs

Proof of Uptime

How XE proves provider uptime

#The Problem

In decentralised compute, a consumer pays a provider to run a workload. Neither party can be trusted:

  • The provider could claim to be running a VM while doing nothing -- pocketing rewards without delivering compute.
  • The consumer could claim the provider wasn't running, disputing legitimate charges.
  • Both could collude -- fabricating proof to extract network emissions without any real work happening.

Traditional cloud providers solve this with legal contracts and reputation. A decentralised network has neither. We need a cryptographic mechanism that makes dishonesty economically irrational.

#The Solution

Cryptographic heartbeat chains with merkle tree compression.

Every ~60 seconds, both provider and consumer participate in a dual-signed heartbeat. These heartbeats form a hash chain -- each one references the previous, making the sequence tamper-evident and forward-only. Heartbeats are then compressed into merkle trees, yielding a compact proof that can be stored on-chain for dispute resolution.

diagram
Heartbeat 0 ← Heartbeat 1 ← ... ← Heartbeat 59                    │                    ▼             Merkle Tree (epoch)                    │                    ▼            Epoch Root (32 bytes)                    │                    ▼         Claim Root → On-chain (~200 bytes)

24 hours of continuous uptime compresses from 718.9 KB of raw heartbeat data to ~200 bytes on-chain -- a 3,681x compression ratio.

#Research Path

Five proof-of-concept implementations explored increasingly sophisticated approaches:

PoCFocusKey Addition
PoC 1Linear hash chainDual-signed heartbeats chaining via SHA-256
PoC 2Merkle tree epochsHeartbeats grouped into epochs with merkle roots
PoC 3VDF hardeningVerifiable Delay Functions to prevent batch fabrication
PoC 4Production candidateThree-layer architecture combining all approaches
PoC 5Session modelHandling offline consumers and proof tiers

#Production Recommendation

Why no VDF? Because economics solves the collusion problem. In the XE network:

  • Providers stake collateral to accept leases.
  • Consumers pay XUSD for compute.
  • Providers earn XE emissions as reward.

For collusion to be profitable, the XE emission must exceed the XUSD lease cost. The network parameters are set so this never happens. A colluding pair loses money on every fake heartbeat. VDFs remain available as an optional hardening layer if the economic model ever needs reinforcement.

See Threat Analysis for the full red-team breakdown.

#How It Fits Together

diagram
┌─────────────────────────────────────────────┐│              Block Lattice                   ││  lease_accept ──▶ heartbeats ──▶ lease_settle│├─────────────────────────────────────────────┤│              Uptime Proof                    ││  Heartbeat Chain → Merkle Epochs → Claims   │├─────────────────────────────────────────────┤│              Settlement                      ││  Claim root submitted on lease_settle block  ││  Dispute: full merkle proof path provided    │└─────────────────────────────────────────────┘

The uptime proof system bridges the gap between lease acceptance and lease settlement. During the lease period, heartbeats accumulate. At settlement, the compressed proof is submitted on-chain. If anyone disputes, the full merkle proof path can be disclosed to prove or disprove any individual heartbeat.