00/ Abstract

AI compute is scarce, centralized clouds are expensive with long queues, and supply is deeply fragmented. We propose a decentralized compute coordination protocol that organizes globally distributed GPU resources into an on-demand AI compute network through on-chain matching, settlement, verification, and incentive mechanisms. The core problem the protocol addresses is: how to achieve supply-demand discovery, pricing, delivery, and payment for compute in a trustless environment.

01/ Market Context

The explosion of generative AI and autonomous agents has produced an exponentially growing GPU demand curve. Centralized clouds face bottlenecks including high prices, limited quotas, vendor lock-in, and geographic restrictions. Meanwhile, vast amounts of idle compute objectively exist -- off-peak capacity in data centers, surplus mining-farm hardware, and consumer-grade high-end GPUs -- but these resources remain difficult to trade due to the absence of trust infrastructure.

02/ Problem Definition

Why does this require a "protocol" rather than simply a website? Because decentralized compute trading faces four core challenges: supply-demand discovery and market-driven pricing, delivery and payment guarantees in a trustless environment, prevention of fraudulent behavior (fake hardware, degraded service), and the lack of a shared ledger for cross-organizational collaboration.

03/ Solution Overview

The protocol defines four participant roles: Demanders (AI teams), Providers (GPU holders), Validators (audit nodes), and Governance Participants. The core workflow is: Publish Demand -> Competitive Bidding -> Escrowed Execution -> Acceptance & Settlement. The control plane (coordination layer) is separated from the data plane (GPU compute traffic) -- high-volume data stays off-chain; only commitments and settlements are recorded on-chain.

// Protocol core workflow -- pseudocode
function protocol_loop(demand: Demand) {
    providers = match(demand, supply_pool)     // Match
    escrow    = lock_funds(demand.budget)       // Escrow
    task      = dispatch(demand, providers[0]) // Dispatch
    receipt   = await execute(task)             // Execute
    verify(receipt) ? settle(escrow) : dispute(escrow)
}

04/ Protocol Design

This is the core chapter of the whitepaper. The Resource Description Standard defines a unified schema for GPU model, VRAM, bandwidth, region, and other attributes. The Matching and Pricing mechanism supports auctions, pricing curves, and SLA tiering. Settlement and Escrow are handled by on-chain contracts with support for stablecoins and utility tokens. Verification and Dispute Resolution are implemented through heartbeat monitoring, benchmark testing, result hashing, and a challenge-period mechanism. A Penalty and Reputation System constrains malicious behavior.

Here $\mathcal{H}(p,d)$ is the hardware compatibility score (cosine similarity of a vector comprising GPU model, VRAM, and interconnect bandwidth), and $\mathcal{R}(p) \in [0,1]$ is the provider's on-chain reputation score. The protocol ranks candidate providers in descending order of $S$, and the highest-scoring provider is awarded the order.

When the network utilization rate $U(t)$ exceeds the target $U_{\text{target}}$, the price increases; when it falls below the target, the price reverts to the base rate. $\delta$ is the elasticity coefficient, and $(\cdot)^+$ denotes the positive-part operator. This mechanism ensures supply-demand equilibrium and efficient price discovery.

// Escrow contract -- Solidity
contract DASPEscrow {
    struct Order {
        address  demander;
        address  provider;
        uint256  amount;
        bytes32  specHash;
        uint64   deadline;
        Status   status;
    }

    function createOrder(bytes calldata specs, address provider)
        external payable returns (uint256 orderId)
    {
        orderId = nextId++;
        orders[orderId] = Order(
            msg.sender, provider, msg.value,
            keccak256(specs), uint64(block.timestamp) + ttl,
            Status.ACTIVE
        );
        emit OrderCreated(orderId, msg.sender, provider);
    }

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

    function dispute(uint256 orderId, bytes calldata evidence)
        external
    {
        require(msg.sender == orders[orderId].demander);
        require(block.timestamp < orders[orderId].deadline);
        orders[orderId].status = Status.DISPUTED;
        emit Disputed(orderId, evidence);
    }
}

05/ System Architecture

The control plane and data plane are separated. On-chain responsibilities include identity registration and reputation scoring, order escrow and settlement, critical state anchoring, and incentive distribution and governance voting. Off-chain responsibilities include actual GPU computation, container orchestration and scheduling (K8s / Ray), data transfer, and model delivery. The scheduling layer supports cluster, single-node, and containerized deployment modes.

The output of each computation stage $k$ is hashed to produce a commitment $C_k$. Multiple commitments are aggregated into a Merkle tree root and anchored on-chain. Validators can verify the output of any stage via a Merkle proof without replaying the entire computation.

# Provider node registration -- hardware description vector
provider = dasp.Provider(
    gpu_model="NVIDIA H100 80GB SXM",
    vram=81920,             # MB
    memory_bandwidth=3350,  # GB/s HBM3
    pcie="Gen5 x16",
    interconnect="NVLink 4.0",
    region="ap-east-1",
    tee="confidential-vm",
)
provider.register(stake=10000)  # DASP stake
provider.run_benchmark()          # On-chain benchmark verification

