Skip to main content

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.
Key Innovation: Actors can run computationally expensive tasks off-chain with cryptographic verification, without sacrificing decentralization or security.
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

Cowboy’s Solution: Decentralized Runners

Core Architecture

+------------------------------------------------------------------+
|                      Actor (On-Chain)                            |
|  - Submits task definition                                       |
|  - Specifies verification requirements                           |
|  - Receives results asynchronously                               |
+-------------------------------+----------------------------------+
                                | Task Submission
                                v
+------------------------------------------------------------------+
|           Task Dispatcher (On-Chain Contract)                    |
|  - Stores task specifications                                    |
|  - Locks payment                                                 |
|  - Snapshots VRF seed + active runner list                       |
+-------------------------------+----------------------------------+
                                | VRF Selection (Deterministic)
                                v
+------------------------------------------------------------------+
|               Runner Network (Off-Chain)                         |
|  - Selected runners execute task                                 |
|  - Download models/data as needed                                |
|  - Generate proofs if required                                   |
|  - Submit results on-chain                                       |
+-------------------------------+----------------------------------+
                                | Result Submission
                                v
+------------------------------------------------------------------+
|        Runner Submission Contract (On-Chain)                     |
|  - Validates runner selection                                    |
|  - Validates result size                                         |
|  - Triggers callback when N results collected                    |
+-------------------------------+----------------------------------+
                                | Deferred Callback
                                v
+------------------------------------------------------------------+
|                 Actor Callback (On-Chain)                        |
|  - Receives all results                                          |
|  - Chooses winning result                                        |
|  - Triggers payment distribution                                 |
+------------------------------------------------------------------+

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
  • TaskSubmitted event 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:
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