Cowboy: Design Decisions Overview


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

Note: This document explains the “why” behind Cowboy’s architecture. For complete technical specifications, see the Technical Whitepaper, the Storage Whitepaper, and the Secrets Whitepaper. This Markdown file is authoritative; the committed PDF is a point-in-time rendering of it.

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 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 — LLM inference, web requests, MCP tool calls, or containerized batch jobs — Cowboy integrates a decentralized network of Runners who execute jobs and attest to results under selectable trust models: N-of-M consensus, TEEs, and ZK-proofs (planned). Beneath the chain sits an off-chain substrate that the chain governs but never touches on the data path: CBFS (the Cowboy File System) for encrypted, durable storage; CBSS (the Cowboy Secret Service) for threshold-encrypted secret release; and CBQS (the Cowboy Queue System, planned) for durable, end-to-end-encrypted coordination between off-chain workloads. Together these let developers build two kinds of applications on one platform: consensus applications, where every state transition is public and verifiable, and sovereign applications, where users own their data, keys, models, and compute — and the chain serves as the authority record rather than the data plane. 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 Simplex BFT consensus with proof‑of‑stake, fast finality, and mandatory proposer rotation. 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. There is a second failure, just as fundamental: today’s AI applications are tenants, not owners. The models belong to a provider, the compute belongs to a cloud, the data sits in someone else’s bucket, and the credentials live in someone else’s vault. An agent built this way can be deplatformed, repriced, or read by any of the parties it rents from. Intelligence without ownership is not agency.

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 — and a set of chain-governed off-chain services (CBFS, CBSS, CBQS) that give applications durable storage, secrets, and coordination without surrendering ownership to any single operator. This document explains the architectural decisions and trade-offs that shape Cowboy’s design.

Key Innovations in Cowboy

General‑purpose chains struggle with data‑hungry, latency‑sensitive apps. Cowboy makes actors and verifiable off‑chain compute native through five 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 — LLM inference, HTTP fetches, MCP tool calls, custom compute, and container batch jobs — with selectable trust models, including N-of-M consensus, TEE attestations, and ZK-proofs (planned). Anyone can bring compute; anyone can bring models.
A Sovereign Off-Chain Substrate: CBFS (encrypted storage), CBSS (threshold secrets), and CBQS (encrypted queues, planned) share one architectural pattern — the chain is the control plane, an off-chain provider network is the data plane, and no data-path operation costs a transaction.
Dual-Metered Gas: Independent pricing and EIP-1559-style fee markets for compute (Cycles) and data/storage (Cells) to ensure fair and predictable costs.

Two Ways to Build

Cowboy’s subsystems exist to serve two distinct application shapes. Most real applications blend them, but the design decisions in this document are easiest to understand against these two poles.

Consensus Applications

The first shape is the classic one: the application’s value comes from public, verifiable state transitions. A trading agent, a DeFi rebalancer, an oracle committee, an on-chain game — for these, the actor’s on-chain state is the application, and off-chain compute is an input to it. The actor reads its state, dispatches a runner job (an LLM analysis, a price fetch), receives the result under a chosen trust model, and commits a decision that anyone can audit. The chain’s job is to make the link between inputs, execution, and outputs verifiable. Everything in Cowboy’s consensus core — deterministic Python execution, single-block atomicity, native timers, dual-metered gas, VRF ordering — is in service of this shape.

Sovereign Applications

The second shape is newer, and it is the reason the substrate below the chain exists. A hosted agent workspace, a personal AI with years of memory, a team of cooperating agents running a business — these applications are mostly data plane: gigabytes of documents and embeddings, credentials for a dozen outside services, high-frequency message traffic between workers. Almost none of that belongs in consensus state, and none of it should be readable by a platform operator. For these, the visible on-chain actor is the tip of an iceberg. Below the waterline sit CBFS volumes holding the application’s data, CBSS policies guarding its secrets, CBQS streams carrying its internal traffic, and runners supplying its compute. The chain’s job changes: it is no longer the data plane but the authority record — who owns each volume, which actor may read which secret, which provider serves which stream, who gets paid, and what happened. Every authority question resolves on-chain; content stays off-chain, and private content is encrypted under keys the chain never holds. We call these applications sovereign because the ownership stack has no landlord. The user’s account owns the data (client-side encrypted in CBFS), the credentials (threshold-wrapped in CBSS), the coordination fabric (CBQS streams it can re-home to another provider), and — where it matters — the models and the compute (see Bring Your Own Compute below). Any individual provider — a storage relay, a secrets proxy, a queue broker, a runner — is replaceable without the application losing its identity, its data, or its history. Hosted products like Homestead are built this way: the host operates infrastructure, but the tenant holds the keys. The rest of this document walks through the design decisions behind both halves: the consensus core first, then the marketplace and substrate that make sovereign applications possible.

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. The choice of Python reflects a pragmatic trade-off: we prioritize developer accessibility and ecosystem richness over the theoretical performance advantages of lower-level languages. The vast majority of AI tooling, data science libraries, and enterprise software is built in Python. By bringing Python on-chain, Cowboy dramatically lowers the barrier to entry for autonomous agent development.

