Proof of Uptime

[!WARNING] Design stage — not implemented Proof of uptime is a design, not shipped behaviour. Nothing on these pages runs in an XE node today: the protocol implementation contains no heartbeat, epoch, or claim code, and no block type or block field carries an uptime proof. The constructions described here were explored as standalone prototypes in the separate xeprotocol/proof-of-uptime repository. Read them as a proposal that will change before it ships.

What is implemented for leases today is timekeeper attestation on lease_accept and lease_settle blocks, and the provider performance certificate. Neither proves continuous 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 Proposed Solution

Cryptographic heartbeat chains with merkle tree compression.

Every ~60 seconds, both provider and consumer would 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 small enough to store on-chain for dispute resolution.

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

In the PoC 4 prototype's 24-hour simulation, 718.9 KB of raw heartbeat data compresses to a ~200-byte on-chain claim -- a 3,681x ratio. That figure is a property of the prototype's demo run, not a measured protocol constant.

Research Path

Five proof-of-concept prototypes explored increasingly sophisticated approaches. All five are standalone Node.js demos in the xeprotocol/proof-of-uptime repository; none of them runs in an XE node.

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: hash chain + merkle epochs + chained claims, no VDF

PoC 5

PoC 4 plus VDF

The same three layers with PoC 3's VDF time-binding layered in

Proposed Starting Point

[!SUCCESS] PoC 4: Hash chain + merkle epochs, no VDF The research settled on PoC 4 as the first thing to build -- the three-layer architecture combining heartbeat chains, merkle epochs, and chained claims, with VDFs left out of the base protocol. PoC 5 (the same design plus VDF) is held in reserve for the case where emission rewards could exceed lease cost.

Why no VDF? Because economics is expected to carry the collusion problem. All three legs of that argument are already live in the protocol:

Providers stake collateral to accept leases -- ceil(cost / 5) in µXUSD, minimum 1 µXUSD. Implemented.
Consumers pay XUSD for compute, escrowed at lease creation. Implemented.
Providers earn XE emissions at settlement, from the R-curve. Implemented -- and the curve carries an explicit anti-collusion cap: R_effective is bounded above by R_collusion, a TWAP-derived ceiling that holds the USD value of the XE emitted for a lease below the XUSD the consumer paid for it.

What is missing is enforcement: a dispute and slashing path is not implemented. The consumer's escrow is burned at settlement and the provider's stake is returned; there is no on-chain mechanism today that adjudicates an uptime dispute or slashes a provider for one.

See Threat Analysis for the full red-team breakdown.

How It Would Fit Together

The diagram below is the proposed integration, not the current one. No block type carries a claim root today.

┌─────────────────────────────────────────────┐
│              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 is intended to bridge the gap between lease acceptance and lease settlement. During the lease period, heartbeats accumulate. At settlement, the compressed proof would be submitted on-chain. If anyone disputes, the full merkle proof path can be disclosed to prove or disprove any individual heartbeat.

Today the only time evidence a lease_settle block carries is its timekeeper attestations; there is no claim-root field on any block type, and no dispute arbitration to consume one.