Chio/Docs

Run Verifiable Work

Buy an authentication inventory from your partner, have a verifier you both pinned check it, and pay only after the check passes.

Guide chio@5f63e6e

On this page

Buy a checked analysis from another company and pay for it only when a verifier you both chose has rerun the checker on the exact bytes. The work is an inventory of the authentication each operation in the pricing service’s OpenAPI document declares, priced at USD 28.00, and every step below prints what your owner work service recorded.

Continues from Quickstart part 3 · uses the partner card and the pricing service’s openapi.json.

Start

1. Start your owner work service

Initialize a private state directory from a host profile that names your kernel, the rail you accept, the verifier you pin, and your partner. Then serve it in its own terminal.

Before you begin

You need the partner card from Quickstart part 3, a copy of the pricing service’s OpenAPI document saved as openapi.json from https://127.0.0.1:9440/pricing/v1/openapi.json, and a funded wallet on the rail your host profile names. Your partner runs its own owner work service and sends its signed offer as partner-offer.json.

Terminalbash
chio work init --config work-host.toml --state ./work
Output
state        ./work  private, mode 0700
owner        did:chio:z6Mkf3…Qp9  kernel 4f1c…a2e9
rail         work-claim-escrow  chainId 8453, escrow 0x3b9e…a71c
verifier     verify.corbel.example  pinned 0x9f62…3ad5
peer         partner  did:chio:z6MkpA7…c2T, kernel 9b07…d31c
Terminal · keep runningbash
chio work serve --state ./work
Output
serving      owner work service from ./work, chio.work.v1
socket       ./work/work.sock
authority    activated for kernel 4f1c…a2e9

You should see your kernel and one pinned verifier. A network caller cannot run init; it reads only your local profile, and serving requires your kernel’s activated authority.

2. Select your partner’s offer

Select the offer. Your owner service signs the selection, your partner’s kernel seals a dispatch permit for one slot, and you get a draft commitment with no funding attached.

buy-auth.tsbuy_auth.pysrc/main.rs · in main
import { readFileSync, writeFileSync } from "node:fs";
import { WorkClient } from "@chio-protocol/process";

const work = await WorkClient.open("./work");
const offer = JSON.parse(readFileSync("partner-offer.json", "utf8"));
const draft = await work.select(offer, {
  programId: "pricing-openapi-auth",
  commandId: "auth-select-1",
});
writeFileSync("auth-draft.json", JSON.stringify(draft.commitment, null, 2));
console.log(draft.describe());
Output
offer        openapi-explicit-auth-v1 from did:chio:z6MkpA7…c2T, USD 28.00
selection    signed by did:chio:z6Mkf3…Qp9 at revision 2
permit       sealed by kernel 9b07…d31c for slot auth-inventory
draft        WorkCommitmentV1 written to auth-draft.json, no funding yet

You should see the permit sealed by kernel 9b07…d31c. The offer is only an input: your partner’s kernel checked the current policy and profile generation when it prepared the offer, and it checks them again at admission.

3. Sign the agreement

Write the terms: the checker, the verifier, the price, the four deadlines, and the custody policy. Choose the checker now; once a result exists, neither side can swap it.

terms/openapi-auth.jsonjson
{
  "workId": "pricing-openapi-auth",
  "provider": "partner",
  "verifier": "verify.corbel.example",
  "checker": "openapi-explicit-auth-v1",
  "assurance": "artifact-only-v1",
  "input": "openapi.json",
  "amount": "USD 28.00",
  "deadlines": {
    "submitBy": "2026-10-14T18:00Z",
    "challengeUntil": "2026-10-15T18:00Z",
    "resolveBy": "2026-10-16T18:00Z",
    "refundAfter": "2026-10-17T18:00Z"
  },
  "custody": { "policy": "local-retain-indefinitely-v1" }
}
buy-auth.tsbuy_auth.pysrc/main.rs · in mainTerminal
const prepared = await work.prepare({
  schema: "chio.work.preparation.v1",
  program_id: "pricing-openapi-auth",
  command_id: "auth-agree-1",
  proposal: {
    Agreement: {
      commitment: draft.commitment,
      funding_profile_id: "work-claim-escrow",
      terms_reference: "terms/openapi-auth.json",
    },
  },
});
console.log(prepared.describe());
Output
preparation  auth-agree-1  Prepared
agreement    7e1d…c04a  SHA-256 of the RFC 8785 body
buyer        did:chio:z6Mkf3…Qp9  signed
provider     did:chio:z6MkpA7…c2T  signed through kernel.halden.example/cosign
verifier     verify.corbel.example  pinned 0x9f62…3ad5
checker      openapi-explicit-auth-v1  c7a1…02be
amount       USD 28.00 to 0x7d0c…12f4
deadlines    submitBy 2026-10-14T18:00Z  challengeUntil 2026-10-15T18:00Z
             resolveBy 2026-10-16T18:00Z  refundAfter 2026-10-17T18:00Z

You should see both signatures over one agreement digest, 7e1d…c04a, and deadlines in strict order. Your service canonicalized the terms with RFC 8785, hashed the body, and collected your partner’s signature over the identical bytes. From the command line, auth-agree-1.json holds the same preparation document. Work Agreements and Funding lists every field the body binds.

4. Fund the allocation

Lock the USD 28.00 in the escrow. The funding call moves exactly that amount and returns an allocation id derived from the chain, the escrow, and the complete terms.

Terminalbash
chio work fund --state ./work auth-agree-1
Output
allocation   0x8c1f…40d2  keccak256(chainId 8453, escrow 0x3b9e…a71c, terms)
state        Funded  USD 28.00 moved from 0x41a3…9be0 to the escrow
token        USDC 0x8335…2913, amount 28000000
reserve      work-claim-escrow  agreement 7e1d…c04a
commitment   auth-commitment.json  funding reference attached

