Skip to main content

​
Overview

Cowboy is a Layer 1 blockchain purpose-built for autonomous agents and verifiable off-chain computation. Unlike traditional smart contract platforms, Cowboy treats time, compute vs. storage pricing, off-chain work, and large data as first-class protocol primitives.
Key Insight: Cowboy treats time as a first-class citizen. Actors can schedule their own future execution without depending on external keepers, bots, or relayers.

​
The Problem Space

Modern blockchain platforms face a few fundamental challenges for agentic workloads:

​
1. No Native Time Awareness

Smart contracts cannot schedule their own future execution. Developers fall back on:
  • External bots (centralized, unreliable)
  • Keeper networks (expensive, extra trust)
  • User-triggered transactions (poor UX)

​
2. Unfair Resource Pricing

A single gas metric can’t distinguish between:
  • Computation (CPU cycles)
  • Storage (state growth, persisted forever)
  • Data transfer (bandwidth)
This subsidizes one use case at the expense of another and makes fees hard to predict.

​
3. Limited On-Chain Computation

On-chain VMs are intentionally constrained — no AI/ML inference, no large data processing, no external API calls, no off-chain data access. Moving compute off-chain then introduces trust issues.

​
4. No Native Large-Data Storage

Storing anything bigger than a few KB on-chain is prohibitively expensive. Developers resort to IPFS, Arweave, or centralized S3, each with its own trust model.

​
Cowboy’s Solution

​
1. Protocol-Level Timers (CIP-1)

Native timers as a core primitive:
  • Tiered Calendar Queue: O(1) enqueue/dequeue for near-term timers
  • Dynamic Gas Bidding (GBA): Actors bid for priority using protocol-supplied context
  • Autonomous Execution: No external keeper infrastructure required

​
2. Dual-Metered Gas Model (CIP-3)

Compute and data are metered independently with separate fee markets:

Cycles (Computation)

What it measures: VM work — bytecode instructions, function calls, operationsUse case: Python code execution, cryptography, data processingMetering: Fuel-based tracking inside the Rust-backed PVM

Cells (Data/Storage)

What it measures: Bytes — transaction payloads, storage writes, return dataUse case: State storage, large inputs/outputs, blob commitmentsMetering: Event-based accounting at I/O boundaries
Benefits:
  • Fair pricing: pay for what you actually use
  • Predictable costs: each resource has its own basefee
  • DoS protection: separate limits per dimension

​
3. Verifiable Off-Chain Compute (CIP-2)

Actors outsource work to a decentralized runner network while keeping results verifiable on-chain. Runner executor types:
  • LLM — OpenAI, Anthropic, OpenRouter, and compatible APIs
  • HTTP — Arbitrary authenticated HTTP requests
  • MCP — Model Context Protocol tool calls
Key properties:
  • VRF-based selection: Deterministic, verifiable runner assignment
  • Asynchronous execution: Deferred callback via continuation FSM (CIP-6)
  • Configurable verification: N-of-M consensus, TEE attestation, or ZK proofs
  • Market-driven pricing: Runners compete on price and reliability

​
4. Encrypted Distributed Storage (CBFS)

Large data (models, datasets, media, logs) lives off-chain in CBFS:
  • Client-side AES-256-GCM encryption — storage nodes never see plaintext
  • Reed-Solomon erasure coding — K data + M parity shards, recover from any K
  • QUIC transport — low-latency shard reads/writes
  • FUSE mount — actors and runners attach volumes as normal filesystems via delegated capability tokens
Metadata authority lives on-chain (volume registry, capability tokens); shard data lives on relay nodes.

​
5. Ethereum-Compatible Keys

Cowboy uses the same secp256k1 keypairs and 20-byte address scheme as Ethereum. An existing Ethereum key works unchanged — same address, same signing flow. This makes wallet integration, tooling reuse, and cross-chain bridging dramatically simpler.

​
Core Architecture

​
Actor Model

Cowboy uses an actor-based execution model: 
+----------------------+
|   Transactions       |
+----------------------+
          |
          v
+------------------------------------------------------------+
|    Actor                                                   |
|  - Persistent State (KV store, priced in Cells)            |
|  - Handler Methods (Python)                                |
|  - Mailbox (incoming async messages)                       |
|  - Timer Queue (scheduled execution, CIP-1)                |
|  - Balance (CBY, the native token)                         |
|  - Continuation state (suspended off-chain jobs)           |
+------------------------------------------------------------+
          |
          v
+----------------------+
|   Responses / events |
+----------------------+
Characteristics:
  • Isolated state: each actor has its own KV storage
  • Message-driven: asynchronous, deterministic ordering
  • Single-threaded: one handler invocation at a time
  • Autonomous: schedules its own future execution via timers and deferred jobs

​
Python VM

Actors are Python programs executed in the PVM — a Rust-based deterministic Python 3 interpreter (forked from RustPython). Two ways to write an actor: Low-level (host API): import pvm_host directly. 
import pvm_host

def increment(ctx, payload):
    val = pvm_host.get_state(b"counter") or b"\x00" * 8
    n = int.from_bytes(val, "big") + 1
    pvm_host.set_state(b"counter", n.to_bytes(8, "big"))
    return n
Recommended — CIP-6 SDK: use cowboy_sdk decorators for typed storage, async runner calls, and continuation-based FSMs. 
from cowboy_sdk import actor, runner, capture, CowboyModel

@actor
class Counter:
    def __init__(self):
        self.storage["count"] = 0

    def increment(self):
        self.storage["count"] += 1
        return self.storage["count"]
VM guarantees:
  • ✅ Determinism: same input → same output, bit-identical across all nodes
  • ✅ Sandboxing: no file I/O, no network, no system calls
  • ✅ Fuel metering: every bytecode operation has a cost
  • ✅ Checkpointable: full program state can be serialized and resumed (the mechanism behind async runner jobs)

​
Fee Markets

Two independent EIP-1559-style markets: 
Cycles Market:
  basefee_cycle adjusts based on compute usage per block

Cells Market:
  basefee_cell adjusts based on data/storage usage per block

Total Fee = (cycles_used × basefee_cycle) + (cells_used × basefee_cell) + tips
Basefee is burned, creating deflationary pressure on CBY.

​
Key Differentiators

FeatureTraditional ChainsCowboy
TimersExternal keepersNative protocol (CIP-1)
LanguageDomain-specific (Solidity, Move)Python
Gas ModelSingle metricDual-metered (Cycles + Cells)
Off-chain ComputeTrusted oraclesVerifiable runner network (LLM/HTTP/MCP)
Large-data StorageIPFS / Arweave / S3Native encrypted CBFS
KeysChain-specificEthereum-compatible secp256k1
AutonomyReactive onlyFully autonomous
ConsensusVariesSimplex BFT (~1s blocks, ~2s finality)

​
Design Principles

Every operation must produce identical results on every node. Software float, no JIT, curated stdlib, no system calls.
Compute, storage, and data are priced independently based on actual costs.
Actors schedule their own execution. No external keepers required.
Heavy or non-deterministic work (LLM inference, HTTP, MCP) runs off-chain but returns verifiable results.
Python, a familiar SDK, Ethereum-compatible keys. Don’t force people to learn niche languages or re-issue keys.

​
Next Steps

Key Innovations

The technical details behind each pillar

Quickstart

Build and run your first actor

Architecture

End-to-end system design

Minimal Actor

Anatomy of a Cowboy actor

​
Further Reading