​

Cowboy: An Actor‑Model Layer‑1 with Verifiable Off‑Chain Compute

Status: Draft for internal review
Type: Standards Track
Category: Core
Author(s): Cowboy Foundation
Created: 2025‑09‑17
License: CC0‑1.0

​

Abstract

We are in the Age of the Agent. Advancements in LLMs have unleashed new modalities for software to act autonomously, but these intelligent systems remain economically handcuffed, trapped behind APIs and corporate accounts. Crypto provides the missing element: permissionless, programmable economic agency. Cowboy is a general-purpose Layer-1 blockchain designed to bridge this gap, enabling AI agents to become native citizens of a digital economy. Cowboy combines a Python-based actor-model execution environment with a proof‑of‑stake consensus and a market for verifiable off‑chain computation. Smart contracts on Cowboy are actors: Python programs with private state, a mailbox for messages, and chain‑native timers for autonomous scheduling. For heavy tasks like LLM inference or web requests, Cowboy integrates a decentralized network of Runners who execute jobs and attest to results under selectable trust models: N-of-M consensus, TEEs, and (in V2) ZK-proofs. To ensure fair and predictable resource pricing, Cowboy introduces a dual-metered gas model, separating pricing for computation (Cycles) and data (Cells) into independent, EIP-1559-style fee markets. Security is provided by HotStuff‑style BFT proof‑of‑stake with fast finality. By bringing the world’s most dominant AI programming language, Python, directly on-chain, Cowboy provides the critical infrastructure for the next generation of autonomous agents.

​

Introduction

​

The Problem: A Chasm Between Intelligence and Agency

Most programmable chains evolved from a synchronous, function-call model, coupling storage, compute, and timing into a single transaction. This paradigm is ill-suited for the asynchrony and complexity of modern autonomous systems. Further, it forces development into nascent ecosystems like Solidity or Rust, alienating the vast majority of AI and enterprise developers who build in Python. Even for teams who bridge this gap, the result is operational chaos: a Frankenstein’s monster of cloud servers, cron jobs, oracles, and key management services, held together by brittle off-chain glue. Critically, these architectures fail to build trust. When an agent makes a decision—rebalancing a portfolio, executing a trade—users reasonably want to know why. What data did it see? How did it decide? Today’s approach offers no verifiable link between inputs, execution, and outputs. Without this foundation of trust, autonomous agents remain toys, not tools for a robust economy.

​

The Solution: Cowboy

Cowboy imports the actor model into a blockchain to provide a native, unified platform for autonomous agents. Every application is a set of actors; each actor is a Python program with deterministic execution, a persistent key/value store, and a mailbox. The chain delivers messages and timers, enforces resource limits, and commits state transitions in blocks. For work that cannot or should not run on-chain, Cowboy exposes a native market where Runners execute jobs off-chain and post verifiable results. This document presents Cowboy’s architecture, the state transition function, the economic mechanisms for fees and verification, and an initial parameter set.

​

Key Innovations in Cowboy

General‑purpose chains struggle with data‑hungry, latency‑sensitive apps. Cowboy makes actors and verifiable off‑chain compute native through four key innovations:

• Deterministic Python Actors: A sandboxed Python VM with mailbox messaging, reentrancy (depth‑capped), and first-class support for the world’s most popular programming language.
• Native Timers & Scheduler: A protocol-level mechanism for autonomous, scheduled execution with dynamic, context-aware gas bidding, eliminating the need for external keeper networks.
• Verifiable Off-Chain Compute: An open marketplace for off-chain jobs (e.g., LLM inference, API calls) with selectable trust models, including N-of-M consensus, TEE attestations, and (in V2) ZK-proofs.
• Dual-Metered Gas: Independent pricing and EIP-1559-style fee markets for compute (Cycles) and data/storage (Cells) to ensure fair and predictable costs.

​

Accounts and State

Cowboy distinguishes two object types:

• External Accounts (EOAs): Controlled by private keys (secp256k1). They initiate transactions and hold balances of CBY and other assets.
• Actors: Autonomous Python programs executed in the PVM (Python Virtual Machine). Actors own storage, receive messages, and can send messages to other actors.

