Skip to main content

​
General Questions

Cowboy is a Layer 1 blockchain designed for autonomous agents and verifiable off-chain computation. It features:
  • Python-based actors (smart contracts) instead of Solidity
  • Dual-metered gas system (Cycles for compute, Cells for data)
  • Native timers for autonomous execution
  • Verifiable off-chain compute via a runner network (LLM, HTTP, MCP)
  • CBFS — encrypted distributed storage with FUSE mount
  • Ethereum-compatible keys — the same secp256k1 addresses work on both chains
Think of it as “Ethereum but optimized for AI agents, complex computation, and large data.”
Advantages of Python:✅ Familiar: 80%+ of AI/ML developers already know Python ✅ Expressive: Cleaner, more readable code ✅ Ecosystem: Direct access to data structures, algorithms ✅ AI-Ready: Natural fit for AI agent logicHow we make it work:
  • Deterministic Python VM (no system calls, no I/O)
  • Software floating-point for consensus
  • Strict module whitelist
  • Comprehensive gas metering
See Actor VM & Determinism for details.
Actors are Cowboy’s equivalent of smart contracts. Key differences:
ConceptEthereumCowboy
ContractSolidity contractPython Actor
FunctionExternal functionHandler method
StateStorage variablesstorage API
CallTransactionMessage
Address0x…0x…
Example (using the CIP-6 SDK):
from cowboy_sdk import actor

@actor
class MyActor:
    def my_handler(self, param):
        value = self.storage.get("key", 0)
        self.storage["key"] = value + param
        return value
Not at the VM level, but keys are compatible.❌ VM / contracts are not compatible:
  • Different VM (Python-based PVM instead of EVM)
  • Different transaction format
  • Different gas model (Cycles + Cells vs. single gas)
✅ Keys and addresses are compatible:
  • Same secp256k1 curve
  • Same 20-byte address derivation
  • An existing Ethereum key works unchanged — same address, same signing flow
Migration path for contracts: Solidity contracts need to be rewritten in Python, but the business logic ports naturally. Wallet tooling usually works as-is.
FeatureEthereumCowboy
LanguageSolidityPython
VMEVMPython VM
Gas ModelSingle gasCycles + Cells
TimersNo (need Gelato, etc.)Native
Off-Chain ComputeOracles (Chainlink)Native (CIP-2)
ConsensusPoS (Gasper)Simplex BFT
Target Use CaseGeneral DeFiAI Agents + Computation

​
Technical Questions

Cowboy separates resource pricing into two dimensions:Cycles (Computation):
  • Measures CPU work
  • Every bytecode instruction costs cycles
  • Example: Function call = 10 cycles
Cells (Data/Storage):
  • Measures data and storage
  • 1 Cell = 1 byte
  • Charged at I/O boundaries
Why?
  • Fair pricing: Don’t subsidize compute-heavy apps with storage costs
  • Independent markets: Each resource has its own basefee
  • Predictable: Know exactly what you’re paying for
See Fee Model for details.
Verifiable Off-Chain Compute (CIP-2):
  1. Submit Task: Actor calls runner.llm(), runner.http(), or runner.mcp() from within an @runner.continuation handler (CIP-6 SDK)
  2. VRF Selection: Runners deterministically selected via VRF snapshot
  3. Execution: Selected runners execute the task off-chain (LLM inference, HTTP call, MCP tool)
  4. Result Submission: Runners submit results + optional proof on-chain
  5. Resume: Actor’s continuation resumes in a later block with the result
  6. Payment: Actor chooses a winning result; payment flows to the runner(s)
See Off-Chain Compute and SDK Overview.
Yes, completely deterministic. All nodes must produce identical results.How we achieve it:
  • ✅ Software floating-point (no hardware FPU)
  • ✅ No JIT compilation
  • ✅ Deterministic GC (reference counting)
  • ✅ No system calls (time, random, I/O)
  • ✅ Module whitelist
What’s forbidden:
# ❌ These will fail:
import os
import random
import time
import requests
Use instead:
  • ✅ Use protocol-provided randomness/time context APIs (instead of local RNG/system time)
  • ✅ Use protocol storage and off-chain submission interfaces (see related docs)
See Determinism & Sandboxing.
Cowboy uses Simplex BFT consensus:Properties:
  • Byzantine Fault Tolerant (BFT)
  • Deterministic finality (no reorgs)
  • Leader rotation
  • Requires 2/3+ honest validators
Phases:
  1. Leader proposes block
  2. Validators vote (QC = Quorum Certificate)
  3. Block finalized with 2/3+ votes
  4. Next leader elected
vs. Nakamoto Consensus (Bitcoin):
  • ✅ Faster: 2s vs 10min
  • ✅ Finality: Immediate vs probabilistic
  • ❌ More validators needed