You should see the claim Funded and a funding reference attached to auth-commitment.json. Running the command again returns the same allocation; the escrow funds an agreement digest once per payer.

5. Submit the work

Submit the funded commitment. Your partner’s kernel reads the allocation on the rail, admits the request under its own policy, and runs the work.

buy-auth.tsbuy_auth.pysrc/main.rs · in mainTerminal
const commitment = JSON.parse(readFileSync("auth-commitment.json", "utf8"));
const submitted = await work.submit({
  schema: "chio.work.command.v1",
  program_id: "pricing-openapi-auth",
  command_id: "auth-submit-1",
  action: { Submit: { commitment } },
});
console.log(submitted.describe());
console.log((await work.inspect(submitted.handle)).describe());
Output
command     auth-submit-1  Applied at revision 4
admitted    by kernel 9b07…d31c under its own policy

handle      pricing-openapi-auth/auth-inventory, request req-01c4…7a90
execution   Available      returned, rcpt-01c4…7a92 signed by kernel 9b07…d31c
acceptance  Pending        verify.corbel.example, recordable after 2026-10-15T18:00Z
results     Available      output 6f0e…b31a, 3 operations
recovery    NotApplicable
settlement  Pending        Submitted, commitment 0x2a90…f1e3
delivery    Available      co-signed by kernels 4f1c…a2e9 and 9b07…d31c

You should see execution and delivery available and acceptance pending. The provider has committed to one output, 6f0e…b31a, and the verifier cannot record a decision until the challenge window closes at 18:00 on October 15.

6. Read the verifier’s decision

After the challenge window, inspect the work again with its costs. The verifier has retrieved the retained input and output, rerun the checker, and recorded its signed decision on the rail.

Terminalbash
chio work inspect --state ./work auth-submit-1 --costs
Output
acceptance  Available      Accepted, predicate match, checker c7a1…02be
                           decision 0x51bc…0d78 recorded 2026-10-15T18:04Z
settlement  Available      Payable USD 28.00, allocation 0x8c1f…40d2
costs       production     USD 0.46   model USD 0.41, tools and compute USD 0.05
            verification   USD 0.03   checker rerun 17 ms, custody reads
            ratio          0.07       verification over production

You should see Accepted with predicate match, the claim Payable, and a ratio of 0.07. Buying checked work pays off when checking costs a small fraction of producing: aim for a median ratio at or under 0.10 across your purchases, and at most 0.25 at the 90th percentile.

7. Collect the payment and verify the evidence

Collect the work. Collecting reconciles the records your service owns and never dispatches the work again.

buy-auth.tsbuy_auth.pysrc/main.rs · in mainTerminal
const view = await work.collect(submitted.handle);
console.log(view.describe());
Output
handle      pricing-openapi-auth/auth-inventory, request req-01c4…7a90
execution   Available      returned, rcpt-01c4…7a92 signed by kernel 9b07…d31c
acceptance  Available      Accepted, predicate match, checker c7a1…02be
results     Available      output 6f0e…b31a, 3 operations
recovery    NotApplicable
settlement  Available      Paid USD 28.00, allocation 0x8c1f…40d2
delivery    Available      co-signed by kernels 4f1c…a2e9 and 9b07…d31c

Then export the signed records and verify them as an auditor would, on a machine that trusts only your trust file and the partner card:

Terminalbash
chio work export --state ./work --out ./auth-evidence auth-submit-1
chio evidence verify --input ./auth-evidence --partner partner
Output
exported     ./auth-evidence  agreement, commitment, custody receipt, decision, 4 receipts

package      ./auth-evidence  9 records
agreement    7e1d…c04a  buyer and provider signatures verified
decision     0x51bc…0d78  EIP-712 signer 0x9f62…3ad5, the pinned verifier
receipts     4 of 4 verified, kernels 4f1c…a2e9 and 9b07…d31c (card: partner)
receipt      rcpt-01c4…7a92  allow  pricing-openapi-auth/auth-inventory, co-signed
verified     offline, against .chio/trust.toml and the partner card

You should see Paid USD 28.00 and a verified package that ends in your partner’s co-signed receipt, rcpt-01c4…7a92. Collecting never prints the protected result bytes; read the inventory through the recovery release operation, which checks your current authority as a recipient.

A wrong or missing result refunds you

Each failure leaves its own record, and none of them pays for work the checker did not accept.

The inventory does not match the checker’s

The verifier signs accepted: false with predicate mismatch, the escrow records Rejected, and the USD 28.00 returns to your payer address.

Terminalbash
chio work inspect --state ./work auth-submit-1
Output
acceptance  Available      Rejected, predicate mismatch, checker c7a1…02be
settlement  Available      Refunded USD 28.00 to 0x41a3…9be0
The verifier never decides

When custody cannot produce the retained bytes, the verifier makes no decision at all; missing evidence is never a rejection. After refundAfter the claim times out and refunds, and the view keeps the timeout distinct from a rejection.

Terminalbash
chio work inspect --state ./work auth-submit-1
Output
acceptance  Unavailable    custody returned no retained bytes, no decision
settlement  Available      TimedOut after 2026-10-17T18:00Z, Refunded USD 28.00
A command is sent twice

Submitting auth-submit-1 again returns the original outcome, and the work is never dispatched twice. A different body under the same command id is refused before dispatch. After a timeout, query the original id; neither the SDK nor the CLI generates a replacement id or retries a side effect.

Next: what happens when a parent fails

Work Claim EscrowSee why an earned child claim survives a refunded parent, and how unknown outcomes settle.Work Agreements and FundingLet your partner subcontract from prefunded money under a procurement permit.
PreviousWork Claim EscrowNextThe Delivery Contract