Each object has a 20‑byte address. Actor addresses are computed CREATE2‑style from the creator address, a salt, and the code hash. The world state is a mapping: State : Address → { balance, nonce, code_hash?, storage?, metadata } where actor storage is a key/value map with a quota (default 1 MiB) and rent. System actors and precompiles occupy a reserved prefix of the address space.

​

Transactions and Message Passing

A user interacts with Cowboy by sending a transaction (signed with secp256k1) specifying a destination, a payload, and resource limits: a cycles limit and a cells limit alongside maximum and tip prices for each. An actor interacts with other actors by sending messages. Messages carry a small payload, may transfer value, and may trigger further messages. Delivery is exactly‑once, and actors may schedule timers that insert messages at a future block height. To avoid denial‑of‑service through explosive fanout, Cowboy caps the number of messages any transaction (and its triggered cascades) can enqueue.

​

Native Timers and the Actor Scheduler

To enable true autonomy, Cowboy provides a protocol-native timer and scheduling mechanism, eliminating the need for external keeper networks. Actors can schedule messages to be sent to themselves or other actors at a future block height or on a recurring interval. The scheduler is designed to be scalable, economically rational, and fair.

​

Scalable Design: The Tiered Calendar Queue

The scheduler uses a multi-layered tiered calendar queue to manage timers efficiently across different time horizons without compromising performance. This architecture consists of three levels:

• Tier 1: Block Ring Buffer: An O(1) queue for imminent timers, organized as a ring buffer where each slot represents a single block. This handles near-term scheduling with maximum efficiency.
• Tier 2: Epoch Queue: A medium-term queue for timers scheduled in future epochs. Timers from this queue are efficiently migrated in batches to the Block Ring Buffer at the start of each new epoch.
• Tier 3: Overflow Sorted Set: A Merkleized binary search tree for very long-term timers that fall outside the Epoch Queue’s range, ensuring the protocol can handle any future-dated schedule.

This tiered design ensures that the per-block work of processing timers remains constant and small, regardless of the total number of scheduled timers.

​

Economic Rationality: The Gas Bidding Agent (GBA)

A key innovation in Cowboy’s scheduler is the concept of the Gas Bidding Agent (GBA). Instead of pre-paying a fixed gas fee, an actor designates a GBA (which is another actor) to dynamically bid for its timer’s execution when it becomes due. When a timer is ready to be executed, the protocol performs a read-only call to the actor’s GBA, providing it with a rich context object containing real-time data like network congestion (current base fees), the timer’s urgency (how many blocks it has been delayed), and the owner’s balance. The GBA uses this context to return a competitive gas bid. This creates an intra-block auction for a dedicated portion of the block’s compute budget, ensuring that high-priority tasks can get executed even during periods of high network traffic. To ensure a simple developer experience, actors which do not specify a GBA receive the network default.

​

Fairness and Liveness

Timers that are not executed due to low bids or network congestion are automatically deferred to the next block. To prevent “timer starvation” where an actor is perpetually outbid, the protocol tracks an actor’s scheduling history. It uses a weighted priority system with exponential decay to give a small boost to actors whose timers have been repeatedly deferred, ensuring eventual execution and maintaining network fairness.

​

The Cowboy Actor VM (PVM)

​

Why Python?

Python is the language of AI and the glue of modern software. It is where builders already live, with a massive developer base and an unmatched ecosystem of tools and libraries. Cowboy turns that familiarity into production power: write a simple Python script and deploy an accountable, always‑on actor, while the protocol enforces determinism and safety. The result is a shorter path from idea to launch and a much wider funnel of teams who can build.

​

Execution Environment and Determinism Guarantees

Actors are Python programs executed in the PVM inside a deterministic sandbox. For the network to reach consensus, every node must produce the exact same result from the same code. The whitepaper’s claim of determinism is backed by a rigorous set of consensus-critical rules enforced by the VM:

