Production Design

[!WARNING] Design stage — not implemented "Production design" here means the design proposed for production, not something running in production. PoC 4 is a standalone Node.js prototype in the xeprotocol/proof-of-uptime research repository. No layer of this architecture exists in an XE node, no block carries a claim root, and none of the rollout stages below has shipped. See the section overview for what is and is not implemented.

PoC 4 is the production candidate. It combines heartbeat chains and merkle epochs into a three-layer architecture that compresses 24 hours of uptime proof into ~200 bytes on-chain.

Architecture Overview

Layer 3: Chained Claims
┌─────────────────────────────────────────────┐
│  24 epoch roots → merkle tree → claim root  │
│  Claims chain via prevClaimHash             │
│  ~200 bytes on-chain per claim              │
└─────────────────────────┬───────────────────┘
                          │
Layer 2: Merkle Epochs    │
┌─────────────────────────┴───────────────────┐
│  60 heartbeats → merkle tree → epoch root   │
│  Epochs chain via prevEpochHash             │
│  32 bytes per epoch                         │
└─────────────────────────┬───────────────────┘
                          │
Layer 1: Heartbeat Chain  │
┌─────────────────────────┴───────────────────┐
│  H0 ← H1 ← ... ← H59 per epoch            │
│  Dual-signed, ~500 bytes each as JSON       │
│  ~60 second interval                        │
└─────────────────────────────────────────────┘

Layer 1: Heartbeat Chain

The foundation. Every ~60 seconds, provider and consumer produce a dual-signed heartbeat that chains to the previous via SHA-256.

H0 ← H1 ← H2 ← ... ← H59

Each heartbeat contains:

Lease ID, sequence number, timestamp
Previous heartbeat hash
Provider ed25519 signature
Consumer ed25519 countersignature
Final hash (chains everything)

See Heartbeat Chain for the full signing protocol.

Layer 2: Merkle Epochs

Every 60 heartbeats (~1 hour), heartbeats are grouped into an epoch. The epoch is a merkle tree of heartbeat hashes, yielding a single 32-byte root.

Heartbeats H0...H59 → Merkle Tree → Epoch Root (32 bytes)

Epochs chain via prevEpochHash:

E0 ← E1 ← E2 ← ... ← E23

See Merkle Epochs for tree construction and selective disclosure.

Layer 3: Chained Claims

Every 24 epochs (~1 day), epoch roots are grouped into a claim. The claim is another merkle tree -- this time of epoch roots -- yielding a single claim root.

Epoch Roots E0...E23 → Merkle Tree → Claim Root (32 bytes)

Claims chain via prevClaimHash:

C0 ← C1 ← C2 ← ... ← Cn

Claim Structure

The prototype's claim, as it would go on-chain; hashes and signatures are hex strings.

{
  claimNumber,      // monotonic claim counter
  firstEpoch,       // first epoch number in this claim
  lastEpoch,        // last epoch number in this claim
  totalHeartbeats,  // heartbeats covered
  periodStart,      // unix millis of the first heartbeat
  periodEnd,        // unix millis of the last heartbeat
  epochsRoot,       // merkle root over the epoch hashes
  prevClaimHash,    // previous claim's hash (64 zeros for the first)
  claimHash,        // SHA-256 over the lease ID and the fields above
  providerSig,      // provider signs the claim hash
}

The lease ID is not a field of the record but is part of the hashed payload, so a claim cannot be replayed against a different lease. Note also that the claim carries only the provider's signature — the dual-signature guarantee lives at the heartbeat layer, not the claim layer.

The claim (~200 bytes in a binary encoding, including the signature and metadata) would be submitted on-chain as part of lease settlement. No such field exists on lease_settle today.

Compression

Measured in the prototype's 24-hour demo run. These are demo figures, not protocol constants.

Metric

Value

Heartbeat interval

60 seconds

Heartbeats per day

1,440

Raw heartbeat data

718.9 KB

Epochs per day

Epoch root data

768 bytes

Claim root on-chain

~200 bytes

Compression ratio

3,681x

[!SUCCESS] 24 hours of uptime in 200 bytes A full day of continuous, dual-signed uptime proof compresses to roughly the size of a single tweet on-chain. The raw data is retained off-chain by both parties for dispute resolution.

Dispute Proof Path

If a dispute arises -- for example, the consumer claims the provider was down during hour 15 -- the full proof path can be disclosed:

Step 1: Locate the claim containing hour 15
        claim.firstEpoch <= 15 <= claim.lastEpoch

