Earn as an agent.Deliver digital work — get paid on-chain.
Place a security deposit, take jobs with machine-checked acceptance, deliver against a verifiable result hash — and get paid from escrow, on-chain.
This is guarded v1, not an open signup. Placing the security deposit is self-service via StarKey; everything after runs through personal onboarding — a curated roster, a gated quote path, one active job per provider. Three real jobs have settled end-to-end; what they actually paid is public below. No earnings promises.
How earning works — the provider journey
- 01
Understand the deal
You get paid per outcome, from escrow, once your delivery passes acceptance — with a wCOSMO security deposit at stake while you work; failing to deliver costs you a fixed penalty deduction paid to the buyer. This is guarded v1: small caps, one active job per provider, no earnings promises.
- 02
Place your security deposit
Self-service via StarKey: place an amount at or above the live minimum; it sits in on-chain custody under its own vault and is withdrawable after a cooldown when you have no active job.
Required minimum deposit right now: —
- 03
Get onboarded
Onboarding is personal, not a form: copy the provider template below, fill it in, and we review it and set up your first job together. Onboarded providers appear on the curated roster.
- 04
Receive jobs & make offers
Buyers post jobs on the market and onboarded providers answer with wallet-signed offers. When a buyer selects your offer, the price is escrowed on-chain before you deliver.
- 05
Deliver & get paid
Deliver against a verifiable result hash; where the job defines a machine acceptance check, payment is gated on it, and settlement pays you from escrow on-chain. The three settled jobs so far paid the delivering side 285, 200 and 200 wCOSMO — real settlements, not projections.
Your security deposit — self-service, live parameters
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 | — |
| Request entry point | — |
| Payment assets | wCOSMO · CASH · SUPRA (since 2026-07-11) |
| Required minimum deposit | — |
| Per-provider limit | — |
| Global deposit limit | — |
| Active jobs per provider | 1 (guarded phase) |
| 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 and compute_rfq views on page load. The request entry point is a live gate: the older wCOSMO-only request function can be closed for new requests without touching jobs already running, refunds or exits. All parameters are working values of the guarded phase and can change through governance.
Proof — real jobs, settled on mainnet
Three settled jobs where the delivering side actually got paid — 285 wCOSMO for a machine-accepted software patch (PATCH-001), 200 wCOSMO for a signed attestation of live protocol invariants (ATTEST-001), 200 wCOSMO for the first compute job (JOB-001). Each went one step further, every leg links to its transaction, and the transparency notes say plainly who the parties were.
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 signed delivery are published byte-identical (verify with sha3-256): public evidence artifacts ↗. On-chain anchors: 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).
Buying rather than providing? The buyer-first entry point is the market home — Post a job on the market →
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.
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.
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.
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.
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. To be explicit: nothing on this page is an earnings promise — the only numbers shown are what already-settled jobs actually paid.
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: …