• No JIT Compilation: The PVM operates in a pure interpretation mode, forbidding any Just-In-Time (JIT) compilation, whose optimizations are a source of non-determinism.
• Deterministic Garbage Collection: Memory is managed via deterministic reference counting. Non-deterministic garbage collection mechanisms that could cause pauses or varied behavior are disallowed.
• Deterministic Math: All floating-point operations MUST use a cross-platform, deterministic software-based math library, not the host machine’s native FPU, to prevent micro-variations across different CPU architectures.
• Whitelisted Imports: Actors can only import modules from a strict, consensus-defined whitelist. This prevents access to non-deterministic or insecure libraries that could interact with the underlying system (e.g., networking, filesystem).
• Deterministic Serialization: All object serialization, used for storing state or sending messages, follows a canonical format (e.g., sorting dictionary keys) to ensure byte-for-byte identical output across all nodes.
• Forbidden Operations: The sandbox also forbids process exit, environment inspection, system clocks, the standard random module, and all networking calls.

Each handler invocation receives a fixed amount of memory (10 MiB by default) and is metered in cycles and cells. Actor storage is persistent and subject to rent. This mechanism keeps full nodes compact and encourages efficient data lifecycle policies.

​

A New Security Model

The vast majority of wallet hacks in the Ethereum ecosystem are due to code audit bugs. While borrowing from the lessons of Ethereum, Solidity, and Bitcoin over the past decade, our new security model is simple: the code is easy to read. Python’s existing analysis and auditing tools, combined with Cowboy’s native guards and decorators, place it at a natural advantage when it comes to preventing on-chain attacks.

​

Storage and State Persistence

Cowboy’s storage architecture is designed for verifiability, performance, and cross-VM compatibility. It is built on a three-layer model:

1. The Ledger: An append-only log of blocks, serving as the sequential, historical source of truth for all transactions.
2. The Triedb: The canonical state repository, which uses a Merkle-Patricia Trie (MPT), similar to Ethereum, to generate a verifiable state_root for each block. This layer holds the authoritative state of all accounts, code, and storage.
3. Auxiliary Indexes: Rebuildable, read-optimized tables for data like transaction hashes or event topics. These indexes are derived from the Ledger and Triedb and allow for fast queries without being part of the consensus-critical state root.

This design ensures compatibility with existing MPT-based tooling while providing enhanced query performance.

​

Cross-VM Compatibility

To support both the native Python VM (PVM) and a future EVM execution environment, the state trie is designed to be VM-neutral.

• State Separation: A vm_ns (VM namespace) flag is embedded directly into storage keys. This allows PVM and EVM storage slots for the same address to coexist without collision, enabling a single actor address to have state in both environments.
• Cross-VM Calls: A standardized C-ABI (Application Binary Interface) wrapper is defined at the protocol level. This allows the storage layer to remain neutral while enabling seamless and predictable calls between the PVM and EVM.

All actor storage is subject to state rent, paid in CBY. This mechanism requires actors to pay for the storage they occupy over time, preventing state bloat and encouraging efficient data management. If rent is not paid, the storage may be pruned by the network after a grace period.

​

Pricing: Cycles and Cells

Ethereum introduced gas as a single scalar. Cowboy splits pricing into two independent meters:

• Cycles measure compute: Python operations and host calls (e.g., send, set‑timer, blob‑commit) each have a fixed cost. Cycles resemble Erlang reductions: a budget of discrete steps that bounds how long a handler runs.
• Cells measure bytes: calldata, return data, blobs, and storage all consume cells.

Each block adjusts two basefees (one per meter) using the familiar EIP‑1559 feedback loop. Users specify max prices and optional tips for each meter. Basefees are burned, while tips go to validators. This dual model makes fees more predictable and fair.

​

On-Chain Metering

To ensure deterministic execution, Cowboy’s on-chain resource consumption is metered with precision:

• Cycles: Computational work is metered by instrumenting the Python VM at the bytecode level. Every instruction has a fixed Cycle cost, defined in a consensus-critical cost table. This approach ensures that all computational paths, including loops and function calls, are accurately measured.
• Cells: Data and storage work is metered at specific I/O boundaries. Cells (where 1 Cell = 1 byte) are consumed for transaction payloads, return data, state storage (storage_set), and temporary scratch space used by an actor during execution.

This strict, deterministic metering is the primary defense against computational and state-based denial-of-service attacks.

​

Off-Chain Fee Model

It is critical to distinguish on-chain gas from off-chain job fees. The protocol does not calculate gas for Runner execution. Instead, it facilitates a free market where Runners set their own prices. A Runner’s operational costs (CPU time, memory, data transfer) determine its market price for a given job. Runners are free to ignore jobs they deem underpriced. This model allows for efficient price discovery for real-world resources and accommodates a wide range of computational tasks, from simple data fetching to intensive AI model inference, without burdening the on-chain consensus with non-deterministic and complex cost calculations.

​

Off-Chain Compute: The Runner Marketplace

Many applications need access to web data, ML inference, or heavy transforms. Any actor can post a job with a price and latency target. Runners—off‑chain workers who stake CBY—pick up jobs, execute them, and post results. This market is verifiable: the chain accepts results under various trust models chosen by the developer. Runners who lie or miss deadlines risk being challenged and slashed.

​

Asynchronous Task Framework and Runner Reliability

To ensure that off-chain computation does not impact the stability of the core network, Cowboy implements a fully asynchronous and deferred task framework. The lifecycle of an off-chain job is decoupled from the main transaction flow:

1. Task Submission: An actor submits a task by calling a dispatcher contract. The submission defines the task, the number of Runners required, and a result_schema that specifies the expected output format and constraints (e.g., max return size).
2. Runner Selection & Health: A committee of Runners is implicitly and deterministically selected for the task using a Verifiable Random Function (VRF). This selection is made from a dynamic active runner list. To remain on this list, Runners must periodically send a heartbeat() transaction, ensuring that tasks are only assigned to nodes that are proven to be online and responsive.
3. Execution and Submission: Selected Runners execute the task. If a Runner chooses not to perform the work, it can call a skip_task function, explicitly and verifiably passing responsibility to the next Runner in the deterministic sequence. Results are submitted to a dedicated contract.
4. Deferred Callback: Once the required number of results are collected, the system constructs and signs a deferred transaction. This transaction, which contains the call to the original actor’s callback function, is then executed in a future block.

This deferred model ensures that even long-running off-chain jobs or network delays do not congest the primary execution of the chain. The mandatory result_schema provides clarity for Runners, while the health and skipping mechanisms create a robust and self-healing network of off-chain workers.

​

Cowboy’s Off-Chain Tiered Trust Model

Runners and actors are matched by their Entitlements, a framework for policy and security constraints (e.g., TEE-only, data residency).

​

Randomness

Each block derives a random beacon from the previous quorum certificate using a threshold BLS VRF. Actors can access this for fair committee sampling, lotteries, and games.

​

Consensus and Networking

Cowboy uses a HotStuff‑style proof‑of‑stake protocol with ~1‑second blocks and finality on commit. Validators rotate proposers using the randomness beacon, and votes are aggregated with BLS signatures. The network favors liveness while retaining BFT safety.

​

Data Availability and Blobs

Small outputs (≤ 64 KiB) are stored inline and paid for with cells. Larger artifacts MUST be stored as content‑addressed blobs (e.g., IPFS) with the multihash referenced on-chain.

​

Monetary Policy and Fees

The native asset is CBY. Cowboy launches with a genesis supply of 1 billion CBY and a declining issuance schedule to reward validators.

​

Inflation Schedule

Emission rate (decreasing over time):

• Year 1-2: 8% annual inflation
• Year 3-4: 5% annual inflation
• Year 5-6: 3% annual inflation
• Year 7-10: 2% annual inflation
• Year 10+: 1% terminal inflation

​

Fee Distribution

• Basefees (Cycles & Cells): 100% burned.
• Tips: Paid to block proposers.
• Off-Chain Job Payments: Flow to Runners, with a small percentage to the protocol treasury.

Because basefees are burned, the net supply may become deflationary if the chain is heavily used.

​

Governance and Upgrades

Early governance is conducted by a foundation multisig with a standard timelock, sunsetting into token‑weighted on‑chain governance. Upgrades are shipped as hot‑code upgrades, coordinated by governance.

​

Applications

