Skip to content

THE PROVEN GUIDE

The check comes
before the payment.

Proven handles work with executable acceptance conditions. This guide explains the path from those conditions to a recorded delivery result, and what remains trusted along the way.

How a job moves

  1. Commit the job. Fix the worker, payment, acceptance check, planted fakes and verifier build before funding. Hashes bind the job to these inputs.
  2. Challenge the check. Run it against the planted wrong deliverables. A check that accepts one of those fakes is refused. Catching the planted fakes does not prove that every possible wrong delivery will be caught.
  3. Fund escrow. The buyer locks the agreed payment in the NEAR contract after the challenge is accepted.
  4. Deliver the work. The worker commits the delivery hash. Changed bytes do not match that commitment.
  5. Request verification. Anyone may trigger the escrow’s OutLayer request with the required compute deposit. Only the escrow’s private promise callback records its verdict.
  6. Settle and inspect. A recorded pass permits release; a recorded fail permits refund. Inspect the final contract state and transfer receipt to establish that payment actually happened.

A failed run is not a failed delivery.

A promise failure, timeout, malformed result, oversized output or mismatched binding produces no verdict. It must not become a pass or fail. The job can be retried within its window and then reach its expiry/refund path.

A pending payout is also different from a confirmed transfer. The app labels the recorded contract state and shows what is still pending.

What remains trusted

What an attestation panel means

“Bindings matched” means the fetched fields match the stored job, verifier, input, output and secret-reference commitments. The page does not independently check the Intel signature chain or worker-measurement approval.

Selected recorded runs have passed independent command-line signature checks, documented in the project README. That does not independently establish the private plaintext or reproducible builds.

Start with two completed jobs

The recorded November 6 testnet pair used the same check. Job 35 released exactly 0.01 NEAR to the honest worker. Job 36 refunded exactly 0.01 NEAR to the buyer after the fake delivery failed. The check had caught 13 of 13 planted fakes before funding.

These are existing jobs, read live. Opening them sends no transaction and does not start a new demo.

Inspect honest job 35 Inspect fake job 36

The guarded live demo

The live control is separate from job lookups. It starts disabled unless the operator prepares one fixed run. That run uses the operator’s testnet funds and the existing restricted buyer and scoped workers; the visitor cannot choose payment amounts, recipients or inputs.

A durable allowance is consumed before launch. Repeat clicks, another server process or a restart cannot use it again. An uncertain result requires operator reconciliation; there is no automatic retry or browser reset.

One earlier fresh command completed in 117.87 seconds. That is a measured run, not a guarantee of future network timing. The browser’s elapsed display is a progress timer.

Open the demo controls

Where Proven stops

Subjective work is outside this flow. Proven does not decide whether an essay is good, settle a dispute by opinion, or establish correctness beyond the committed check.

Market currently runs on testnet. The recorded examples on this page are scripted testnet jobs. A separate unaudited, owner-funded mainnet escrow has paid a real model delivery and refunded a scripted fake; there is no mainnet market board. Cross-chain payouts are not implemented. The relay operator can read private inputs; this page does not independently verify their handling.