Protocol

Result lifecycle

Settlement is a sequence of commitments and irreversible transitions. Every accepted result must refer to the exact task that funded it.

1. Commit the task

The requester selects a program digest, input root, result policy, verifier identifier, amount, expiry, and unique salt. The ledger derives a domain-separated task identifier that includes the host chain and contract deployment.

taskId = H(
  domain || requester || programId || inputRoot ||
  resultPolicy || verifierId || asset || amount || expiry || salt
)

Creation locks the deposit and freezes the charge using current policy. Subsequent policy changes affect only new tasks.

2. Execute elsewhere

After sufficient confirmation depth, operators recover the input envelope, validate every commitment, and run only program versions they explicitly support. Private witnesses remain outside public settlement calldata unless the selected proof design requires disclosure.

3. Bind the result

The operator encodes output according to the committed policy and computes its result root. Evidence must bind at least the task identifier, program, input root, result root, intended beneficiary, verifier version, chain, and settlement contract.

statement = H(taskId || programId || inputRoot || resultRoot || beneficiary)
accept = Verify(verifierKey, statement, evidence)

4. Verify before mutation

The ledger rejects late, repeated, or malformed submissions before calling the adapter. A verifier revert counts as failure. Only an explicit acceptance permits terminal state mutation and vault accounting.

5. Resolve balances

On acceptance, the operator amount and snapshotted protocol charge become pull-based balances. External transfers do not occur inside the core verification path. On expiry, the full deposit becomes claimable by the requester instead.

ConservationFor every task, cumulative withdrawals plus remaining claimable balances must equal the amount originally locked. A task can resolve only once.