# Benchmark output
# ┌────────────────┬──────────┐
# │ FP16 TFLOPS    │  989.5   │
# │ FP32 TFLOPS    │  494.7   │
# │ Memory BW      │ 3352 GB/s│
# │ NVLink BW      │  900 GB/s│
# │ Score          │  0.973   │
# └────────────────┴──────────┘

06/ AI Workloads

The protocol is designed for a range of AI scenarios: Inference APIs (deploy model endpoints, billed per invocation), Fine-tuning Jobs (fine-tune pretrained models on specified datasets), Batch Training (large-scale distributed training jobs), and Agent Scenarios (rent compute per task, pay per usage). It supports mainstream frameworks including PyTorch, vLLM, Ray, and TensorFlow, and provides templates and prebuilt container images.

# Inference call
resp = dasp.infer(
    model="llama-3-70b",
    prompt="explain quantum computing",
    max_tokens=512,
    temperature=0.7,
)
print(resp.text)
print(f"tokens: {resp.usage.total_tokens}, cost: {resp.cost} USDC")

# Fine-tuning job
job = dasp.finetune(
    base="mistral-7b",
    dataset="s3://data/train.jsonl",
    gpu="H100", count=8,
    epochs=3,
    learning_rate=2e-5,
    lora_rank=16,
)
print(job.status)   # "running"
print(job.eta)      # "2h 34m"

# Distributed training -- 64 GPU FSDP
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,
        "gradient_checkpointing": true,
    },
    budget_cap="5000 USDC",
)
receipt = await job.submit()
print(receipt.tx_hash)  # 0x7f3a... on-chain receipt

07/ Economic Model

Token utility spans staking, payments, governance, and priority access. Supply-demand incentives combined with inflationary and deflationary mechanisms ensure long-term network sustainability. Protocol fees, token burns, and revenue sharing form a complete value loop. The economic model is designed so that providers are incentivized to join, demanders obtain prices lower than centralized clouds, and validators receive fair compensation.

When circulating supply $S_{\text{total}}$ exceeds the target $S_{\text{target}}$, the burn rate increases; when it falls below the target, the burn rate decreases. Logarithmic damping prevents excessive deflation.

Each epoch's reward $R_{\text{epoch}}$ is distributed to validator $v$ in proportion to its weight $w_v$. The weight factors in both the staked amount and the reputation score, incentivizing high-quality service.

08/ Security & Compliance

Data security is achieved through tenant isolation and independent containers. Malicious nodes are deterred through benchmark testing, heartbeat monitoring, and the reputation system. Sybil attacks are constrained through staking and identity mechanisms. Known limitations include: unsuitability for latency-critical real-time inference, inability to replace compute requiring specialized compliance certifications (government / financial sectors), and potential payment compliance challenges for cross-border compute transactions.

Here $p$ is the per-check hit probability, and $n$ is the number of check rounds. When $p = 0.05, n = 60$, the detection probability reaches $1 - 0.95^{60} \approx 95.4\%$. Continuous random spot checks make the cost of cheating far exceed the returns from honest participation.

# Heartbeat monitoring -- continuous verification of node liveness 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}:{timestamp()}"
        )
        await chain.submit_heartbeat(node.id, commitment)

        # Random spot check: validator requests re-execution of a reference task
        if random() < SPOT_CHECK_RATE:
            ref_result = await node.execute(REFERENCE_TASK)
            assert cosine_sim(ref_result, EXPECTED) > 0.99

        await asyncio.sleep(interval)

09/ Competitive Positioning

Differentiated comparison with Akash (open cloud marketplace), io.net (GPU aggregation platform), Gensyn (verifiable training), Render (rendering pivoting to generative), Nosana (on-demand GPU cloud), and Aethir (enterprise-grade GPU cloud). DASP's core differentiator is not "more GPUs" but rather the protocol layer -- we are building the rules, not the data centers.

10/ Roadmap & Governance

Phase 1 -- Core matching and settlement contracts, Provider registration and benchmarking, testnet launch. Phase 2 -- Inference services and training job support, reputation system and dispute resolution, mainnet launch. Phase 3 -- Private supply pools and enterprise SLAs, compliance certification and auditing, cross-chain interoperability. Governance is conducted through on-chain voting for parameter adjustments, treasury management, and protocol upgrades.

# Governance proposal -- adjust protocol fee rate
proposal = dasp.governance.propose(
    title="Adjust protocol fee: 2.5% → 2.0%",
    params={"protocol_fee": 0.02},
    discussion_period=7 * 86400,   # 7 days
    voting_period=3 * 86400,       # 3 days
    quorum=0.15,                   # 15% of staked supply
)
# proposal.id → "BIP-042"
# proposal.status → "discussion"

Voting weight uses the square root of the staked amount to mitigate whale concentration, with a logarithmic bonus for longer lock-up periods.

11/ Conclusion

We do not claim to build AGI; we provide a coordinable, settleable, and scalable compute network layer for the AI era. The protocol's goal is to enable AI teams to access the compute they need with less friction, GPU holders to earn transparent returns, and the entire ecosystem to evolve collectively under open rules.