The Actor Model

Cowboy’s core execution model is based on the actor model, a paradigm that naturally fits autonomous, asynchronous systems.

Why Actors?

The actor model provides several key advantages for autonomous agents:

Natural Asynchrony: Actors communicate via asynchronous messages, matching the real-world behavior of autonomous systems that interact with external services, wait for responses, and operate on independent schedules.
Encapsulation: Each actor has private state that can only be modified through message handlers. This provides strong isolation and prevents many classes of bugs common in shared-state systems.
Composability: Complex systems emerge from simple actors sending messages to each other. This modularity makes it easier to reason about, test, and audit autonomous systems.
Autonomy: Actors can schedule their own execution via timers, enabling true autonomy without external keeper networks.

Single-Block Atomicity

Cowboy provides atomicity only within a single block. When an actor’s message handler executes, all state reads, writes, and outbound messages within that handler are atomic — they either all commit or all revert. There is no cross-block atomicity: providing it would require either global locks (destroying parallelism and creating deadlock vectors) or speculative execution with rollbacks (creating griefing opportunities and unpredictable costs). Both would let an adversary exploit or grief the interval between blocks. Cowboy explicitly rejects these approaches. The consequence for developers: when a handler waits on an off-chain result, the continuation runs later, against potentially different world state, and must re-validate its assumptions. Cowboy makes this boundary explicit rather than hiding it.

Awaiting Off-Chain Work

The SDK surfaces the boundary as ordinary async/await. A handler that needs off-chain work awaits it; the runtime suspends the handler, the runner executes, and the continuation resumes in a later block as its own atomic transaction. Context that must survive the gap is captured explicitly. From examples/core/09-runner-llm (trimmed):

from cowboy_sdk import actor, runner, capture, codec, runtime

@actor
class RunnerLLMActor:

    @runner.continuation
    async def ask_llm(self, payload):
        obj = codec.decode(payload) if payload else {}
        prompt = str(obj.get("prompt", ""))
        request_id = self.storage.get("request_count", 0)
        self.storage["request_count"] = request_id + 1
        self.storage[f"llm:{request_id}:status"] = "pending"

        ctx = capture()              # context that must cross the block boundary
        ctx.request_id = request_id

        result = await runner.llm(   # suspends; resumes in a later block
            prompt,
            system_prompt=SYSTEM_PROMPT,
            max_tokens=256,
        )

        request_id = ctx.request_id  # restored from captured context
        self.storage[f"llm:{request_id}:response"] = _extract_llm_response(result)
        self.storage[f"llm:{request_id}:status"] = "done"
        runtime.emit_event("llm.response", {"request_id": request_id})

Three principles hide in this small example:

No hidden control flow. The await desugars to explicit message passing — a job message out, a result message back in, each its own on-chain transaction. Nothing is a closure held in memory; execution can be traced block by block.
Explicit context capture. Only what is written to capture() (or storage) crosses the boundary. There is no accidental closure over stale local variables — what survives the gap is a deliberate, visible choice.
Re-validation is the developer’s job. The continuation runs against current state. Code that acted on pre-await reads (a price, a balance) must re-read and re-check them — the model makes the staleness possible to see, and the pattern makes checking it natural.

The Runner system is not special syntax: it is a system actor that receives job requests and sends results. The same message-passing substrate carries actor-to-actor calls and timer callbacks.

Native Timers and Scheduling

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.

Why Protocol-Level Timers?

External keeper networks (like Ethereum’s Gelato or Chainlink Automation) introduce several problems:

Centralization Risk: Keepers are typically operated by a small number of entities, creating single points of failure.
Cost Inefficiency: Each keeper network requires separate infrastructure, payment mechanisms, and trust assumptions.
Coordination Overhead: Actors must integrate with external services, manage subscriptions, and handle keeper failures.
MEV (Maximal Extractable Value) Exposure: Keepers can observe scheduled transactions and potentially front-run them.

By making timers native to the protocol, Cowboy eliminates these issues while providing better guarantees and lower costs.

Scalable Design: Height-Indexed Storage

