QALS Wiki · the qalarc network⌂ qalarc.com/projects/qals
generated 2026-09-22 · qalcode autonomous research

GPU-hours as tracked, escrowed objects · 07_compute_marketplace/COMPUTE_MARKETPLACE.md

Qal Compute — Transferring & Tracking Compute on a Tangle-Lineage Chain

Parent: 03_qals_architecture/QALS_ARCHITECTURE.md • Date: 2026-09-06 Answers: "Could this kind of tangle crypto coin be used to transfer and track compute and tokens as well?" → Yes. Compute becomes an escrowed, metered, provable, tradeable object.


1. Why the object model is uniquely good for compute

IOTA's original pitch was M2M (machine-to-machine) micro-payments for IoT. The 2026 IOTA/Sui object model finally delivers the data structures for it:

Precedent to borrow from: Akash (deployment leases + escrow), Golem (NTF task lifecycle), Render (burn-mint equilibrium), io.net (depin GPU pools) — all account-based chains; none have Move's resource safety or object-anchored provenance. We keep their tokenomics lessons (see §5) and drop their VM overhead.

2. The qal_compute Move package

/// Provider registers capability (DID-accredited via Hierarchies).
public struct Provider has key {
    id: UID,
    owner: address,
    accelerator: String,           // "amd-rdna3-8060s", "nvidia-rtx4090", "cpu-96gb"
    benchmark_score: u64,          // from Qal Bench oracle (§4)
    price_doofs_per_gpu_hour: u64,
    reputation: u128,              // staked + successful-jobs weighted
    active: bool,
}

/// The job lifecycle object — this is what "tracking compute" means.
public struct ComputeJob has key {
    id: UID,
    requester: address,            // user or AI agent (CreditAccount bound)
    provider: ID,                  // Provider object
    spec: String,                  // pointer: image, entrypoint, model hash, input DataAnchors
    state: u8,                     // POSTED→MATCHED→RUNNING→ATTESTED→SETTLED / SLASHED / REFUNDED
    escrow: Balance<QALS>,         // max cost locked at match
    actual_cost: u64,              // set at settlement
    attestation: Option<Attestation>,
    created_ms: u64, timeout_ms: u64,
}

public struct Attestation has store {
    provider_sig: vector<u8>,      // sig over (job_id, outputs_hash, gpu_seconds, watts?)
    outputs: DataAnchor,           // result artefacts anchored (hash+URI)
    telemetry: DataAnchor,         // signed metrics: gpu_s, vram_peak, energy
    optional_verifier_sig: vector<u8>, // second opinion (§4)
}

Lifecycle

POSTED ──(match: escrow locked)──► MATCHED ──(provider starts)──► RUNNING
   ▲                                                                   │
   │                                                            (finish: Attestation)
refund                                                           ATTESTED
(slash on                                                         │      │
 proven fault)                                              settle   dispute window
   ▲                                                            ▼      ▼
   └────────────────────────── REFUNDED ◄── SLASHED ◄──┤    SETTLED
                                              (provider slashed,     (escrow → provider pay +
                                               requester refunded)    doof-fee burned; receipt NFT minted)

3. Compute futures & tradeable compute (the "transfer" part)

4. Trust machinery

Mechanism What it does Cost
Qal Bench oracle fleet-submitted benchmark runs (e.g. MLPerf-lite subset, llama-token/s per accelerator class), medianised on-chain into benchmark_score tiny; runs weekly
Provider stake reputation stake slashed on proven fault economic security
Optimistic verification for high-value jobs: a second node re-runs on sampled inputs; mismatch → dispute 1.1× compute cost, optional
Attestation signatures provider DID signs telemetry + output hashes; verifier optionally countersigns ~free
Hierarchies accreditation devices must hold device.can-run-jobs accreditation to register as Provider — a compromised rig is revocable without touching code free
Anchoring every ATTESTED job's outputs anchor is checkpoint-anchored to public IOTA mainnet ~1 tx/checkpoint

5. Tokenomics of compute (lessons from Render/Akash/io.net)

6. AI-output provenance (why this matters beyond billing)

Every AI artefact qalarc ships can carry a receipt: {model_hash, input_anchors, gpu_job, provider, cost, DID of requesting agent} → either as a DataAnchor or the ComputeReceipt NFT itself. Downstream: endispute.com.au can prove "this report was produced by model X on Y date for client Z, unmodified since"; doof.ing can prove meme provenance (fun + serious); enterprise clients get C2PA-style lineage without trusting us — they verify the chain. Compute tracking = AI accountability. (Ties into Qal ID agent credentials — see 09_identity_ai/.)

7. Phases

  1. v0 (2 wks): qal_compute on qalnet-dev-1, single provider (superlocal), fake jobs, full lifecycle + receipts. Prove escrow/settle/slash paths in Move tests.
  2. v1 (+6 wks): real jobs via the hub (LLM inference metered per token; ollama-served GLM/Qwen on the 8060S is the natural first workload — it's already running there), ComputeReceipt NFTs, PriceTable-driven pricing, agent spend caps live.
  3. v2 (+3 mo): minirig + bb-mini as providers, vouchers tradeable, Qal Bench oracle, optimistic verification for big jobs, JobBundle batching.
  4. v3 (when public): open provider registration (stake + accreditation), futures for capacity, external GPU partners; bridged settlement against qAUD for fiat-paying clients.