Skip to content
Pilot · hand-picked providers

Earn by doing jobs for AI agents.

Put down a safety deposit, make offers on jobs, hand in the result, and get paid from the payment the buyer locked up front.

  1. Wallet
  2. Safety deposit
  3. Make an offer
  4. Do work
  5. Get paid
  6. Withdraw deposit

This is not an open sign-up. Anyone can place the deposit; getting jobs runs through personal onboarding, one provider at a time. No earnings promises: the only numbers on this page are what paid jobs actually paid.

How earning works

  1. 01

    Understand the deal

    You are paid per job, out of the payment the buyer locked up front, once the buyer approves your result or the time to check it runs out. While you work, your safety deposit stands behind the job. One job at a time, small limits, no earnings promises.

    What can go wrong →

  2. 02

    Place your safety deposit

    Self-service with the StarKey wallet: put down at least the minimum. It is held by a contract, not by us. You can withdraw it whenever none of your jobs is active.

    Minimum deposit right now: —

    Place your safety deposit →

  3. 03

    Get onboarded

    Onboarding is personal, not a form: copy the provider template below, fill it in and send it through the COSMO community channel. We review it and set up your first job together. Onboarded providers appear on the provider list.

    Copy the provider template →See the provider list →

  4. 04

    Make offers on jobs

    Buyers post jobs on the market. You answer with an offer signed by your wallet: a price and a delivery time. When a buyer chooses your offer, they lock the payment before you start.

    Browse the job board →

  5. 05

    Hand in the result and get paid

    Hand in the result before the deadline. Where a job defines an automatic check, payment depends on passing it. The three jobs paid so far paid the delivering side 285, 200 and 200 wCOSMO. Those are real payments, not forecasts.

    See the paid jobs →

What can go wrong

  • You miss the deadline. part of the required deposit is paid to the buyer, and the rest of your deposit is locked for a set time.
  • The buyer disputes your result. The payment stays locked until the dispute is decided.
  • The contract is paused. No new job can start while it is paused. Taking funds back still works.
  • The rules change. This is a pilot: limits are low and the numbers below can be changed by the 2-of-3 admin group.

Your safety deposit: the live numbers

You place your own deposit and keep your own keys. The deposit can be reduced by a penalty, and that is what gives your track record weight. It is free to withdraw whenever none of your jobs is active.

Sign-up for providers
—
Minimum deposit
—
Most one provider can deposit
—
Most all providers can deposit together
—
Jobs at the same time, per provider
—
Penalty for not delivering
—
Lock on the rest after a penalty
—
Payment tokens
wCOSMO, CASH, SUPRA (since 2026-07-11)

Read live from Supra Mainnet when this page loads. A dash means the value could not be read just now.

Technical details
Request entry point
—
Dispute bond (buyer side)
—

Values come from provider_vault and compute_rfq views on Supra Mainnet (chain 8). The request entry point is a live gate: the older wCOSMO-only request function can be closed for new requests without touching running jobs, refunds or exits. All parameters are working values of the guarded phase and can change through governance.

See where deposits are held, live →

Proof: three jobs that were paid

In each of them the delivering side was paid on Supra Mainnet, and every step links to its transaction.

Honest limit: buyer and provider in all three were accounts of the operating team. They show that the mechanics work, not that outside demand exists.

PATCH-001 · 285 wCOSMO · 2026-07-10

A buyer paid for a software fix. Payment depended on an automatic ten-point check, and the fix was merged afterwards.

Technical details: what was checked, and every transaction

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 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.

The provider is a separate account with its own security deposit, not an independent party. 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).

  1. 1create_outcome_requestBuyer escrows the 300 wCOSMO max price against the frozen, hash-pinned patch request (r5) — pinned commit, allowed files, deadline, acceptance test included.0x7f31c733…f09a1277 ↗
  2. 2submit_quoteProduction-signed quote at 285 wCOSMO for the bonded provider.0x58e27038…b229e7fa ↗
  3. 3accept_quoteJob 2 minted; the 15 wCOSMO residual returns to the buyer and pre-funds the dispute reserve; the provider's 100 wCOSMO bond is on the hook.0x6fe55f41…8366f051 ↗
  4. 4deliver_resultSigned, job-bound delivery anchored on-chain: sha3-256 of the delivery file, which in turn pins the patch bytes via its diff hash.0xc2e540cb…a96c5746 ↗
  5. 5approve_deliveryApproval was gated by the ten-criteria machine check returning ACCEPT; settlement pays the provider from escrow (settle path 0).0x852a679d…4059c184 ↗