The scheduler stores timers indexed by their target block height, with the same-height bucket ordered FIFO by insertion. This keeps the per-block work proportional to the number of timers actually firing this block, not to the total active population, and avoids the operational complexity of a priority queue or tiered calendar. A separate LANE_TIMER_CYCLES budget (8,888,890 cycles ≈ 11% of the 80M block cap; ~22% of the 40M non-system lane total) is dedicated to timer execution, and a parallel TIMER_GC_CYCLES budget handles TTL-expiry cleanup so a sweep storm cannot starve live execution. A per-actor cap (max_timers_per_actor = 1,024) bounds individual exposure.

Economic Rationality: The Per-Fire Fee Payer Model

In the implemented v1 scheduler, each timer records fee_payer, gas_limit_per_fire, and expires_at. At the end of each block the protocol pre-charges max_cost = gas_limit_per_fire × cycle_basefee + max_cells × cell_basefee from the fee_payer, executes the handler, refunds unused gas, and removes the timer. Timers whose fee_payer cannot cover max_cost, or whose expires_at is reached, self-destruct without firing. A future EIP-1559 hybrid target design (activated via Tier-3 governance) layers a timer-lane basefee and a priority tip on top of this, plus a per-actor fairness weight W(actor) ∈ [1, 2] over a 1,000-block rolling window. The fairness weight gives a small inclusion boost to actors whose effective fire rate is below the network median, ensuring eventual execution under sustained bidding congestion without requiring exponential-decay state to be maintained off-block. This design enables sophisticated scheduling strategies: an actor (or a Gas Bidding Agent acting on its behalf) can adjust max_fee_per_cycle and max_priority_fee_per_cycle per timer based on urgency, network congestion, and balance.

Fairness and Liveness

Under the v1 mechanism, timers whose fee_payer cannot cover max_cost at fire time self-destruct rather than block the lane; well-funded timers always fire. Under the future EIP-1559 hybrid, the per-actor fairness weight described above is the explicit anti-starvation primitive — actors at or below the network-median fire rate get the maximum boost, actors at 2× median or above get none.

DoS Prevention Philosophy

The timer system is a potential vector for denial-of-service attacks. An adversary could attempt to schedule millions of timers at a single block height, overwhelming execution capacity, or fill the timer queue with spam to crowd out legitimate users. Cowboy employs multiple layers of defense:

Per-Actor Timer Limits: Each actor is limited to a maximum of 1,024 active timers at any time.
Progressive Deposit Model: Creating a timer requires a deposit that scales with the actor’s total active timer count, making large-scale timer spam prohibitively capital-intensive.
Same-Block Exponential Pricing: An exponential surcharge applies when an actor schedules multiple timers for the same block height, preventing “timer bomb” attacks.
Timer Queue Basefee: Similar to EIP-1559, a timer basefee adjusts based on global timer queue pressure, naturally throttling demand when the queue is congested.
Per-Block Execution Budget: Each block reserves a dedicated portion of its compute budget for timer execution, ensuring timer storms cannot completely crowd out regular transactions.

For complete technical details on these mechanisms, see the Technical Whitepaper.

Verifiable Off-Chain Compute

Not all computation belongs on-chain. LLM inference, web scraping, and complex data transformations are too expensive for consensus execution, too slow for a 1-second block, and often non-deterministic. Cowboy’s answer is a native marketplace of Runners — off-chain workers who stake CBY, publish rate cards, and execute jobs under verifiable trust models.

Job Lifecycle

The marketplace is not a bulletin board that runners scrape; it is a protocol-mediated dispatch pipeline:

Post: An actor submits a job with an escrowed max price, explicit resource bounds (tokens, wall time, memory), and a chosen trust model.
Assign: The protocol samples a committee of runners via stake-weighted VRF from the eligible set — staked, healthy, and whose advertised capabilities satisfy the job’s entitlements.
Commit / Reveal: Committee members return a hash commitment to their output, then reveal it — preventing copy-cheating within the committee.
Challenge: A bonded challenge window opens; proven dishonesty slashes stake, while operational failures cost reputation only.
Payout: 89% of the job payment goes to the runner(s), 10% is burned, and 1% funds the Treasury. Unused escrow returns to the actor.

Pricing is a free market: actual_payment = min(reported_usage × rates, max_price). The protocol deliberately does not meter off-chain execution with gas — deterministic on-chain metering and non-deterministic off-chain resource pricing are different problems, and conflating them (as single-gas-scalar designs must) makes both worse.

Trust Models

Developers choose the right balance of security and cost per job:

Mode	Level of Trust
N-of-M Quorum	Runners execute results; the runtime accepts the consensus result from a committee.
N-of-M with Dispute	Runners stake a bond; disputers may prove an incorrect result within a fixed window.
Structured Match	For tasks with well-defined output fields, verifier functions compare structured data rather than requiring byte-identical raw output.
Semantic Similarity	For subjective/LLM outputs, an N-of-M committee’s results are accepted if embedding-based similarity clears a threshold rather than requiring a byte-identical match.
TEE Attestation	An N-of-M committee or single runner executes the result within a Trusted Execution Environment.
ZK-Proof (planned)	Runners provide zk-SNARKs with results for cryptographic verification.

