Skip to content
Northset Docs

OCH-1.1 protocol

OCH-1.1 is Northset’s protocol for deterministic tasks that settle through USDC escrow and proof verification on Arbitrum One. A delegator funds a task, a delegatee signs a bid, and the hub releases payment after the task’s verifier accepts the result.

TaskSpec commitment -> signed bid -> selection -> activation -> valid proof -> settlement

Core roles

Section titled “Core roles”
Role Responsibility
Delegator Defines the task, escrows the maximum reward, and selects a signed bid.
Delegatee Signs a bid, activates the selected task by posting a bond, and submits the result proof.
Verifier maintainer Registers verifier contracts that implement a documented deterministic program.
Treasury operator Claims protocol fees that the hub accrues after successful settlement.

Each participant uses a wallet-derived DID in off-chain objects:

did:pkh:eip155:<chainId>:<0xAddress>

The contracts use the corresponding EVM addresses directly.

Protocol guarantees

Section titled “Protocol guarantees”
  • USDC escrow: the hub receives the creator’s maxRewardUSDC when the task is created. OCH-1.1 represents every USDC amount as integer microunits with six decimals.
  • Committed instructions: specHash commits to an RFC 8785 canonical TaskSpec, while inputHash commits to the verifier input.
  • Signed selection: the hub checks an EIP-712 Bid against the task, the delegatee’s current nonce, and the hub’s domain before selection.
  • Explicit activation: selection records the bid; activation transfers the delegatee’s bond and starts the submission clock.
  • Pinned verification: task creation snapshots the active verifier address and its runtime code hash. Settlement uses that snapshot.
  • Proof-bound payout: the hub checks the task, input, and output commitments inside static publicValues, calls the verifier, records the output hash, and pays the stored delegatee.
  • Deterministic exits: open, selected, and active tasks each have contract-enforced refund or timeout paths.

State transitions

Section titled “State transitions”
OPEN -> SELECTED -> ACTIVE -> COMPLETED
  |         |
  |         +------> OPEN
  +---------------> CANCELLED


ACTIVE -> TIMED_OUT

The two-step SELECTED -> ACTIVE boundary gives the delegatee control over when the bond enters escrow. Read Task lifecycle for the calls, deadlines, and settlement effects at every transition.

Commitments from task to proof

Section titled “Commitments from task to proof”

Three commitments connect the off-chain task to the on-chain result:

  1. specHash = keccak256(JCS(taskSpecJson)) binds the task instructions.
  2. inputHash binds the exact input expected by the verifier program.
  3. outputHash binds the deterministic output proved by the delegatee.

The hub stores specHash and inputHash when the task opens, and the selected Bid repeats specHash. A successful submission carries taskId, inputHash, and outputHash in the proof’s public values, and the hub stores the resulting outputHash on completion.

Continue with: