Introduction
Cowboy’s Verifiable Off-Chain Compute framework enables actors to outsource heavy computation, AI model inference, and external data fetching to a decentralized network of “Runners” while maintaining verifiability and trust minimization.Note: Examples and names in this page are conceptual and illustrative (non-normative). Final interfaces and usage should follow the SDK and Developer Guide; normative behavior follows the Off-chain architecture documents.
The Problem
On-Chain Computation Limits
Traditional smart contracts face severe computational constraints: On-chain execution is intentionally constrained: no external network access, no large model loading, and bounded per‑transaction computation. Heavy compute and external data access must be handled via the off‑chain framework.Current Solutions Fall Short
- Oracles (e.g., Chainlink)
- Optimistic Rollups
- ZK Rollups
- Centralized Services
Approach: Trusted off-chain nodes provide dataProblems:
- ❌ Limited to data fetching
- ❌ Cannot run custom computation
- ❌ Trust assumptions
- ❌ Expensive for frequent updates
- ❌ Not suitable for AI/ML
Cowboy’s Solution: Decentralized Runners
Core Architecture
Key Components
Task Dispatcher
On-chain contract for task submission and payment management
Runner Registry
Manages runner registration, staking, and active list
VRF Selection
Deterministic, verifiable runner assignment
Result Schemas
Mandatory specifications for task inputs/outputs
How It Works
Step-by-Step Workflow
1
1. Task Submission
Actor submits
task_definition with mandatory result_schema, providing num_runners, timeout_blocks, and proof_type_requested.What happens:- Task stored in Dispatcher state
- Payment locked (3 × 100 = 300 CBY)
- VRF seed snapshot taken
- Active runner list snapshot taken
TaskSubmittedevent emitted
2
2. VRF-Based Runner Selection
Runners independently compute selection using the VRF seed snapshot and the active runner list at submission (CIP‑2). Anyone can verify selection on-chain.Key properties:
- ✅ Deterministic (same inputs → same selection)
- ✅ Verifiable (anyone can check on-chain)
- ✅ Decentralized (no coordinator)
- ✅ Fair (equal probability over time)
3
3. Off-Chain Execution
Selected runners execute off‑chain, optionally generating proofs/attestations per requested verification mode, and then submit results on‑chain.
4
4. Result Submission
Submission enforces runner selection,
result_schema bounds, and proof/attestation checks; when N valid results are stored, a deferred callback is scheduled (CIP‑1/CIP‑2).5
5. Deferred Callback
Deferred callback is created and scheduled under the scheduler’s per‑block budget (CIP‑1).
6
6. Callback Execution
Actor callback selects the consumed result (e.g., quorum for N‑of‑M) and calls
consume_result(task_id, consumed_runner_address) to finalize payment (CIP‑2).7
7. Payment Distribution
Dispatcher verifies the consumed result and distributes payment to the selected runner(s), refunding any unused portion to the actor; the task is finalized.
Verification Models
Developers choose the verification model based on their trust/cost trade-offs:- N-of-M Consensus
- Zero-Knowledge Proofs
- TEE Attestation
How it works: Run task on N runners, require M matching results.Trust model: Economic security + honest majorityCost: Medium (pay N runners)Use cases:
- Price oracles
- General computation
- Data aggregation