The LLM rows exist because LLM output is inherently non-deterministic: the same prompt produces semantically equivalent but byte-different outputs, so byte-exact quorum fails even at temperature 0. Structured matching, embedding similarity, and economic bonds recover verifiability for exactly the workloads agents care most about.

Bring Your Own Compute

Runner supply is permissionless by design: anyone with hardware can stake, register a rate card, declare capabilities, and start earning. This is not an operational detail — it is a load-bearing decision:

No privileged inference provider. If the platform operated the compute, every “autonomous” agent would have a landlord. A permissionless runner set means no single party can deplatform an agent, reprice it arbitrarily, or read its traffic as a condition of service.
Markets find the hardware. Idle GPUs, specialized accelerators, region-specific capacity, and consumer hardware all clear at their own prices through rate cards, instead of being flattened into one provider’s SKU list.
Capability matching replaces gatekeeping. The entitlements system matches jobs to runners on declared facts — supported models, TEE hardware, geographic region, network egress — so specialization is expressed in the protocol, not negotiated in a sales channel.
Own your stack end to end. An application with strict requirements can run its own runners — its compute joins the same marketplace, serves its own jobs, and remains verifiable and billable under the same protocol rules. Sovereignty is not a separate deployment mode; it is the marketplace used at N=1.

Bring Your Own Models

The same logic extends to model weights. Runners advertise which models they serve; nothing requires those models to be public:

Monetize without publishing. A model owner can serve a proprietary model from their own runners, price it on a rate card, and earn per-inference revenue — without the weights ever leaving machines they control. The chain verifies the service (commitments, committees, attestation) rather than the artifact.
Private weights as private data. Weights are data, and the substrate already handles private data: store them client-side encrypted in CBFS, gate the decryption key through CBSS so it releases only to an authorized runner for a dispatched job, and (where third-party hosting is desired) require TEE attestation so even the host machine’s operator never holds plaintext weights.
Why this matters: open-weight models commoditize; frontier and fine-tuned models are where economic value concentrates. A platform that can only serve public models cedes that entire economy to centralized APIs. Cowboy’s design lets model owners participate in a permissionless market while keeping the asset that makes them valuable.

The Sovereign Substrate

Consensus state is the wrong home for almost everything a real application accumulates: it is public by construction, priced for scarcity, and sized for kilobytes. Yet pushing that data to ordinary cloud services reintroduces exactly the landlord problem Cowboy exists to remove. The resolution is a family of chain-governed off-chain services sharing one architectural pattern:

The chain is the control plane. An off-chain provider network is the data plane. No data-path operation costs a transaction.

Ownership, authorization, provider registration, billing, and audit live on-chain, where they are permissionless and verifiable. Content lives off-chain; private content is encrypted under keys the chain never holds. Three services instantiate the pattern (CBFS and CBSS are live; CBQS is planned):

CBFS: Storage

What it is: A decentralized, erasure-coded object store operated by permissionless, staked Relay Nodes, mounted by accounts as private (client-side encrypted) or public volumes. The decisions behind it:

Separate state from storage. State is consensus-critical key/value data billed per cell and subject to rent. Storage is bulk data — agent memory, embeddings, artifacts, web assets — referenced on-chain only by compact manifest-root commitments. Ethereum fuses these; the fusion is why “put it on-chain” is a joke and “put it on S3” is a surrender.
Off-chain data plane. Reads and writes are client-to-relay RPCs authenticated by capability tokens; the chain is touched only at lifecycle boundaries (create, anchor, bill, repair, evict). An agent reading its memory thousands of times a day pays for storage, not for consensus.
Private by default, public by choice. Private volumes are encrypted client-side: relays store and serve ciphertext, and the protocol never asks storage operators to be trusted with private content — so the storage network can be permissionless without being a privacy hazard. Public volumes are deliberately plaintext and world-readable without a CapToken — that is what lets the gateway serve web assets and public datasets straight from relays. A volume’s visibility is chosen at creation and immutable thereafter.
Capability tokens over transactions. Scoped, signed CapTokens (volume, path prefix, mode, quota, expiry) grant access — chain-issued for runner mounts at job dispatch, client-signed via a delegation keypair for owner access. Cold wallet authority and hot data-path authority are deliberately separated.
Verifiable durability. Reed-Solomon shards across independent relays, on-chain Proof-of-Retrievability challenges, and slashing make durability an economic guarantee rather than a brand promise.