Cowboy is designed for real‑world, autonomous workloads.

• AI Agents: Actors that call LLMs for planning or retrieval, with verifiable transcripts and bounded costs. A trading agent could, for example, scrape congressional stock disclosures, use an LLM to parse the trades, and autonomously execute a copy-trade.
• DeFi Automation: An agent that monitors an ETH/BTC pool and automatically rebalances it based on price deviations from a 7-day moving average, all without external keepers.
• Games: Per-tick logic with VRF randomness; blob assets stored off-chain but committed on-chain.
• Oracles: HTTP committees fetch data from allow‑listed domains with commit‑reveal and disputes.

​

Ethereum Interoperability

Interoperability is a foundational design goal. The same secp256k1 key can control both a Cowboy account and an EVM address, letting agents hold ETH and ERC-20s, bridge assets, and sign EIP-1559 transactions under tight policy guards enforced by entitlements. A canonical bridge will carry funds and calldata, while Cowboy actors can subscribe to Ethereum events to trigger on-chain workflows.

​

The State Transition Function

At the heart of Cowboy lies a deterministic state transition function that takes a block and an input state and returns the next state. Let σ be the global state, B a block with transactions T_i, basefees (bf_c, bf_b), and randomness R.

1. Header/Proposer: determined by HotStuff; R derives from the parent QC.
2. Execute Transactions (ordered):
   • Validate signature, nonce, and balance.
   • Initialize meters with user limits; charge intrinsic cells.
   • Dispatch to target. Actor may send messages (fanout ≤ 1,024), schedule timers, and commit blobs; reentrancy depth ≤ 32.
   • Enforce memory (10 MiB), mailbox (≤ 1,000,000), and storage quotas.
   • Deduct fees: cycles_used*(bf_c+tip_c) + cells_used*(bf_b+tip_b); burn basefees.
3. Deliver Timers: Inject due timers at height(B).
4. Resolve Jobs: Process commitments, reveals, challenges, and payouts.
5. Adjust Basefees: Update (bf_c, bf_b) via EIP-1559 feedback.
6. Mint Rewards: Distribute per-block inflation to validators.

A single reference implementation defines the canonical metering table for cycles.

​

Terminology

• Actor: A Python program with persistent key/value state and a mailbox.
• Message: A datagram delivered to an actor handler.
• Cycle: Unit of metered on‑chain compute.
• Cell: Unit of metered bytes (1 cell = 1 byte).
• Runner: Off‑chain worker that executes a job and returns an attested result.
• Entitlement: A permission governing an actor’s or runner’s capabilities.
• Model: A registry entry describing an off-chain compute model’s digest and metadata.

​

Normative Conventions

This document uses MUST/SHOULD/MAY as defined in RFC 2119. Parameters marked governance‑tunable can be changed by on‑chain governance (see §11).

​

1. Accounts, Addresses, and Keys

1.1 Signatures. External accounts MUST use secp256k1 (ECDSA) with chain‑id separation. 1.2 Actor address derivation (CREATE2‑style). New actor addresses MUST be: addr = last_20_bytes(keccak256(creator || salt || code_hash)) where code_hash = keccak256(python_source_bytes). 1.3 System address space. The range 0x0000…0100 is reserved for system actors and precompiles (see §10).

​

2. Transaction Types & Encoding

2.1 Typed tx (EIP‑1559 style, dual meters). A transaction MUST include: chain_id, nonce, to, value, cycles_limit, cells_limit, max_fee_per_cycle, max_fee_per_cell, tip_per_cycle, tip_per_cell, access_list?, payload, signature. 2.2 Validity checks. Nodes MUST reject a tx if: (a) limits exceed maxima (§13.1), (b) insufficient balance, (c) signature invalid, (d) access list invalid, or (e) payload decoding fails. 2.3 Fee accounting. Let bc, bb be the block basefees for cycles/cells. Fees are: fee = cycles_used * (bc + min(tip_per_cycle, max_fee_per_cycle - bc)) + cells_used * (bb + min(tip_per_cell, max_fee_per_cell - bb)). Unused limits MUST be refunded at the user’s max_fee_* rates. 2.4 EBNF (informative). Tx = Header Body Sig Header = chain_id nonce to value cycles_limit cells_limit max_fee_per_cycle max_fee_per_cell tip_per_cycle tip_per_cell [access_list] Body = payload Sig = secp256k1_signature_recoverable

