Skip to content

Proof of 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.

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:

PoC Focus Key Addition
PoC 1 Linear hash chain Dual-signed heartbeats chaining via SHA-256
PoC 2 Merkle tree epochs Heartbeats grouped into epochs with merkle roots
PoC 3 VDF hardening Verifiable Delay Functions to prevent batch fabrication
PoC 4 Production candidate Three-layer architecture combining all approaches
PoC 5 Session model Handling offline consumers and proof tiers

Production Recommendation

PoC 4: Hash chain + merkle epochs, no VDF

The production recommendation is PoC 4 -- the three-layer architecture combining heartbeat chains, merkle epochs, and chained claims. VDFs are deliberately excluded from the base protocol.

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

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