CBSS: Secrets

What it is: Threshold identity-based encryption (BLS12-381, the drand tlock construction) operated by a committee of staked proxies, releasing secrets just-in-time into the address space of the one runner authorized for a dispatched job. The decisions behind it:

Conditional plaintext release is the missing primitive. Chains make everything public; private rollups make everything available to whoever decrypts the rollup; off-chain vaults release plaintext against a bearer token with no link to on-chain reality. Agents need a third thing: release this secret only to whoever the chain says is doing this job — so Cowboy built it as infrastructure.
Thresholds, not hardware. Decryption requires t-of-n proxy cooperation; the trust root is non-collusion plus slashing. TEEs are available as an additional layer, not the foundation — a hardware vendor’s attestation keys should not be the root of every secret on the network.
Chain-derived authorization. Proxies validate each release request against current chain state: the actor’s manifest declares the secret, the job is real, the requesting runner is the one dispatched. Authorization is computed from the authority record, not from possession of a credential.
Actors hold zero secrets. An actor can operate authenticated integrations — Slack bots, payment webhooks, API clients — while its on-chain code and state contain nothing worth stealing. Compromising the actor’s public surface yields nothing; the secret exists in plaintext only inside an authorized runner, for one job’s duration.

CBSS is also the key-delivery layer for private CBFS volumes and provides time-lock release (encryption to a future block height), which the protocol reuses for sealed-bid auctions.

CBQS: Coordination

What it is: Durable, end-to-end-encrypted streams and queues for off-chain workloads — at-least-once delivery, replay, consumer groups, sub-second push — served by chain-registered broker providers. The decisions behind it:

Mailboxes are not a message bus. Actor mailboxes carry public, consensus-relevant state transitions at consensus speed and gas cost. Multi-agent applications also need high-frequency, private, durable transport between runner-hosted workloads — a coordinator fronting a chat surface, workers fanning out tasks. Before CBQS, every serious multi-agent build re-implemented persistence, retry, fan-out, cursors, and crash recovery on its own. Repeated reinvention of the same infrastructure is a signal the platform is missing a primitive.
Same pattern, third instance. A stream is created, owned, configured, billed, and re-homed by chain transaction; message flow is broker RPCs with zero chain writes. The provider network follows the CBFS relay pattern — registered, staked, replaceable.
Encrypted by default, honest about metadata. Stream contents are end-to-end encrypted; brokers and the chain never hold data keys. The design states its privacy claim precisely: the platform protects what you say, not the fact that you talk — stream records, release receipts, and broker connection metadata remain visible at their respective layers. Applications get a real guarantee instead of an implied one, and self-hosting the broker remains available for those who want traffic metadata private too.

Why the Iceberg Shape

Together, the substrate is what makes the sovereign application class possible, and each property traces to a specific decision:

Permissionless — every provider role (relay, proxy, broker, runner) is open entry with stake, and every consumer role needs no one’s approval, because authorization is computed from chain state rather than granted by an operator.
Private — private content is encrypted before it reaches any provider (private CBFS volumes, CBQS messages) and credentials are never plaintext anywhere except an authorized runner (CBSS), because the data plane was designed assuming providers are curious. Only content an owner explicitly marks public (a public volume) is ever provider-readable.
Sovereign — the account owns the volumes, the policies, the streams, and optionally the runners and models; providers are replaceable line items, because identity, authority, and history live in the one place no provider controls: the chain.

An application built this way — its data in volumes it owns, its credentials threshold-guarded, its internal traffic encrypted, its inference on compute it chose or operates, its model weights unpublished — is using sovereign AI: intelligence whose ownership stack terminates at the user, with the chain as notary rather than landlord.

Dual-Metered Gas

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.

Why Separate Meters?

Separating compute and data pricing provides several benefits:

Fair Pricing: A transaction that processes large amounts of data but does little computation pays for data, not computation. Conversely, a compute-intensive transaction pays for cycles, not data.
Predictable Costs: Developers can reason about costs independently: “This operation will cost X cycles and Y cells” rather than trying to understand how a single gas scalar maps to both dimensions.
Better Resource Management: The protocol can adjust pricing for compute and storage independently based on network conditions. If storage is scarce but compute is abundant, cell basefees rise while cycle basefees fall.
EIP-1559 Benefits: Each meter gets its own EIP-1559-style fee market, providing the same predictability and fee burning benefits that Ethereum users enjoy, but applied to both dimensions.

Consensus Philosophy

Cowboy uses Simplex BFT consensus, a streamlined Byzantine Fault Tolerant protocol chosen for three key properties:

Why Simplex?