​

3. Execution Model (Actors)

3.1 Runtime & Determinism.

• Official SDKs: Python SDK. The runtime MUST enforce determinism:
  • Allowed operations: Standard Python operations, file I/O limited to /tmp, cooperative yields via async/await.
  • Forbidden: sys.exit(), random module (except chain VRF), time.time()/datetime.now(), os.environ access, socket/network operations, subprocess calls, path traversal outside /tmp.
  • Floating point: Permitted; Cowboy provides a deterministic math library.
  • Scratch space: /tmp MUST be per‑invocation, capped at 256 KiB (counts toward cells_used), wiped post‑handler.

3.2 Memory & Storage.

• Per‑call memory limit: 10 MiB heap memory.
• Per‑actor persistent storage quota: 1 MiB (governance‑tunable) with state rent (§4.4).
• Quota extensions: An actor MAY post a storage bond up to 8 MiB total; rent applies to the full allocated quota.

3.3 Messaging, Reentrancy, Timers.

• Delivery: Exactly‑once. Each message ID MUST be keccak256(sender||nonce||msg_hash) and recorded in a per‑actor dedup set.
• Mailbox: Capacity 1,000,000 items; enqueue beyond the limit MUST revert.
• Per‑tx fanout: A transaction (including all nested sends) MUST NOT enqueue more than 1,024 messages.
• Reentrancy: Allowed; recursion/await depth cap = 32.
• Timers (chain‑native): set_timeout(height) and set_interval(every_blocks) are provided. Delivery is best‑effort.

3.4 Randomness.

• Validators MUST generate a threshold‑BLS VRF per block: R_n = VRF_sk_epoch(QC_{n-1}). Actors MAY call an API which returns HKDF(R_n, label).

3.5 Partial cost table (informative).

• Exact metering is consensus‑critical; implementers MUST match the reference cost table.

Note: Cells meter bytes (payload, return data, inline blobs ≤ 64 KiB, /tmp).

​

4. Fees, Metering, and Basefee Adjustment

4.1 Meters.

• Cycles: Deterministic step count over Python operations + host calls.
• Cells: Bytes used by calldata, return data, inline blobs (≤ 64 KiB), and /tmp.

4.2 Dual EIP‑1559 basefees. Let U_c, T_c be cycles usage/target; U_b, T_b be cells usage/target. With elasticity E=2 (hard cap E*T_*), adjustment uses: basefee_{x,i+1} = max(1, basefee_{x,i} * (1 + clamp((U_x - T_x)/(T_x*alpha), -delta, +delta))) where x ∈ {cycle, cell}, alpha = 8, delta = 0.125. Nodes MUST burn 100% of basefees; tips go to proposers/validators. 4.3 Targets (genesis defaults).

• T_c (cycles target): 10,000,000 cycles (cap 20,000,000).
• T_b (cells target): 500,000 bytes (cap 1,000,000).

4.4 State rent. Persistent storage incurs rent per byte per epoch, which is governance-tunable. If unpaid for 90 epochs, keys MAY be pruned after a 30‑epoch grace period.

​

5. Off‑Chain Compute

5.1 Model registry. model_id = keccak256(weights||arch||tokenizer||license) MUST uniquely identify a model revision. Publishing is permissionless with a refundable 1,000 CBY deposit. Governance MAY flag/ban models. 5.2 Runner staking. Runners MUST stake max(10,000 CBY, 1.5 × declared_max_job_value) in the Runner Registry. 5.3 Job lifecycle.

1. Post: Actor posts a job with escrowed price.
2. Assign: For HTTP domains, a committee of M=5 is sampled; N=3 matching reveals finalize. LLM jobs MAY use committees or single-runner.
3. Commit: Runner returns commit = keccak256(output||salt).
4. Reveal: Runner reveals {output, salt, proof?}.
5. Challenge: A challenge window of 15 min is opened, requiring a 100 CBY bond.
6. Resolve: Proven fault ⇒ 30% slash of active stake (70% to challenger, 30% burned).
7. Payout: On finalization, 99% of job payment to runner(s), 1% to Treasury.