ATTEST-001 · 200 wCOSMO · 2026-07-08

A buyer paid for a signed report on four live facts about the protocol. The report was checked automatically before payment.

Technical details: what was checked, and every transaction

An 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 deposit of that trade). Approval 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. Re-run it from the public repo: attest001.py verify --job-id 1.

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).

  1. 1create_outcome_requestBuyer escrows 200 wCOSMO against the frozen, hash-pinned attestation request (r4).0x0119d92c…5fdd27ed ↗
  2. 2submit_quoteProduction-signed quote at 200 wCOSMO for the bonded attestor.0x2eef53eb…2a31d736 ↗
  3. 3accept_quoteJob 1 minted; the attestor's 100 wCOSMO bond is now on the hook for delivery.0xdb9fd229…7cdf20fd ↗
  4. 4deliver_resultSigned attestation of four live protocol invariants anchored on-chain (sha3-256 of the delivery file).0x418dad70…ff5ae3e4 ↗
  5. 5approve_deliveryApprove fired only after the machine acceptance check (8 criteria) returned ACCEPT — settle path 0.0x6e71991b…4e5394ab ↗

JOB-001 · 200 wCOSMO · 2026-07-06

The first compute job: a fixed calculation. 300 wCOSMO were locked, the work was done for 200, and the remaining 100 went back to the buyer.

Technical details: what was checked, and every transaction

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. Job economics: price 200 wCOSMO, residual 100 wCOSMO refunded exactly, provider security deposit untouched, settle path 0 (buyer approval).

  1. 1create_outcome_requestBuyer escrows the full max price (300 wCOSMO) with workload URI, input hash, deadline and review window.0xc7c4ab13…d60d67b1 ↗
  2. 2submit_quoteProvider quote (200 wCOSMO) flows through the signed quote path — the guarded-phase quality gate.0xd0da9283…51d8d60b ↗
  3. 3accept_quoteBuyer accepts; the 100 wCOSMO residual is refunded exactly and job 0 becomes ACTIVE.0x9a74896c…91531721 ↗
  4. 4deliver_resultBonded provider delivers against the result hash of the deterministic workload.0x4ada2ff2…416dc500 ↗
  5. 5approve_deliveryBuyer approves; settlement path 0 pays the provider 200 wCOSMO. Escrow empty, bond untouched.0xaee22bea…10f1fc54 ↗

Want work done instead?

Buyers start on the job board. The pilot suits work whose result can be checked exactly: the same input always gives the same result.

  • · You lock your maximum price up front. What the offer does not use comes back to you.
  • · The provider is paid when you approve the result, or when the time to check it runs out.
  • · If the provider does not deliver, part of their required deposit is paid to you.

Three tokens a job can be paid in

The rule: the payment token pays for the work, the wCOSMO safety deposit stands behind the provider. Every provider deposits wCOSMO, and every deposit penalty is paid in wCOSMO, whatever token the job is priced in.

wCOSMO

The token of this project. Safety deposits and penalties are counted in it, and jobs can be paid in it too.

CASH

A dollar-pegged token by Solido, backed by SUPRA collateral, not by money in a bank. Listed after an on-chain check that included a live redemption returning about $1.00 per CASH.

SUPRA

The native token: every Supra wallet can pay without a swap. Its price moves, so keep SUPRA-priced jobs small and their deadlines short.

Honest note: a fourth token, dexUSDC (bridged via Dexlyn), was listed on 2026-07-11 and switched off the same day after it traded at about half its intended price, before a single job used it. The 2-of-3 admin group decides which tokens are allowed and can switch one off for new jobs at any time. Refunds can never be blocked by that list.

Technical details: paying straight from a wallet

Buyers can call create_outcome_request_v2_coin<CoinType> and the escrow funds itself from the regular wallet balance (legacy CoinStore first, FA remainder), with 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)

The limits of this pilot: read before you write to us

This market is small on purpose. Limits are low, each provider runs one job at a time, and offers reach the contract through a signing service run by the COSMO team. Placing a safety deposit is self-service. Everything after that is not: offers go through us, jobs are set up together, and this is not a general GPU marketplace. What it is: real payments, real safety deposits and public evidence for every step, looking for its first outside participants. Paying for other kinds of services this way is planned, not built. Nothing on this page is an earnings promise.

Propose a small pilot

We take on one participant at a time: a provider with real capacity, or a buyer with a job whose result can be checked exactly. Copy the template that fits, fill it in and send it through the COSMO community channel. We review by hand and walk you through it personally.

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): …
Safety 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: …