Simplicity: Simplex achieves consensus with optimal latency while maintaining a simple design and provable liveness. Fewer moving parts means fewer bugs and easier auditing, which is critical for a system managing autonomous agents and financial assets.
Mandatory Proposer Rotation: Unlike stable-leader protocols (like PBFT) where one validator might propose many consecutive blocks, Simplex rotates proposers every block via a Verifiable Random Function (VRF). This is a deliberate MEV mitigation strategy—no single proposer observes transaction flow across multiple blocks, fundamentally limiting cross-block MEV extraction.
Fast Finality: With ~1 second blocks and ~2 second finality, Cowboy enables autonomous agents to act on confirmed state quickly. This is critical for time-sensitive operations like trading, arbitrage, and cross-chain interactions.

MEV Resistance Through Design

Cowboy takes a multi-layered approach to MEV mitigation:

VRF-Based Transaction Ordering: Within each block, transactions are ordered deterministically using VRF. Proposers cannot strategically place their own transactions.
Dedicated Lanes: Block space is partitioned into reserved lanes for system operations, timers, and runner results. Attackers cannot spam the mempool to delay victim transactions.
No Encrypted Mempool: Given the ~2s finality and VRF ordering, the observation window for front-running is already minimal. The marginal benefit of encryption doesn’t justify the latency cost.

For complete consensus specifications, see the Technical Whitepaper.

Economic Model

Cowboy’s economic design aligns incentives across validators, runners, and actors:

Deflationary Pressure

All basefees (for both Cycles and Cells) are burned, creating deflationary pressure that scales with network usage. This ensures that heavy usage benefits all token holders, not just block producers.

Validator Rewards

Block Inflation: Validators receive rewards from a declining gross-inflation schedule on a fixed genesis supply of 1,000,000,000 CBY: 8%/6% in the bootstrap years, 4%/3% on the glidepath, and a 2% floor at steady state. Gross inflation is offset by protocol burns, so net inflation depends on network usage.
Tips: Proposers receive transaction tips, incentivizing efficient block production.
Conservative Slashing: Most offenses result in jailing (temporary removal) rather than stake destruction. This encourages validator participation while still removing bad actors.

Runner Marketplace

Off-chain compute is priced via a free market:

Runners set their own rates via on-chain rate cards
Jobs are matched to runners based on price, capabilities, and entitlements
Economic bonds and reputation systems align incentives for honest execution
Each job settlement pays 89% to runners, burns 10%, and sends 1% to the Treasury — the runner fee burn is the primary deflationary mechanism beyond basefee burns, scaling supply reduction with real usage

State Rent

Persistent storage incurs ongoing rent, preventing state bloat and encouraging efficient data lifecycle management. Actors who don’t pay rent enter a grace period, then have storage evicted (but can restore it if data is preserved). Off-chain CBFS storage is billed separately — per MiB per epoch, in its own market — keeping bulk data costs out of the consensus fee markets.

USD-Denominated Billing

Agents and their users should not need to hold a volatile asset to buy inference. Billing can be denominated in CUSD, a fiat-backed, transfer-restricted USD credit built on the standard fungible-token transfer hook and settled through the payment layer, while gas remains invisible to the end user. This keeps the commercial product surface in stable units without changing any tokenomic rule: CBY remains the protocol’s staking, gas, and burn asset.

The Agent Service Layer

Beyond the core execution engine and the sovereign substrate, Cowboy ships agent-facing platform capabilities as governance-controlled system actors at reserved addresses rather than as privileged user-space contracts or off-protocol services. This is a deliberate pattern: each capability gets a well-known address, an auditable on-chain interface, and a governance-controlled upgrade path, while the base consensus rules stay small. No third-party contract holds protocol privileges. The service layer includes:

Gateway & Naming: Actors are reachable over plain HTTP. A gateway tier renders actor-served UIs and assets from public CBFS volumes, a route registry binds DNS names to actors, and MCP ingress lets AI clients call actors as tools. Agents get a web presence without running servers.
Payments: HTTP-native payment settlement for the machine-payable web: multiple wire formats (MPP, x402) normalize to one on-chain settlement layer, with session escrow and cumulative vouchers for streaming and metered usage. Agents can charge for services — and pay for them — without a human in the loop.
Actor Hiring & Distribution: The Trading Post provides store-neutral rails for hiring actors: hireable declarations, declared fee splits, review attestations bound to exact code snapshots, and private-code access enforced through CBSS key leases. Any party may operate a store; no store — including Cowboy Labs’ own — holds protocol privileges, and direct hiring with no store in the loop is a first-class path.
Container Registry: OCI container jobs execute against an on-chain base-image allowlist with declared resource classes, giving off-chain batch compute supply-chain integrity and priced, escrowed settlement.
Intent Settlement: Conservation-checked, atomic settlement of signed token diffs, used for in-chain swaps and as the anchor for cross-chain flows (see Ethereum Interoperability below).

