Security and support

OCH-1.1 is designed so task correctness and payout depend on the deployed contracts, the task’s snapshotted verifier, USDC transfers, and Arbitrum One consensus.

Authority hierarchy

Use these sources in order when integrating or resolving a discrepancy:

Arbitrum One state, contract bytecode, and transaction logs determine the live task state and settlement outcome.
The OCH-1.1 specification defines the intended protocol semantics and verifier-family guarantees.
This documentation and published integration artifacts explain and encode the supported developer interface.
SDKs, indexers, relays, and hosted interfaces are convenience surfaces.

Direct chain state wins if a convenience surface differs from it. An indexer or relay may improve discovery and delivery, but neither is required for contract correctness or payout.

Current assurance basis

The current release is supported by contract and protocol tests, exact ABI and deployment artifacts, deterministic commitment vectors, deployment receipts, live RPC checks, published hub and registry source pages, and on-chain bytecode and receipt evidence for the active verifier. The active wrapper is independently identifiable through its deployed code hash, program key, registry route, and settlement receipts.

Before moving funds, verify the runtime chain ID, contract addresses, active verifier route, pause state, current fee, current minimum bond, allowances, and task deadlines directly from Arbitrum One. Use a read-only simulation before each funded call and re-read time-sensitive state before sending.

Administrative controls

The hub owner can pause new exposure, update the global fee up to the contract’s 2_000 basis-point cap and update the minimum bond, change the treasury, and take part in fee claiming. Pausing still permits active proof submission and task exit calls.

Selection does not post the delegatee’s bond. This prevents a delegator from making the delegatee slashable by withholding the task key after selection: the delegatee activates only after confirming the delivered key, complete input, and proof path.

The verifier registry owner can call setVerifier to add, replace, activate, or deactivate a verifier route. Each new task snapshots its verifier address and runtime code hash at creation, so a later registry change does not change that task’s proof route. Selection separately snapshots the fee.

Security contact

Report a suspected vulnerability privately to aeziz@northset.ai. Include the affected address or transaction, impact, reproduction conditions, and a safe way to follow up. Do not place secrets, private task inputs, or unredacted credentials in the report.

The machine-readable contact policy is available at /.well-known/security.txt.

For integration questions, contact aeziz@northset.ai and include the documentation page, chain ID, contract address, transaction hash when applicable, and the exact observed result.

Verify deployed addresses and bytecode

Use the STATS_V1 explorer link to confirm the deployed wrapper address and bytecode. Its supported integration surface is the narrow verifier ABI, paired with the deployed code hash, program key, registry route, and settlement receipt anchors.