Overview

A domain is an independent execution environment that connects to delta's validator-secured base layer through zero-knowledge proofs. Unlike traditional blockchains where all application logic runs onchain, domains execute offchain with full computational flexibility while proving correct execution to the base layer only when settlement is required.

Key distinction from ZK rollups: Rollups batch transactions and prove correct execution of the rollup's VM to a settlement layer. Domains are arbitrary applications (written in any language, using any stack) that prove application-specific rules (local laws) were followed when state changes need to be finalized onchain.

Example: Fitness Aggregator Domain

We'll walk through building a fitness aggregator that processes wearable sensor data, runs ML models, and settles challenge payouts trustlessly. This example demonstrates capabilities that are fundamentally impossible on traditional blockchains.

Application Requirements

The fitness app needs to:

• Ingest continuous streams from Oura, Garmin, Apple Watch APIs
• Process heart rate packets in real-time event loops
• Run ML models (VO₂ max estimation, overtraining detection)
• Trigger webhooks (Slack alerts, Google Fit sync)
• Maintain private state (ring buffers, workout history, leaderboards)
• Deploy code updates instantly
• Settle challenge payouts trustlessly when goals are met

Why Traditional Blockchains Can't Support This

Blockchains are guarantee machines which prevent invalid state transitions through validator consensus. They are not designed to create or transform state like general-purpose computers.

Specific blockers:

• No external data streams: Smart contracts can't subscribe to APIs; data must be batched through oracles
• No event-driven execution: State changes require signed transactions; contracts can't "listen and react"
• No side effects: Contracts can't call webhooks or external services
• Public state only: All data is readable by everyone; private health metrics are exposed
• Determinism requirements: ML models with randomness or large dependencies are prohibited
• Slow iteration: Contract upgrades require governance, audits, and migration complexity

Building this on a traditional blockchain means pushing most functionality to offchain services, creating a fragile architecture where application logic is scattered across incompatible systems.

Architecture as a delta Domain

The fitness aggregator runs as a domain with 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 generic domain as embedded software (Docker container or SDK integration)
• Handles delta operations (token transfers, proof generation, base layer submission) through the generic domain

2. Local laws (custom code)

• Application-specific rules written in Rust that govern state transitions
• Examples: "workout data must come from authenticated sources", "challenge criteria must be met before payout"
• Proven via zero-knowledge proofs when state is submitted to base layer
• Configured in domain.yaml and compiled into the domain's prover

Local Laws

Local laws are application-specific rules written in Rust that the domain proves were followed during state transitions. For the fitness aggregator:

// Example local law 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 laws are proven via zero-knowledge proofs when the domain submits state to the base layer. Validators verify the proof without re-executing the application logic or seeing private sensor data.

Technical Flow

Challenge Setup:

1. User creates challenge via fitness app
2. Domain locks prize pool funds in state

Real-time Processing: 3. Wearables stream data to fitness app continuously 4. Fitness app processes in event loops: ML inference, Slack alerts, leaderboard updates 5. All computation happens offchain; no interaction with delta

Challenge Completion: 6. Fitness app detects user completed challenge (5K in 23:45, goal was sub-25 min) 7. Domain validates local laws (zkTLS proof of authentic sensor data + challenge criteria met) 8. Domain generates ZK proof that local laws were satisfied 9. Domain submits proof + state update (release prize pool) to base layer 10. Base layer validators verify proof and finalize payout

What goes onchain: Proof of challenge completion + resulting state change (token transfer)

What stays offchain: Raw heart rate data, ML model parameters, workout history, intermediate calculations

Comparison Table

Capability	Traditional Blockchain	delta Domain
External API integration	Must use oracles (batched, stale)	Direct API calls in application
Event-driven execution	Requires transactions for every update	Native async/event loops
ML model execution	Impossible (size/determinism limits)	Full Python/NumPy stack
Private data	All state is public	Sensitive data stays in domain
Real-time processing	Delayed by block times	Instant computation offchain
Side effects	Impossible	Standard webhooks/API calls
Code deployment	Governance + audits + migration	Standard deployment (git push)
Verifiable settlement	Native	ZK proofs to base layer

When to Build a Domain

A domain is appropriate when your application requires:

1. Web-native integration: External APIs, webhooks, real-time data streams
2. Complex computation: ML models, large datasets, arbitrary business logic
3. Privacy: User data that shouldn't be public
4. Development velocity: Rapid iteration without blockchain upgrade constraints
5. Verifiable guarantees: Specific outcomes (payouts, rankings, access) need cryptographic proofs

If your application is purely about token transfers with simple validation rules, a traditional blockchain may suffice. If it needs to integrate with internet infrastructure or perform non-trivial computation, it requires a domain.

For implementation details, see the generic domain documentation and local laws guide.