5.4 Determinism & bounds. Jobs MUST pin toolchain_digest and seed. On‑chain return data MUST be ≤ 64 KiB. 5.5 TEE option. A job MAY set tee_required=true. A valid attestation MUST match accepted policies.

​

6. Consensus, Randomness, and Networking

6.1 Consensus. HotStuff PoS; ~1s target block time; finality on commit. Proposers rotate using the VRF beacon. Votes aggregate via BLS12‑381. 6.2 P2P transport. Implementations MUST support QUIC over TLS 1.3. 6.3 Gossip (mempool). Public mempool with FIFO within fee tiers. No private builders or MEV separation in v1.

​

7. Data Availability & Blobs

7.1 Inline cap. Inline blob cap is 64 KiB per output. 7.2 External blobs. Larger data MUST be content‑addressed (e.g., IPFS). The on‑chain commitment MUST be a multihash.

​

8. Economics, Inflation, and Fees

8.1 Ticker & supply. CBY. Genesis supply 1,000,000,000 CBY. 8.2 Inflation. A decreasing inflation schedule is used to bootstrap network security.

• Year 1-2: 8% annual inflation
• Year 3-4: 5% annual inflation
• Year 5-6: 3% annual inflation
• Year 7-10: 2% annual inflation
• Year 10+: 1% terminal inflation

8.3 Distribution at genesis. Validators 25%, Treasury 25%, Ecosystem 30%, Investors 20% (standard vesting). 8.4 Fee sinks & splits. Basefees: 100% burned. Tips: to proposers/validators. Off‑chain job payments: 99% to runners, 1% to Treasury.

​

9. System Actors & Precompiles

• 0x01 Messaging: Enqueue and fanout messages.
• 0x02 Timers: Schedule/cancel timers.
• 0x03 Oracle/Runner: Manage off-chain jobs.
• 0x04 Blob store: Commit/retrieve blob multihashes.
• 0x05 Signer utils: secp/BLS/VRF helpers.

​

10. Developer Experience (DX)

• SDKs: A primary Python SDK (cowboy-py) is provided.
• Local dev: A suite of tools including a single-node devnet (cowboyd), runner simulator, faucet, and explorer will be available.
• Best practices: Reentrancy guards, capability-scoped handles, and idempotent message handling are encouraged via the SDK.

​

11. Governance & Upgrades

• Model: Foundation 5‑of‑9 multisig sunsets after ~12 months to token‑weighted on‑chain governance.
• Timelocks: Standard actions 7 days; emergency fast‑track 6 hours.
• Upgrades: Hot‑code upgrades coordinated by governance.

​

12. Security Considerations

12.1 DoS limits (consensus‑enforced; governance‑tunable).

• max_tx_size = 128 KiB
• max_message_depth_per_tx = 32
• per_actor_per_block_cycles = 1,000,000 (burstable)

12.2 Runner safety. Slashing for equivocation or invalid results. Committees mitigate single‑runner faults. 12.3 Reentrancy. Allowed but depth‑capped; stdlib provides reentrancy guards. 12.4 Randomness bias. Threshold‑BLS VRF with epoch keys; actors derive sub‑randomness via HKDF. 12.5 State rent & eviction. Prevents state bloat; eviction windows protect liveness.

​

13. Parameters (Genesis Defaults)

Execution: memory_per_call = 10 MiB; storage_quota_per_actor = 1 MiB; reentrancy_depth = 32; fanout_per_tx = 1024. Fees: T_c = 10,000,000 cycles; T_b = 500,000 bytes; alpha = 8; delta = 0.125. Consensus: validators ≈ 100; epoch = 1 h; block_time = 1 s. Off‑chain: committee M = 5; threshold N = 3; challenge_window = 15 min; challenge_bond = 100 CBY; runner_stake_floor = 10,000 CBY. Economics: supply = 1,000,000,000; inflation follows the schedule in §8.2; basefee burn = 100%; job fee to treasury = 1%.