Entitlements: Least-Privilege by Default

Cowboy implements a declarative permissions system called Entitlements that governs actor and runner capabilities. This system is fundamental to Cowboy’s security model. Entitlements enforce least-privilege by default:

Actors declare requirements: What permissions they need (HTTP domains, TEE access, storage quotas)
Runners advertise capabilities: What they can provide (supported models, geographic regions, TEE hardware)
Scheduler enforces matching: Jobs only run on runners where requires ⊆ provides
Syscalls are gated: Operations fail if the actor lacks the corresponding entitlement

This creates an auditable, on-chain permission manifest for every actor. Users can inspect exactly what an actor can do before interacting with it. For the complete entitlements specification, see the Technical Whitepaper.

Why a Sovereign L1

A natural question arises: why build Cowboy as a sovereign Layer-1 rather than as an Ethereum Layer-2 (rollup), which would inherit Ethereum’s security and liquidity?

L2 Constraints

Ethereum L2s come in two primary flavors, neither of which fits Cowboy’s requirements: Optimistic Rollups:

7-day withdrawal delay for fraud proof windows
Agents needing fast liquidity access would be severely constrained
Sequencer centralization creates MEV and censorship risks

ZK Rollups:

Require execution to be provable in zero-knowledge circuits
Python is not circuit-friendly; the PVM would need complete reimplementation
Proving costs for complex actor logic would be prohibitive
Current ZK-EVM projects took years and billions in funding for EVM alone

Both approaches inherit EVM execution constraints or require building within them, forcing Cowboy to either abandon Python or build an entirely separate proving system.

Execution Model Incompatibilities

Beyond the VM and proving constraints, Cowboy requires execution primitives that don’t exist in Ethereum’s model: Scheduled Future Execution Actors need to schedule work at specific future block heights. The EVM has no native concept of “execute this code at block N”—it only processes transactions submitted to the mempool. On Ethereum, scheduled execution requires external keeper networks (Gelato, Chainlink Automation) that add cost, latency, trust assumptions, and failure modes. Cowboy’s native timers are protocol-level primitives that the chain itself executes. Actor-Aware Block Building Ethereum block builders optimize for MEV extraction and tip maximization. Cowboy’s block proposers must understand a fundamentally different priority: some actors have timers that are overdue and must run soon. The protocol tracks which timers have been deferred, applies anti-starvation boosts, and reserves dedicated block space for timer execution. This actor-aware scheduling cannot be retrofitted onto an EVM-based L2. Guaranteed Execution Lanes Cowboy partitions block space into dedicated lanes (system, timer, runner, user) with reserved capacity. A surge in user transactions cannot crowd out timer executions or runner result submissions. Ethereum’s single-lane block model provides no such guarantees—during congestion, any transaction type competes equally for inclusion. Storage Lifecycle Management Ethereum’s “pay once, store forever” model doesn’t fit an actor-based system where agents may become dormant. Cowboy’s state rent model—with grace periods, eviction, and restoration—requires protocol-level enforcement that an L2 inheriting EVM storage semantics cannot provide.

Why L1 Enables Cowboy’s Design

Capability	L1 (Sovereign)	L2 (Rollup)
Custom VM	Native PVM with Python	Constrained to EVM or custom ZK circuit
Scheduled execution	Protocol-native timers with guaranteed inclusion	External keepers, no execution guarantees
Block building	Actor-aware with anti-starvation, dedicated lanes	MEV-optimized, single priority dimension
Block time	Full control (1s target)	Bound by L1 finality for settlement
Consensus	Simplex with VRF ordering, lane isolation	Inherit sequencer model or Ethereum constraints
Runner integration	Deep protocol integration with verification modes	Separate oracle infrastructure per capability
Storage model	State rent with eviction and restoration	EVM “pay once, store forever” semantics
Upgrade path	Sovereign governance	Depends on rollup framework and L1 upgrades

The Trade-off

Sovereignty comes with costs:

Bridge risk: Cross-chain asset transfers require trust assumptions beyond Ethereum’s security
Liquidity fragmentation: Assets on Cowboy are not natively composable with Ethereum DeFi
Validator bootstrapping: Must attract sufficient stake for economic security