​
Development Questions

No! You only need Python to build actors.Rust is only needed if you want to:
  • Contribute to the core protocol
  • Build custom validator nodes
  • Optimize VM performance
For actor development:
  • ✅ Python only
  • ✅ Familiar SDK
  • ✅ Standard Python tooling
Testing Options:1. Unit Tests (Fastest):
  • Use standard Python test frameworks (pytest/unittest) to unit-test business logic
  • The cowboy_sdk ships a mock_host module for stubbing the PVM host API
2. Local Devnet (Most realistic):
  • docker compose up --build inside docker/ brings up a validator + runner on localhost
  • Point the CLI at it with cowboy init local
  • Deploy and execute actors against a real chain in seconds
3. Mesa Devnet (Shared):
  • cowboy init dev targets the shared rpc-01.mesa.cowboylabs.net:4000 devnet for team testing
See Quickstart for the full flow.
Local / devnet: Free. cowboy init local auto-funds your wallet via the built-in faucet (POST http://localhost:4000/faucet).Mainnet (when live):
  • Costs are metered separately by Cycles (compute) and Cells (bytes) with their respective basefees + tips
  • Influencing factors: bytecode size (Cells), constructor complexity (Cycles), current basefees
  • Set --cycles-limit and --cells-limit on cowboy actor deploy; see Fee Model
Only the curated stdlib subset shipped with the PVM.Forbidden:
  • ❌ requests, httpx, urllib.request — network I/O
  • ❌ numpy, pandas, tensorflow, torch — native C/C++ extensions
  • ❌ os, subprocess, socket — system calls
  • ❌ random, time — non-deterministic (use protocol-provided APIs)
Allowed (curated):
  • ✅ collections, itertools, functools — deterministic data structures
  • ✅ json — encoding/decoding
  • ✅ math — deterministic software FP
  • ✅ hashlib — BLAKE3, SHA-256, etc.
  • ✅ pvm_host — low-level host API
  • ✅ cowboy_sdk — high-level SDK (CIP-6)
For external data or compute:
  • Use runner.llm() / runner.http() / runner.mcp() from an @runner.continuation handler (CIP-2)
  • Large data: store in CBFS volumes
See Determinism & Sandboxing.
Steps (general guidance):
  1. Check the transaction receipt/error message (block explorer or SDK)
  2. Common causes:
    • Insufficient Cycles limit: increase gas_limit_cycles or optimize computation
    • Insufficient Cells limit: increase gas_limit_cells or reduce data
    • Input or business validation failure: verify input data and business logic
    • Insufficient permissions: check access control and caller
  3. Unit test locally before on-chain validation
Actors are immutable by default; conceptual strategies include:
  • Proxy pattern: delegate calls to a replaceable implementation with strict access control
  • Redeploy: deploy a new version, migrate state, update frontend addresses
  • Migration contract: dedicated migration process (batch validation/rollback strategy)
Security notes: access control, replay protection, data consistency checks.

​
Economics & Token Questions

Formula:
Total Fee = (Cycles Used × Basefee_Cycle) + 
            (Cells Used × Basefee_Cell) +
            (Cycles Used × Tip_Cycle) +
            (Cells Used × Tip_Cell)
Basefee: Burned 🔥 (deflationary) Tip: To block producer (incentive)See Fee Model.
Dual EIP-1559 Mechanism:Basefees adjust dynamically based on demand:
If block usage > target (50%):
  → Basefee increases

If block usage < target (50%):
  → Basefee decreases
Example:
Block N: 80% utilization
→ Basefee +7.5%

Block N+1: 30% utilization
→ Basefee -5%
Benefits:
  • Fair pricing (supply/demand)
  • Predictable (can estimate fees)
  • Anti-spam (expensive during congestion)
See Dual EIP-1559.

​
Community & Support

Official Channels:
  • 🐛 GitHub Issues — Bug reports and feature requests
  • 📧 Support: Support@cowboy.io
  • 📖 Contributing Guide — How to propose protocol changes (CIPs)
Ways to Contribute:
  1. Code:
    • Core protocol (Rust)
    • SDK improvements (Python)
    • Tooling and CLI
  2. Documentation:
    • Write tutorials
    • Fix typos
    • Add examples
  3. Testing:
    • Run a local devnet via docker/
    • Test against the Mesa devnet (cowboy init dev)
    • Report bugs on GitHub
  4. Community:
    • Answer questions in GitHub Discussions
    • Write blog posts and tutorials
    • Create videos and demos
See Contributing Guide.

​
Still Have Questions?

GitHub Issues

Browse existing issues or file a new one

Email Support

Reach the team directly