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:

• A compute job is an object with a lifecycle (states, owner changes, version history) — not a row in a SQL table.
• Escrow is trivial: Move's linear types mean QALS inside an escrow object cannot be double-spent or leaked — the compiler enforces the accounting.
• Proofs are objects: attestations, benchmark scores, receipts (even NFTs) reference the job object by ID.
• Sponsored transactions (Qal Pass) mean a GPU rig or AI agent with zero QALS can still have its settlement txs paid for — the "feeless" IOTA promise, done safely.
• Finality is sub-second (Mysticeti/Starfish DAG-BFT): job state machines don't wait minutes for confirmation.

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)

• Match: marketplace matcher (off-chain bot or provider-pull model like Akash) calls match(job, provider) → escrow transfers from requester's Hold (pre-auth, see 04_credit_token_platform/).
• Settle: settle(job, actual_cost, attestation) releases min(actual, escrow) to provider, remainder back to requester. Metering comes from provider-signed telemetry cross-checked against wall-clock — no trusted oracle needed for v1.
• Slash: if telemetry contradicts reality (timeout, failed verification re-run), SLASHED refunds requester and burns/slashes provider stake (reputation backs quality).
• Receipt: settlement mints a ComputeReceipt NFT (per 08_nft_strategy/ — its recommended first NFT project): job ID, model+input hashes, GPU-seconds, cost, provider DID. This is the provenance backbone for AI outputs (§6).

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

• ComputeGift / ComputeVoucher objects: transferable objects redeemable for X GPU-hours at any provider — buy compute credits for someone else, gift them, or sell them on Qalx. Linear types prevent double redemption (one-time receive consumes the voucher).
• Futures (Phase 2): ComputeFuture { deliver_by_ms, gpu_hours, strike_doofs } — lock tomorrow's GPU capacity at today's price; useful because our own rigs are the counterparty, so it's capacity-planning, not gambling. Keep internally-priced; no public derivatives market (regulatory — see 06).
• Batch markets: a JobBundle object aggregates N small jobs (e.g. 10k inferences) into one escrow+settlement → amortises state-machine overhead for micro-jobs. This is how "per-inference billing" stays gas-cheap (one settle per bundle, sponsored by Qal Pass).
• Metered tokens as the unit: everything priced in doofs/GPU-second per accelerator class from the PriceTable; agents compare providers by price × benchmark-normalised-time without trusting anyone's marketing.

4. Trust machinery

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

• Burn-mint balance: a slice of settlement doofs is burned; compute rewards pool mints QALS to providers over 10y. As usage grows → burn grows → net supply falls even with rewards. (Render's model, simplified because we are the anchor tenant.)
• We are our own first customer: qalarc's apps (LLM proxy on the hub, any local-model serving on the 8060S, future video/render jobs) consume the fleet first → the marketplace never has a cold-start problem; external providers join a network with guaranteed demand.
• Real hardware, real costs: fleet today ≈ superlocal (96GB RAM + AMD 8060S 32GB), minirig GPUs, bb-mini. Pricing at residential electricity rates (~AU$0.30/kWh) still profitable for inference-sized jobs if priced against per-token API rates (typical API markup over raw compute is 5-20×). Spreadsheet of unit economics lives with the ops team; chain only records truth.
• SLA tiers: reputation-backed priority queue: higher-staked providers surface first; jobs can pin min_reputation.

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.