Identity, key delivery, and capabilities

OCH-1.1 uses wallet addresses on-chain and canonical DIDs in off-chain objects. Encrypted task delivery and scoped capabilities let participants coordinate private resources without changing settlement authority.

Participant identity

Represent each participant with a did:pkh DID derived from the runtime chain and wallet address:

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

For Arbitrum One, chainId is 42161. Contracts use the corresponding EVM address directly. Confirm that each off-chain DID and on-chain address identify the same participant before signing a task or bid.

Encrypt the task input

Encrypt task inputs before uploading them. The OCH-1.1 baseline supports authenticated encryption with XChaCha20-Poly1305 or AES-256-GCM. Store only the plaintext commitment in inputHash, and keep plaintext inputs, API keys, and unwrapped encryption keys out of transactions and logs.

At bid selection, the delegator passes the chosen delegatee’s bounded key-delivery payload as encryptedKey in selectBid. The hub emits those bytes in TaskSelected.

The byte format is bilateral and outside the on-chain protocol. Participants must agree on the encryption algorithm, key-wrap format, nonce, associated data, and encoding, then test a complete encrypt, deliver, decrypt, and commitment-check round trip before selection.

Activation gate

The delegatee should activate only after all of these checks pass:

• TaskSelected names the expected delegatee and bid terms;
• the delivered key decrypts the complete task input;
• the locally stored plaintext recomputes to the on-chain inputHash;
• the confirmed proof path can meet the compute window; and
• the wallet is ready to post the full bond.

Activation posts the bond and starts submitDeadline. If the task is not completed by that deadline, any caller can invoke claimTimeout and the full bond transfers to the delegator.

Delegation Capability Tokens

A Delegation Capability Token (DCT) grants least-privilege access to an off-chain resource such as an API, data service, or key service. A DCT must carry at least:

• issuer_did;
• subject_did;
• resource;
• actions;
• expires_at;
• nonce; and
• an optional audience.

Resource servers must verify the signature chain, expiry, claims, audience when present, and requested action. Prefer short expiries and the narrowest useful resource and action scope.

A DCT does not control on-chain settlement. The deployed hub, task state, proof checks, and Arbitrum One transactions remain authoritative even when a DCT, relay, indexer, or hosted key service assists the workflow.

Privacy boundary

On-chain state exposes addresses, commitments, economics, deadlines, the selection encryptedKey bytes, and completion public values. Encryption protects an off-chain payload in storage and transit. A proof can limit what observers learn about its witness, but it does not hide input data from the delegatee that computes over it.

Continue with the delegator workflow or delegatee workflow.