​

14. Differences vs. Ethereum

• Execution: Python actors vs. EVM contracts.
• Fees: Dual meters (cycles/cells) vs. single gas scalar.
• Timers: Native timers vs. external keepers.
• Off‑chain compute: Native verifiable market vs. external oracles.
• State: Rent with eviction vs. indefinite storage.

​

15. Entitlements

A declarative, composable permissions system governs the capabilities of actors and runners. Entitlements control access to resources like networking, storage, and execution parameters, enforcing least-privilege by default. The system is enforced at deployment time, by the scheduler, and at the VM syscall gate. 15.1 Goals

• Least privilege by default.
• Deterministic enforcement.
• Declarative & composable.
• Auditable on-chain.

15.2 Objects & lifecycle

• Actor Entitlements: Permissions the actor requires.
• Runner Entitlements: Capabilities the runner provides.

15.3 Rules

1. MUST: Actors require entitlements; runners provide them.
2. MUST: Scheduler matches only if requires ⊆ provides.
3. MUST: Syscalls fail if the corresponding entitlement is missing.
4. MUST: Child actors only inherit entitlements marked inheritable:true.

(For a full list of entitlements, refer to protocol specifications).

​

16. Ethereum Interoperability

Cowboy’s interoperability with Ethereum is a primary design goal, enabling seamless asset transfer and cross-chain communication. This is achieved through a combination of shared cryptographic primitives, a canonical bridge, and event subscription mechanisms. 16.1. Account Unification

• 16.1.1. Cowboy external accounts (EOAs) MUST use the same secp256k1 elliptic curve for signatures as Ethereum. This allows a single private key to control accounts on both networks, simplifying key management for users and agents.
• 16.1.2. An actor, through a host call, MAY verify an EIP-712 signed data structure against a given Ethereum address, enabling actors to validate off-chain authorizations from Ethereum users.

16.2. Canonical Bridge

• 16.2.1. A canonical, trust-minimized bridge contract deployed on both Cowboy and Ethereum SHALL facilitate the transfer of assets and arbitrary message data.
• 16.2.2. Asset Bridging:
  • 16.2.2.1. The bridge MUST support the locking of native ETH and ERC-20 tokens on Ethereum to mint a corresponding wrapped representation on Cowboy (wETH, wERC-20).
  • 16.2.2.2. Conversely, the bridge MUST support the burning of wrapped assets on Cowboy to unlock the corresponding native assets on Ethereum.
  • 16.2.2.3. Bridge operations SHALL be secured by a committee of validators running light clients of the counterparty chain, with security bonds slashable on-chain for malicious behavior.
• 16.2.3. Generic Message Passing:
  • 16.2.3.1. The bridge protocol MUST allow a transaction on one chain to trigger a corresponding message call to a designated recipient actor/contract on the other.
  • 16.2.3.2. The payload of a cross-chain message MUST be included in the event logs of the source chain’s bridge contract, which the destination chain’s bridge validators can verify.

16.3. Event Subscription (Ethereum -> Cowboy)

• 16.3.1. Cowboy actors MAY subscribe to event logs emitted by specific contracts on the Ethereum blockchain.
• 16.3.2. A system actor on Cowboy, 0x06 EventListener, SHALL manage these subscriptions. This actor relies on the bridge validator set to act as a decentralized oracle, monitoring the Ethereum chain for specified events.
• 16.3.3. When a subscribed event is confirmed (i.e., finalized on Ethereum), the EventListener actor MUST enqueue a message to the subscribing Cowboy actor, delivering the event’s topic and data as the message payload.
• 16.3.4. The cost of this subscription service SHALL be paid by the actor in CBY, covering the gas fees incurred by the oracle validators on Ethereum.

16.4. Policy and Security

• 16.4.1. All interoperability functions available to an actor, such as bridge_asset or subscribe_event, MUST be governed by the Entitlements system (§15).
• 16.4.2. An actor’s deployment manifest MUST declare the specific Ethereum contracts it is permitted to interact with and the types of assets it is allowed to bridge, enforcing the principle of least privilege.

End of specification.