Cowboy accepts these trade-offs because the alternative—forcing autonomous Python agents into EVM constraints or waiting years for ZK-Python infrastructure—would compromise the core value proposition. Cross-chain risk is mitigated by keeping bridge selection in governance (the protocol maintains no bridge validator set of its own), rate-limiting corridors, and settling cross-chain flows through conservation-checked intents rather than freeform bridge calls.

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. The protocol does not ship its own bridge validator set — instead, governance selects third-party bridge infrastructure to carry funds and calldata, and exposes the integration to actors through the bridge.asset and bridge.subscribe_event entitlements. Cowboy actors can subscribe to Ethereum events to trigger on-chain workflows once an EventListener system actor (deferred, address to be assigned) is in place. This interoperability design recognizes that Cowboy and Ethereum serve complementary roles: Ethereum provides liquidity and security for high-value assets, while Cowboy provides the execution environment for autonomous agents. The chosen bridge enables agents to leverage both ecosystems without forcing the protocol to maintain validator sets it does not control.

Intent-Based Settlement

Above the bridge layer, Cowboy adopts an intent-based model for exchange and cross-chain flows. An account signs a declarative token diff — “I give up exactly X of token A; I want at least Y of token B” — and off-chain solvers (Runners) compete to fill it. An on-chain Settlement system actor applies matched intents atomically, only if the bundle conserves value: no token can be created by settlement, regardless of what solvers or backends do off-chain. Two decisions distinguish this design:

Sealed-bid solver auctions: Solver competition can run as a sealed auction using CBSS time-lock encryption — bids are encrypted to a future block height and revealed permissionlessly after it passes. This eliminates last-look and bid-sniping, a fairness property open solver markets do not provide.
Pluggable corridor backends: Cross-chain legs go through a uniform settlement interface with governance-selected backends per corridor — the native bridge, ERC-7683/Open Intents adapters for EVM corridors, or NEAR Intents for BTC and non-EVM reach. No standard is treated as a liquidity source: external liquidity always comes from solvers fronting capital over a rail they trust, and the settlement core depends on none of them.

For complete technical specifications on the bridge and interoperability mechanisms, see the Technical Whitepaper.

Security Philosophy

Cowboy’s security model prioritizes simplicity and auditability:

Readable Code: 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.
Explicit Semantics: The message-passing model makes execution flow explicit and traceable.
Economic Security: Staking, slashing, and fee mechanisms align incentives and penalize malicious behavior.
Least Privilege: The Entitlements system enforces least-privilege access by default.
Curious-Provider Threat Model: The off-chain substrate assumes every provider — relay, proxy, broker, runner host — may inspect what it holds. Client-side encryption, threshold release, and attestation exist so that assumption costs applications nothing.

For complete security specifications and considerations, see the Technical Whitepaper.

Applications

The two application shapes from the start of this document map onto everything above:

Consensus applications — trading agents, DeFi automation, oracle committees, on-chain games — build on deterministic actors, native timers, and verifiable runner calls, with every decision auditable on-chain.
Sovereign applications — hosted agent workspaces, personal AI with durable memory, multi-agent businesses, private-model inference services — build on the substrate: data in owned CBFS volumes, credentials in CBSS, coordination over CBQS, compute and models supplied by (or as) permissionless runners, with the chain holding the authority record.

Most production systems are both at once: a hireable agent whose commerce, hiring, and attestations are consensus-visible, and whose memory, credentials, and internal traffic are sovereign. Cowboy provides the missing infrastructure for each half — and one platform for the whole.

For complete technical specifications, parameters, and implementation details, see the Technical Whitepaper.

​Cowboy: Design Decisions Overview

​Abstract

​Introduction

​The Problem: A Chasm Between Intelligence and Agency

​The Solution: Cowboy

​Key Innovations in Cowboy

​Two Ways to Build

​Consensus Applications

​Sovereign Applications

​Why Python?

​The Actor Model

​Why Actors?

​Single-Block Atomicity

​Awaiting Off-Chain Work

​Native Timers and Scheduling

​Why Protocol-Level Timers?

​Scalable Design: Height-Indexed Storage

​Economic Rationality: The Per-Fire Fee Payer Model

​Fairness and Liveness

​DoS Prevention Philosophy

​Verifiable Off-Chain Compute

​Job Lifecycle

​Trust Models

​Bring Your Own Compute

​Bring Your Own Models

​The Sovereign Substrate

​CBFS: Storage

​CBSS: Secrets

​CBQS: Coordination

​Why the Iceberg Shape

​Dual-Metered Gas

​Why Separate Meters?

​Consensus Philosophy

​Why Simplex?

​MEV Resistance Through Design

​Economic Model

​Deflationary Pressure

​Validator Rewards

​Runner Marketplace

​State Rent

​USD-Denominated Billing

​The Agent Service Layer

​Entitlements: Least-Privilege by Default

​Why a Sovereign L1

​L2 Constraints

​Execution Model Incompatibilities

​Why L1 Enables Cowboy’s Design

​The Trade-off

​Ethereum Interoperability

​Intent-Based Settlement

​Security Philosophy

​Applications