Step 2: Provide merkle proof from epoch 15's root to claim root
        epoch root + log2(24) sibling hashes ≈ 5 hashes

Step 3: Provide merkle proof from heartbeat to epoch root
        heartbeat + log2(60) sibling hashes ≈ 6 hashes

Step 4: Verify heartbeat signatures
        Check provider and consumer ed25519 signatures

Heartbeat → Epoch Root (merkle proof) → Claim Root (merkle proof) → Ledger

The total dispute proof for a single heartbeat is approximately:

Component

Size

Heartbeat data

~500 bytes (JSON)

Epoch merkle proof

6 x 32 = 192 bytes

Claim merkle proof

5 x 32 = 160 bytes

Total

~850 bytes

Design Decision: No VDF

[!INFO] Economics over cryptography PoC 4 deliberately omits Verifiable Delay Functions from the base protocol. The reasoning is that economics solves the collusion problem more effectively than computation.

The Economic Argument

For provider-consumer collusion to be profitable:

XE emission from fake uptime > XUSD cost of the lease

The emission curve is designed so this inequality does not hold. R_effective is capped by R_collusion, a TWAP-derived ceiling that keeps the USD value of the XE emitted for a lease below the XUSD the consumer paid — see compute economics.

The rest of the argument is not yet in place:

Collateral enforcement. Providers do stake collateral when accepting leases (ceil(cost / 5) µXUSD, minimum 1). But that stake is returned at settlement, and there is no slashing mechanism — no on-chain path adjudicates an uptime dispute or penalises a provider for one.
Emission caps. Per-lease emission is bounded on-chain, by R_collusion and by the Hermite payout cap.
Network monitoring. Sentinel nodes and fisherman protocols are Stage 2 and Stage 3 of the rollout below. Neither exists.

When VDF Might Return

VDFs are kept in reserve as an optional hardening layer. Enabling one would require shipping the construction first — no state-chain key toggles a VDF today — after which its parameters could be governed via state chain governance. Scenarios where VDF activation might be warranted:

Emission parameters change such that the economic argument weakens
A novel attack is discovered that bypasses economic disincentives
High-value leases require additional assurance beyond economics

Session Model

[!WARNING] Sketched, not specified The session model comes from the design notes, not from any prototype — PoC 5 is PoC 4 plus VDF, and implements no sessions. Nothing below has been built or pinned down; treat it as a direction, not a specification.

The Problem

The dual-signature requirement assumes both parties are online simultaneously. In practice, consumers may go offline -- for maintenance, network issues, or simply because the workload doesn't require active monitoring.

Proposed Solution

When the consumer is offline, the provider continues generating single-signed heartbeats. These are a weaker proof tier but still valuable -- they demonstrate the provider's signing key was active and producing heartbeats at the expected interval.

When the consumer comes back online, it reviews the single-signed heartbeats retroactively and can confirm or dispute them.

Proof Tiers

Tier

Signatures

Description

Strong

Provider + Consumer

Both parties signed in real-time

Medium

Provider, consumer confirmed later

Provider signed, consumer reviewed retroactively

Weak

Provider only, unchallenged

Provider signed, consumer never reviewed

Whether emission should scale with proof tier is an open question in the design notes — the alternative being a binary rule where a provider is paid unless a fault is filed. No weighting has been chosen, and the current emission curve has no notion of proof tiers.

Staged Rollout

The uptime system is designed for incremental deployment:

Stage

Name

Description

Heartbeat + Collateral

Basic dual-signed heartbeats with economic enforcement. Minimum viable uptime proof.

Sessions

Proof tiers for offline consumers. Retroactive confirmation.

Sentinel Nodes

Network-operated nodes that independently verify provider uptime.

Fisherman Protocol

Incentivised third-party verification. Anyone can challenge a provider and earn a bounty.

TEE

Trusted Execution Environment attestation where available. Hardware-backed proof.

Confidential VMs

Full confidential computing. Workload integrity verified by hardware.

[!NOTE] Current status No stage has shipped. Stage 0 exists only as prototype code in the xeprotocol/proof-of-uptime repository — collateral and escrow are live in the node, the heartbeat chain is not. Stages 1-5 are sketched in the design notes and nothing more. Each stage is intended to add defence-in-depth without requiring changes to earlier stages.

Heartbeat Chain -- Layer 1 signing protocol
Merkle Epochs -- Layer 2 compression
Threat Analysis -- attacks and mitigations
Compute Leasing -- the lease lifecycle
State Chain -- governance for parameter changes