Outcome settlementfor compute and verifiable work
A buyer escrows payment. A provider with a security deposit at stake delivers against a verifiable result hash. Settlement happens on-chain — or not at all.
This is not a marketplace pitch. It is a small, deliberately guarded outcome-RFQ market, live on Supra Mainnet, with three real jobs settled end-to-end — most recently a machine-accepted software patch. It is not permissionless and not self-service: one active job per provider, deterministic workloads, a gated quote path — and personal onboarding for every participant.
Markets move assets
Liquidity, trading and routing are market rails — on Supra, that is SupraFX's domain. COSMO does not compete there.
COSMO settles work
A job is requested, paid into escrow, delivered against a verifiable result and settled on-chain — with a provider who has something at stake.
One layer down
Complementary to SupraOS and SupraFX, not a competitor: COSMO is the execution and accountability primitive underneath agent workflows.
How a job settles
Request
A buyer creates an outcome request: workload URI, input hash, max price, deadline, review window. The full max price is escrowed on-chain.
Quote
A provider with a security deposit at stake quotes a price. Quotes flow through a signed quote path — the quality gate of the guarded phase.
Accept
The buyer accepts a quote. Any residual between max price and quoted price is refunded exactly; the job becomes active.
Deliver
The provider runs the workload and delivers against a verifiable result hash. v1 targets deterministic, re-computable workloads.
Approve
The buyer verifies and approves within the review window. Timeout and dispute paths exist so neither side can strand the other.
Settle
Settlement pays the provider from escrow, on-chain. The outcome is a receipt that feeds the provider’s track record.
Pay in the asset that fits
Since 2026-07-11 the market accepts three payment assets. The rule is simple: payment assets pay for the work — the wCOSMO security deposit guarantees provider behavior. Every provider still places a wCOSMO security deposit, and every penalty deduction is compensated in wCOSMO, no matter which asset a job is priced in.
wCOSMO
The community and security asset. Provider security deposits and penalty compensation are denominated here — and jobs can be paid in it too.
CASH
Solido CDP stablecoin, backed by SUPRA collateral — not fiat-backed. Listed after an on-chain due diligence including a live redemption test that returned ~$1.00 per CASH.
SUPRA
The native asset — every Supra wallet can pay without swaps or bridges. It is volatile, so keep SUPRA-priced jobs small and their deadlines short.
Pay straight from your wallet
Buyers call create_outcome_request_v2_coin<CoinType> and the escrow funds itself from the regular wallet balance (legacy CoinStore first, FA remainder) — no manual migration step. Keep a small gas headroom free on top of the escrowed amount: transaction validation reserves max_gas × gas price upfront.
Both rails are proven with settled mainnet jobs (payment-rail proofs with deterministic constant workloads — no external work product claimed): CASH job settled (0.30 CASH) · SUPRA job settled (19 SUPRA)
Honesty note: a fourth asset, dexUSDC (bridged via Dexlyn), was listed on 2026-07-11 and disabled the same day after a ~50% market depeg was observed — before a single job used it. Payment assets are governed by a 2-of-3 multisig allowlist and can be disabled for new requests at any time; refunds are never blockable by the allowlist.
Proof — real jobs, settled on mainnet
Three settled jobs, each one step further: JOB-001 proved the settlement machinery, ATTEST-001 traded a verified statement, PATCH-001 traded a directly usable work product.
PATCH-001 — a machine-accepted software patch
On 2026-07-10, a buyer paid 285 wCOSMO for a software patch fixing a real, pre-existing defect — an address-canonicalization bug in the maker daemon's access gate — against a commit frozen in the request. The acceptance test itself travels inside the hash-pinned request, so the provider cannot soften it. Payment was gated by a ten-criteria machine check in a clean clone of the pinned commit: signature against the key frozen in the request, binding to job and request, deadline, the patch applies cleanly, the frozen test fails before and passes after, full suite and typecheck green, only the two allowed files changed, no forbidden changes, and the hash chain from patch bytes through the signed delivery to the on-chain result hash. Only after ACCEPT did the buyer approve — and the paid patch was then actually merged.
Transparency: buyer and provider are operating-team accounts; the provider is a separate account with its own security deposit, not an independent party. What is real either way: the defect, the deposit at stake, the fixed deadline, and the machine-checkable acceptance. Request, patch and signed delivery are published byte-identical (verify with sha3-256): public evidence artifacts ↗. On-chain anchors: input hash 20eef0578a…a06395e5 (frozen request), result hash 7a5847bb18…077afdb3 (signed delivery, pinning the patch bytes).
ATTEST-001 — the first traded good
On 2026-07-08, a buyer paid 200 wCOSMO for an independent, ed25519-signed attestation of four live protocol invariants (wCOSMO peg backing, provider security deposit above minimum, every admin equal to the 2-of-3 multisig, the request-fee floor) — delivered by an attestor with a 100 wCOSMO security deposit at stake (the historical deposit of that trade). Approval was not a click: it was gated by a machine acceptance check with eight criteria — signature against the key frozen in the request, deadline, schema binding to request and job id, freshness (4 seconds used of a 300-second budget), raw evidence per check, live reproducibility, verdict logic, and the on-chain hash anchor. Anyone can re-run the acceptance from the public repo: attest001.py verify --job-id 1.
Transparency: buyer and attestor are operating-team accounts. What is real either way: the attested on-chain state itself, the deposit at stake, and the machine-checkable acceptance — all independently verifiable. Request and delivery are pinned on-chain: input hash 7516be60f3…86b2b6ee (frozen request), result hash 665404a859…7caec205 (signed delivery file).
JOB-001 — the technical foundation
On 2026-07-06, the first real compute job settled on Supra Mainnet: a deterministic workload (a 1,000,000-step SHA3 chain), requested with 300 wCOSMO escrowed, quoted and delivered at 200 wCOSMO against an on-chain result hash, approved by the buyer and settled directly to the provider. Input and result hashes are on-chain and re-computable from the published workload spec.
Transparency: buyer and provider in this first job belong to the operating team — it proves the machinery end-to-end, not external demand. That is exactly the gap the pilot program below is meant to close. Job economics: price 200 wCOSMO, residual 100 wCOSMO refunded exactly, provider security deposit untouched, settle path 0 (buyer approval).
Provide compute
Providers place their own security deposit and run their own keys. The deposit is subject to penalty deductions — that is what makes the on-chain track record credible. Placing the deposit is self-service via StarKey; the quote path stays gated during the guarded phase, so your first job is set up together.
| Provider onboarding | — |
| Payment assets (V2) | wCOSMO · CASH · SUPRA (since 2026-07-11) |
| Required minimum deposit | — |
| Per-provider limit | — |
| Global deposit limit | — |
| Active jobs per provider | 1 (guarded v1) |
| No-delivery penalty | 10% of the required deposit, paid to the buyer (fixed at accept) |
| Dispute deposit | 500 bps of job price (buyer-side) |
Values are read live from Supra Mainnet (chain 8) provider_vault views on page load. All parameters are v1 working values and can change through governance.
Bring a workload
v1 targets workloads whose results can be verified deterministically — batch inference with fixed seeds, hashing and data pipelines, rendering with reproducible outputs, anything where the same input yields the same checkable result.
- · you escrow the max price up front; the residual is refunded exactly on accept
- · payment moves only on your approval — or through defined timeout paths
- · if a provider fails to deliver, a penalty deduction of 10% of their required deposit is paid to you (fixed at accept)
- · a dispute path with its own deposit keeps both sides honest
For a first pilot we help scope the workload, hand-hold the wCOSMO and gas setup, and walk the job through together.
Guarded v1 — read this before reaching out
This market is intentionally small. Caps are low, each provider can run one active job at a time, and quotes flow through a signed quote path operated by the COSMO team. Placing a provider security deposit is self-service (/compute/bond) — everything after that is not: quoting is gated, jobs are set up together, and it is not a general GPU marketplace. What it is: a live settlement primitive with real money, real security deposits and public evidence for every step — looking for its first external participants. The broader class of service settlement remains roadmap.
Propose a small guarded compute pilot
We onboard one participant at a time — a provider with real capacity, or a buyer with a scoped, verifiable workload. Copy the template that fits, fill it in, and send it via the COSMO community channel. Review and onboarding are manual; expect a personal walkthrough, not a signup flow.
COSMO Compute — scoped pilot proposal (provider) Wallet (Supra, chain 8): 0x… Capacity I can offer (hardware / runtime / availability): … Deterministic workload classes I can run (e.g. batch inference, hashing, data pipelines): … Provider security deposit: already placed via /compute/bond? yes/no Background (infra / DePIN / agents): …
COSMO Compute — scoped pilot proposal (workload) Wallet (Supra, chain 8): 0x… Workload (what should run, expected output): … Is the result deterministically verifiable (same input → same output)? yes/no/unsure Rough budget in wCOSMO and desired timeline: … Contact: …