Production Design

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, ~250 bytes each               ││  ~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

1type Claim struct {2    LeaseID       string   // lease block hash3    ClaimIndex    uint64   // monotonic claim counter4    StartEpoch    uint64   // first epoch index in this claim5    EndEpoch      uint64   // last epoch index in this claim6    MerkleRoot    []byte   // root of epoch-root merkle tree7    PrevClaimHash []byte   // SHA-256 of previous claim8    Timestamp     int64    // unix nanos9    ProviderSig   []byte   // provider signs the claim10    ConsumerSig   []byte   // consumer countersigns11    Hash          []byte   // SHA-256 of all fields12}

The claim root (~200 bytes including signatures and metadata) is submitted on-chain as part of lease settlement.

#Compression

#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.startEpoch <= 15 <= claim.endEpochStep 2: Provide merkle proof from epoch 15's root to claim root        epoch root + log2(24) sibling hashes ≈ 5 hashesStep 3: Provide merkle proof from heartbeat to epoch root        heartbeat + log2(60) sibling hashes ≈ 6 hashesStep 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:

#Design Decision: No VDF

#The Economic Argument

For provider-consumer collusion to be profitable:

XE emission from fake uptime > XUSD cost of the lease

Network parameters are set so this inequality never holds. The emission rate is calibrated below the lease cost, making collusion a net loss.

Additionally:

• Collateral enforcement. Providers stake collateral when accepting leases. Slashing on dispute makes ghost nodes unprofitable.
• Emission caps. Per-lease emission is bounded, preventing runaway extraction.
• Network monitoring. Sentinel nodes and fisherman protocols provide additional detection layers.

#When VDF Might Return

VDFs remain available as an optional hardening layer, activatable 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

#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

Emission rates scale with proof tier. Strong proofs earn full emission; weaker tiers earn proportionally less.

#Staged Rollout

The uptime system is designed for incremental deployment:

#Related Pages

• 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