Protocol Design

The core problem DASP Protocol solves is: how to discover, price, deliver, and settle compute resources in a trustless environment. What we are building is not a cloud platform, but an open set of coordination rules — enabling frictionless matching, execution, and settlement between globally distributed GPU supply and AI compute demand.

The protocol defines a unified resource description standard covering hardware attributes such as GPU model, VRAM, bandwidth, region, and trusted execution environment, allowing both supply and demand sides to communicate in a common language. It supports multiple pricing mechanisms including auctions, pricing curves, and SLA tiers, with market-driven pricing ensuring efficiency and fairness.

Funds are held in escrow by the protocol contract until delivery is complete, with support for stablecoin and utility token settlement. Verification mechanisms — heartbeat monitoring, benchmarks, result hashing, and challenge periods — ensure honest delivery by providers. Penalties and a reputation system deter malicious behavior.

Where \(\mathcal{H}(p,d)\) is the hardware compatibility score (GPU model, VRAM, bandwidth), \(\mathcal{R}(p)\) is the provider's on-chain reputation score, and the third term is the normalized price competitiveness. The weights \(\alpha, \beta, \gamma\) are adjusted through governance voting.

Core Workflow

// Escrow Contract — Core Settlement Logic
contract DASPEscrow {
    struct Order {
        address  demander;
        address  provider;
        uint256  amount;
        bytes32  specHash;
        uint64   deadline;
        Status   status;
    }

    // Create order, lock funds into contract
    function createOrder(bytes specs, address provider)
        external payable returns (uint256 orderId)
    {
        orders[orderId] = Order(
            msg.sender, provider, msg.value,
            keccak256(specs), block.timestamp + ttl,
            Status.ACTIVE
        );
        emit OrderCreated(orderId, msg.sender, provider);
    }

    // Auto-settle after verification passes
    function settle(uint256 orderId, bytes32 proofHash)
        external onlyValidator
    {
        Order storage o = orders[orderId];
        require(verify(proofHash, o.specHash), "proof invalid");
        uint256 fee = o.amount * protocolFee / 10000;
        transfer(o.provider, o.amount - fee);
        burn(fee * burnRate / 10000);
        o.status = Status.SETTLED;
    }
}

Participant Roles

Demanders — AI teams, developers, and enterprises. Submit training, inference, or fine-tuning jobs and access compute on demand. No need to build your own clusters or lock into a single cloud vendor.

Providers — Data centers, mining farms, and individual GPU owners. Contribute idle hardware to the supply network and earn transparent rewards with on-chain settlement.

Validators — Run audit nodes to verify delivery quality and hardware authenticity, maintaining network trustworthiness.

Governance Participants — Take part in on-chain governance to adjust protocol parameters, manage the treasury, and vote on protocol upgrades.

On-Chain / Off-Chain Division

The control plane (coordination layer) is separated from the data plane (actual training/inference traffic). High-volume data never goes on-chain — only commitments and settlements do. The chain handles identity registration and reputation scoring, order escrow and settlement, anchoring of key state (delivery receipts, verification results), and incentive distribution and governance voting.

Off-chain components handle the actual GPU computation (training, inference, fine-tuning), container orchestration and scheduling (K8s/Ray), and data transfer and model delivery. GPUs still do the real work on high-performance nodes — the chain solves cross-organization trustless collaboration.

For each computation stage \(k\), the output \(O_k\) is hashed and combined with the task ID and timestamp to produce an on-chain commitment \(C_k\). During the challenge period, anyone can submit the original data to dispute the result.

Reputation System

Provider reputation is updated using an Exponential Moving Average (EMA) model, adjusted after each delivery based on the verification outcome:

Where \(s_t \in [0, 1]\) is the delivery score for the current task (a weighted combination of benchmark results, SLA compliance rate, and dispute records), and \(\lambda\) is the smoothing coefficient. SLA violations trigger penalties:

AI Workloads

The protocol is designed for a variety of AI scenarios. Inference API: deploy model endpoints with per-call billing. Fine-Tuning Jobs: fine-tune pretrained models on specified datasets. Batch Training: submit large-scale training jobs with distributed computing support. Agent Workflows: rent compute per task and pay per usage, tailored for AI Agent pipelines.

# Inference call
resp = dasp.infer(
    model="llama-3-70b",
    prompt="explain quantum computing",
)

# Fine-tuning job
dasp.finetune(
    base="mistral-7b",
    dataset="s3://data/train.jsonl",
    gpu="H100", count=8,
)

# Provider registration
dasp provider register \
    --gpu A100 \
    --capacity 4 \
    --region ap-east

# Distributed training job
job = dasp.TrainJob(
    framework="pytorch",
    model="llama-3-70b",
    dataset="s3://corpus/pretrain-zh.parquet",
    config={
        "gpu": "H100",
        "nodes": 8,
        "gpus_per_node": 8,
        "strategy": "fsdp",
        "precision": "bf16",
        "batch_size": 2048,
        "max_steps": 50000,
    },
    budget_cap="5000 USDC",
)
receipt = await job.submit()
print(receipt.tx_hash)  # 0x7f3a... on-chain receipt

// Settlement receipt — verifiable on-chain
{
  "task_id": "dasp_7f3a9c2e",
  "status": "completed",
  "provider": "0x8B3f...a91D",
  "gpu": "H100-80GB x8",
  "duration_sec": 14420,
  "cost": { "amount": "847.30", "token": "USDC" },
  "receipt": {
    "tx_hash": "0xd41c...8f27",
    "output_hash": "sha256:a9f3c2...",
    "benchmark_score": 98.7,
    "sla_met": true
  }
}

Supported frameworks: PyTorch, vLLM, Ray, TensorFlow, and other major toolchains.

Security & Compliance

Data Security — Tenant isolation ensures workloads run in independent containers with no cross-tenant data leakage. The protocol layer only handles scheduling and settlement metadata — it never touches training data or model weights.

Malicious Activity Prevention — Benchmarks verify hardware authenticity, heartbeat monitoring detects downtime, and the reputation system weeds out bad actors. Sybil attacks are mitigated through staking and identity mechanisms.

# Heartbeat monitoring — continuously verifies node uptime and hardware authenticity
async def heartbeat_loop(node: Node, interval: int = 30):
    while node.active:
        proof = generate_benchmark(gpu_id=node.gpu)
        commitment = sha256(
            f"{node.id}:{proof.hash}:{time.now()}"
        )
        await chain.submit_heartbeat(node.id, commitment)
        await asyncio.sleep(interval)

Known Limitations — The protocol is not suited for real-time inference scenarios with extreme latency sensitivity, nor does it replace government or financial compute needs that require specialized compliance certifications.

FAQ

How is DASP different from cloud providers like AWS or GCP? Cloud providers are centralized suppliers. DASP is an open supply-demand coordination protocol. Multiple providers compete on pricing, so users are never locked into a single vendor.

Is the blockchain just a gimmick? No. The chain solves cross-organization trustless collaboration: identity, settlement, and dispute resolution. The computation itself does not happen on-chain — GPUs still do the real work on high-performance nodes.

Is my data safe? Workloads run in isolated containers. The protocol layer only handles scheduling and settlement metadata — it never touches training data or model weights.

What stage is the protocol at? Development stage. The core protocol design is complete, and we are building the MVP and testnet.