Real-world data as a settlement input

Traditional blockchains can't subscribe to APIs, run ML inference, or process continuous event streams. Any app that needs real-world data has to push that logic offchain, which defeats the purpose of onchain settlement. delta domains run as ordinary web services (with full access to external APIs, async event loops, and any compute stack) and only touch the settlement layer when a state change needs to be finalized. On delta, real-world data becomes a valid input to settlement without ever being exposed onchain.

Example: Fitness Aggregator

A fitness app that aggregates wearable sensor data, runs ML models, and pays out challenge rewards without trusting a centralized server to decide who won.

Overview

Users join fitness challenges with token prize pools. The app ingests live data from Oura, Garmin, and Apple Watch, tracks workout progress in real time, and releases the prize pool when a user completes the challenge criteria. A cryptographic proof confirms that the data was authentic and the rules were followed.

Requirements

The fitness app needs to:

• Ingest continuous streams from Oura, Garmin, and Apple Watch APIs
• Run ML models for VO₂ max estimation and overtraining detection
• Maintain private state (workout history, leaderboards)
• Settle challenge payouts trustlessly when goals are met
• Keep raw health data off the settlement layer

delta Architecture

The domain has two components:

1. Fitness application (custom code)

• Standard web service in any language (Python, Node.js, etc.)
• Processes sensor streams, runs ML models, manages private databases
• Runs the delta gateway as embedded software (Docker container or SDK integration)
• Handles delta operations (token transfers, proof generation, submission to settlement layer) through the delta gateway

2. Guardrails (custom code)

• Application-specific rules written in Rust that define what must be true before a payout is authorized
• Rules are proven via zero-knowledge proofs managed by the delta gateway when submitting state updates
• Validators on the delta settlement layer verify the proof without re-executing application logic or seeing underlying health data

Guardrails

Two conditions must be proven when a challenge completion is submitted:

1. Data authenticity — sensor data is verified against a zkTLS proof that it came from the named provider's API, not a fabricated input
2. Challenge criteria — the parsed workout meets the target (e.g. distance ≥ 5km, time ≤ 25 min)

// Example guardrail structure (simplified)
// Proves: "workout data is authentic AND meets challenge criteria"

fn validate_challenge_completion(
    sensor_data: SensorData,
    zktls_proof: zkTLSProof,
    challenge: Challenge,
) -> Result {
    // Verify sensor data came from authenticated source
    verify_zktls_proof(sensor_data, zktls_proof)?;
    
    // Verify workout metrics meet challenge requirements
    let workout = parse_workout(sensor_data);
    ensure!(workout.distance >= challenge.target_distance);
    ensure!(workout.time <= challenge.target_time);
    
    Ok(true)
}

These criteria are proven via zero-knowledge proofs when the domain submits state to the settlement layer. Settlement is blocked unless both conditions hold.

Technical Flow

Setup: User creates a challenge; the domain locks the prize pool in state.

Real-time processing: Wearables stream data to the fitness app. The app runs ML inference, updates leaderboards, and fires webhooks.

Completion:

1. App detects the user has met the challenge criteria
2. Domain (via the gateway) generates a ZK proof that guardrails were satisfied
3. Gateway submits the proof and state update (prize pool release) to the settlement layer
4. Validators verify the proof and finalize the payout