Work Claim Escrow

A claim moves through seven states on four deadlines

Every move is one contract function with a precondition on the state and a window on the deadlines. Funding fixes those deadlines in strict order, so the decision window always closes before refunds open.

Acknowledgments are idempotent and changes are not: resending the same commitment or decision does nothing, and different bytes revert. A payment or refund transfer cannot repeat, and a failed transfer reverts the whole transition. The escrow checks the balances on both sides of every transfer, so an allowlisted token that moved a different amount fails the call instead of consuming another claim’s backing.

The administrator can pause new funding and change which tokens and verifiers new terms may name. Existing terms and claims are immutable, and a payable claim withdraws with no pause gate and no fresh registry check.

The verifier signs one typed decision

The verifier retrieves the retained input and output, reruns the pinned checker, and persists its decision before it releases the result. Its signature is EIP-712 typed data bound to this escrow on this chain:

{
  "domain": {
    "name": "ChioWorkClaimEscrow",
    "version": "1",
    "chainId": 8453,
    "verifyingContract": "0x3b9e…a71c"
  },
  "primaryType": "ChioWorkDecision",
  "message": {
    "allocationId": "0x8c1f…40d2",
    "agreementDigest": "0x7e1d…c04a",
    "commitment": "0x2a90…f1e3",
    "decisionDigest": "0x51bc…0d78",
    "accepted": true,
    "beneficiary": "0x7d0c…12f4",
    "token": "0x8335…2913",
    "amount": "28000000"
  }
}

Any courier may carry the signature to recordDecision; the escrow recovers the signer, compares it with the verifier in the terms, and refuses a malformed or high-s signature. The message repeats the beneficiary, token, and amount from the terms, so a decision signed for one allocation cannot pay another. A wrong result gets accepted: false with predicate mismatch; missing or tampered custody, authority, or checker inputs get no decision at all.

An earned claim survives the failure of its parent

Each allocation stands alone. When the work below a failed agreement was already accepted, its claim stays payable with no action from the party that failed.

In the child case, your partner funded the specialist from its own money, the specialist’s result was accepted, and your partner never delivered. Your USD 28.00 comes back to you, the specialist withdraws USD 6.00 after all deadlines, and your partner bears that cost. The table lists what each failure leaves standing.

Uncertain execution stays uncertain while money moves

No party may turn an uncertain execution into “no effect” to release funds. When a provider dies before a known return, the original operation and its unknown terminal stay on record; recovery resolves them by original identity and never dispatches the work again. Delivery and money are separate facts, and each leaves uncertainty one way. After an unknown outcome, only a MutuallyAgreedUnknown co-signed by both parties releases money. For a known return whose capture is pending, only a ContractualCaptureWaiver stops the capture.

Each of those records is a new financial event that leaves the earlier history intact. A hold blocks finalization, receipts, and delivery, and never blocks a co-signed monetary successor. Every finalizer reads the effective payment journal before it acts, and a finalizer under a rotated key signs with the current key and binds the original identity.

chio work inspect --state ./work auth-submit-1

handle      pricing-openapi-auth/auth-inventory, request req-01c4…7a90
execution   Available      UnknownEffect, rcpt-01c4…7a92 signed by kernel 9b07…d31c
acceptance  Unavailable    no result to check
results     Unavailable    no result to release
recovery    Available      CommitUnknown, original operation retained, no second dispatch
settlement  Available      MutuallyAgreedUnknown, co-signed by both kernels
                           escrow 0x8c1f…40d2 Refunded USD 28.00 after refundAfter
delivery    Available      co-signed by kernels 4f1c…a2e9 and 9b07…d31c

The money moved and the execution did not change: the view still reads UnknownEffect, and recovery holds the original operation. Unknown outcomes follows the same rule for a single tool call.

Money is conserved in every funding source

For a funding source $s$, defined by its settlement domain, asset, and exclusive allocation generation, every allocation transition keeps one identity:

• $D_s$, cumulative finalized deposits into the source.
• $P_s$, cumulative disbursements to beneficiaries.
• $R_s$, cumulative releases back to the funder.
• $L_s$, the maximum remaining liability over every reachable combination of claims.
• $F_s$, the unallocated available balance.

The liability is counted conservatively, as the sum of remaining ceilings; two terminals count as exclusive only when the funding authority enforces the exclusion. Funding, verification, retry, and dispute fees count in the source that pays them, and token transfer behavior or rounding can never leave recorded backing above the funds received. In this escrow each funding call moves exactly one allocation, so $F$ is zero and $L$ is the claim’s amount until it pays or refunds. Money Conservation states the kernel’s own law for every budget hold.

The escrow trusts its verifier and its token

A dishonest verifier can certify a false result, and an unavailable one can make a provider that did the work miss the decision window; that residual loss falls on the provider under the timeout terms. The exchange depends on a trusted verifier by design. The escrow assumes the allowlisted token behaves honestly; balance checks cannot defend against arbitrary malicious balance reporting or later seizure by the issuer. The kernel’s local budget and nonce transitions and the chain’s transfers are separate commits, so an ambiguous submission is reconciled against the rail’s state before another transaction is created.

Next: run a purchase through the escrow