Skip to main content

Ethereum Interoperability: Technical Integration Guide

Overview

Cowboy is designed for clever interoperability with Ethereum, not reimplementation. Rather than duplicating Ethereum’s extensive standards (ERC-721, ERC-1155, etc.), Cowboy actors orchestrate and interact with existing Ethereum assets while providing unique capabilities: autonomous execution via timers (CIP-1), AI/heavy compute via off-chain runners (CIP-2), and a Python-native developer experience. This document outlines the technical architecture for Ethereum-Cowboy interoperability.

Design Principles

  1. No Duplication: Don’t reimplement what Ethereum does well (NFT standards, DeFi primitives)
  2. Leverage CIP-2: Use existing off-chain compute infrastructure for Ethereum integration
  3. Progressive Decentralization: Start simple, add trust-minimization over time
  4. Developer-First: Python-native APIs for Ethereum interaction
  5. Composability: Cowboy actors orchestrate Ethereum assets with autonomous behavior

Use Case Performance Analysis

To evaluate the architecture options, let’s analyze three critical use cases:

Use Case 1: Real-time Event Monitoring

Scenario: Actor wants to react when a specific Ethereum wallet receives a USDC transfer Winner: Option 4 (Hybrid) with fast path = ~20 seconds Implementation example:

Use Case 2: Transfer Balance Between Ethereum and Cowboy

Scenario: User has 10 ETH in MetaMask, wants to move 5 ETH to Cowboy actor Winner: Option 4 (Hybrid) = ~40-45 seconds both directions Implementation example:

Use Case 3: MetaMask Integration

Scenario: User signs Cowboy transaction with MetaMask without requiring MetaMask to implement a new protocol Key Insight: This is independent of the Ethereum interop architecture! It’s about wallet UX and cryptographic compatibility. Solution: Cowboy uses the same cryptography as Ethereum:
  • Same elliptic curve: secp256k1 (ECDSA)
  • Same address format: keccak256(pubkey)[12:]
  • Same signature format: (r, s, v) tuples
  • Result: Ethereum addresses work natively on Cowboy!
MetaMask signs Cowboy transactions via EIP-712 structured data:
Cowboy validators verify the signature:
User Experience:
  1. User visits Cowboy dApp
  2. Clicks “Connect Wallet” → MetaMask popup (familiar!)
  3. MetaMask shows: “Cowboy wants to connect to 0x742d35Cc…”
  4. User signs transaction → familiar EIP-712 popup
  5. Transaction submitted to Cowboy network
  6. No MetaMask changes required!
Winner: Works with ALL architecture options via EIP-712 structured signing

Recommendation Summary

Based on the three use cases: Overall Winner: Option 4 (Hybrid Approach)
  • Start with CIP-2 oracle consensus (fast, ~20-45 seconds)
  • Add light client proofs for high-value operations (trustless, ~15 minutes)
  • Support MetaMask via EIP-712 (no changes needed)
  • Validators don’t need to run Ethereum nodes
  • Progressive decentralization path

Architecture Options

Option 1: Validator-Run Ethereum Nodes

Architecture:
  • Every Cowboy validator runs a full Ethereum node (geth, reth, etc.) alongside their Cowboy node
  • Ethereum block hashes are included in Cowboy consensus
  • Actors query Ethereum state via deterministic host functions
  • All validators must agree on Ethereum state at specific block heights
Implementation:
Pros:
  • ✅ Fully trustless - no reliance on external oracles
  • ✅ Low latency - direct RPC access
  • ✅ Simple consensus model - all validators have same view
Cons:
  • ❌ High resource requirements (each validator needs ~1TB+ for Ethereum)
  • ❌ Tight coupling between Cowboy and Ethereum consensus
  • ❌ Validators must sync/maintain Ethereum nodes
  • ❌ Ethereum state bloat affects Cowboy validators
Consensus Mechanism:

Option 2: Embedded Light Client

Architecture:
  • Cowboy protocol embeds Ethereum beacon chain light client
  • Validators track Ethereum finality (post-merge proof-of-stake)
  • Actors submit Merkle proofs for state reads
  • No full Ethereum node required
Implementation:
Proof Verification:
  • Cowboy validators verify Merkle proofs against Ethereum state root
  • State root is trustlessly obtained from Ethereum beacon chain
  • Only light client (~few MB) needed per validator
Pros:
  • ✅ Trustless - cryptographic verification
  • ✅ Low resource requirements (~10 MB vs ~1 TB)
  • ✅ No dependency on full Ethereum nodes
Cons:
  • ❌ Complex proof generation (actors or runners must generate Merkle proofs)
  • ❌ Higher latency (proof generation + submission)
  • ❌ Increased on-chain computation (proof verification costs Cycles)
  • ❌ Ethereum beacon chain protocol changes require Cowboy updates
Consensus Mechanism:

Option 3: Optimistic Oracle Pattern

Architecture:
  • Specialized “Ethereum oracle” runners (similar to CIP-2 off-chain compute)
  • Runners submit Ethereum state with stake
  • Fraud proof window for challenges
  • Slashing for incorrect data
Implementation:
Oracle Mechanism:
  1. Actor submits Ethereum read request to Oracle contract
  2. N registered oracle runners independently query Ethereum
  3. Runners submit results + stake to Cowboy
  4. If consensus (e.g., 2/3 agree), result is accepted after challenge period
  5. Anyone can challenge with fraud proof during challenge period
  6. Incorrect runners are slashed
Pros:
  • ✅ No validator requirements - only oracle runners need Ethereum nodes
  • ✅ Flexible - can support any Ethereum RPC call
  • ✅ Leverages existing CIP-2 runner infrastructure
  • ✅ Economic security via staking/slashing
Cons:
  • ❌ Latency from challenge period (minutes to hours)
  • ❌ Trust assumption on oracle honesty (mitigated by staking)
  • ❌ Requires oracle runner infrastructure
  • ❌ Challenge mechanism adds complexity
Consensus Mechanism:

Architecture:
  • Combines flexibility of oracles with security of light clients
  • Standard reads use CIP-2 runner consensus (fast, cheap)
  • High-value operations use light client proofs (trustless, expensive)
  • Validators optionally run Ethereum nodes (not consensus-required)
Implementation:
How It Works:
  1. Standard Path (CIP-2 Oracle):
    • Actor calls eth_call() → creates off-chain task (CIP-2)
    • Multiple runners independently query Ethereum
    • Runners submit results to Cowboy
    • Consensus via majority (e.g., 2/3 agreement)
    • Fast finality, economic security
  2. Verified Path (Light Client):
    • Actor (or helper service) generates Merkle proof
    • Submits proof + claim to Cowboy
    • Validators verify against beacon chain state root
    • Cryptographic security, slower, more expensive
Pros:
  • ✅ Flexible: Actors choose security/cost/speed tradeoff
  • ✅ Gradual decentralization: Start with oracles, add proofs later
  • ✅ Uses existing CIP-2 infrastructure
  • ✅ No mandatory validator requirements
  • ✅ Trustless option available when needed
Cons:
  • ❌ More complex: Two paths to maintain
  • ❌ Requires developer judgment on which path to use

Phase 1: CIP-2 Oracle Integration (Months 1-3)

Goal: Enable basic Ethereum reads via off-chain runners Components:
  1. Standard Ethereum Read Task Type
    • Extend CIP-2 task definitions to include ethereum_read
    • Task schema defines: contract, method, args, block height
    • Runners with Ethereum RPC access can execute
  2. Runner Infrastructure
    • Runners operate Ethereum archive nodes or use Infura/Alchemy
    • Multiple runners submit results for consensus
    • Implement majority-vote finalization
  3. Actor SDK
Deliverables:
  • CIP-4: Ethereum State Reads via Off-chain Compute
  • SDK implementation of EthereumContract wrapper
  • Reference runner implementation with Ethereum RPC

Phase 2: Ethereum Transaction Submission (Months 3-6)

Goal: Enable Cowboy actors to submit Ethereum transactions Components:
  1. Transaction Construction in Actors
    • Actors build unsigned Ethereum transactions
    • Submit to runners as CIP-2 tasks
  2. Runner-Managed Key Signing
    • Runners operate hot wallets
    • Sign and broadcast Ethereum transactions
    • Return transaction hash to actor
  3. Escrow and Payment
    • Actor locks CBY payment for runner
    • Runner proves transaction inclusion (tx receipt)
    • Payment released on proof
Example:
Deliverables:
  • CIP-5: Ethereum Transaction Submission via Runners
  • Transaction escrow contract
  • Runner transaction submission service

Phase 3: Light Client Verification (Months 6-12)

Goal: Add trustless option via cryptographic proofs Components:
  1. Beacon Chain Light Client
    • Embed Ethereum consensus light client in Cowboy
    • Track finalized beacon blocks
    • Expose state roots to actors
  2. Merkle Proof Generation Service
    • Off-chain service generates Ethereum state proofs
    • Actors can request proofs for critical operations
    • Proof verification as Cowboy host function
  3. Dual-Mode SDK
    • Actors specify verified=True for proof-based reads
    • Automatic proof generation and verification
Example:
Deliverables:
  • CIP-6: Light Client Verification for Ethereum State
  • Beacon chain light client integration
  • Proof generation infrastructure

Phase 4: Bidirectional Bridges (Months 12-18)

Goal: Enable asset movement between Ethereum and Cowboy Components:
  1. Ethereum → Cowboy Bridge
    • Lock assets in Ethereum escrow contract
    • Mint wrapped assets in Cowboy (using CIP-20)
    • Light client proof of Ethereum lock
  2. Cowboy → Ethereum Bridge
    • Burn wrapped assets in Cowboy
    • Prove burn to Ethereum (via Cowboy light client on Ethereum)
    • Release locked assets from Ethereum escrow
  3. Standard Wrapped Asset Pattern
    • CIP-20 tokens representing Ethereum assets
    • Metadata linking to Ethereum origin
    • Redemption mechanism
Example:
Deliverables:
  • CIP-7: Ethereum-Cowboy Asset Bridge
  • Ethereum escrow contracts
  • Cowboy bridge actor implementation
  • Wrapped asset standard

Technical Deep Dive: CIP-2 Oracle Implementation

Since the hybrid approach is recommended and Phase 1 uses CIP-2, here’s how Ethereum reads work in detail:

Task Lifecycle

  1. Actor Request
  1. Task Submission (via CIP-2 Dispatcher)
  1. Runner Execution
  1. Consensus & Callback

Determinism Considerations

Problem: Different Ethereum nodes might have different views (reorgs, sync status) Solution:
  • Always specify exact block height (no “latest”)
  • Only use finalized Ethereum blocks (>= 64 blocks old)
  • Runners must verify block is finalized before submitting
  • Cowboy consensus waits for Ethereum finality
Enforcement:

FAQ

Do Cowboy validators need to run Ethereum nodes?

No, not in the recommended hybrid approach. Only the off-chain runners (CIP-2) need Ethereum access. Validators just need to verify runner consensus. In Phase 3, validators would run a light beacon chain client (~10 MB), not a full node (~1 TB).

How do we prevent Ethereum RPC centralization?

Multiple strategies:
  1. Require N-of-M runner consensus (e.g., 3-of-5)
  2. Economic incentives: Slashing for incorrect data
  3. Public runner set: Anyone can become an Ethereum oracle runner
  4. Light client proofs (Phase 3): Cryptographic security, no trust needed

What about Ethereum reorgs?

Use finalized blocks only. Post-merge Ethereum has clear finality (~12.8 minutes = 64 blocks). Cowboy tasks should only reference blocks that have reached finality. The protocol enforces this:
Important: This means there’s an inherent ~13 minute delay for safe Ethereum event processing. Cowboy actors cannot react to Ethereum events in the same block they occur - there will always be latency due to:
  1. Ethereum finality requirements (12.8 min)
  2. Consensus separation (Cowboy and Ethereum are independent chains)
  3. Detection and propagation time (seconds to minutes)
See “Understanding Event Latency” section below for details on fast vs. safe approaches.

Can actors write to Ethereum?

Yes, via runners (Phase 2). Actors construct transactions, runners sign and broadcast. This is more complex and requires:
  • Hot wallet management by runners
  • Transaction inclusion proofs
  • Payment escrow
  • Potential multi-sig for high-value operations

What about gas costs on Ethereum?

Actors pay runners, runners pay Ethereum gas. The runner factors Ethereum gas into their pricing. An actor might pay 100 CBY to a runner, who then spends 0.01 ETH in gas to execute the Ethereum transaction.
Cowboy’s approach is more composable with existing infrastructure (CIP-2). Rather than integrating yet another oracle network, we use the same runner infrastructure for both AI compute and Ethereum reads. Actors can also request light client proofs when they need stronger guarantees.

Understanding Event Latency: The Fundamental Constraint

A critical architectural reality: Cowboy cannot react to Ethereum events in the same block they occur. There will always be latency. This section explains why and how to handle it.

Why There’s Always a Delay

Cowboy is an independent L1 that watches Ethereum, not an Ethereum L2. This creates fundamental constraints:
The timeline for a safe Ethereum event:

The Fast vs. Safe Tradeoff

You must choose between speed and safety:

Option A: Fast but Risky (~15-20 seconds)

Accept unfinalized Ethereum blocks:
When to use fast mode:
  • Low-value alerts/notifications
  • Speculative trading (you accept reorg risk)
  • UX where speed > correctness
  • Operations with built-in rollback mechanisms
Risks:
  • Ethereum reorg → event disappears
  • Actor made decision on false data
  • Potential losses if funds were moved

Option B: Safe but Slow (~13 minutes)

Wait for Ethereum finality:
When to use safe mode:
  • Bridge deposits (MUST wait for finality)
  • High-value trades/transfers
  • Governance actions
  • Anything where correctness > speed
Tradeoffs:
  • ~13 minute latency
  • But cryptographically guaranteed to be correct

Watchtower Use Case: Safe Mode is Correct

For the Watchtower data registry (SEC filings, governance proposals, protocol upgrades), safe mode is the right choice:
Why safe mode for Watchtower:
  • Data changes slowly (governance proposals, SEC filings)
  • Correctness is paramount (can’t have false data in registry)
  • 13 minute delay is acceptable (these aren’t time-sensitive)
  • Downstream actors depend on accuracy

MEV/Trading Use Case: Fast Mode with Rollback

For MEV-sensitive operations, you might choose fast mode:
Why fast mode for MEV:
  • Time-sensitive (arbitrage opportunities disappear quickly)
  • Can accept some reorg risk (built into profit calculations)
  • Rollback mechanism handles false events
  • Speed advantage outweighs occasional false positive

The “Same Block Reaction” is Impossible

What developers often imagine:
Why this can’t work:
  1. Consensus separation: Cowboy and Ethereum have independent consensus mechanisms
  2. Finality requirement: Ethereum blocks aren’t final for 12.8 minutes
  3. Physical impossibility: Cowboy block M is being produced while Ethereum block N is still unfinalized
The only way to react “in the same block” would be to run Cowboy consensus on top of Ethereum consensus - which would make Cowboy an Ethereum L2, not an independent L1.

Validators Running Ethereum Nodes Doesn’t Help

Even if every Cowboy validator ran a full Ethereum node, you still can’t eliminate the delay:
The only benefit of validators running nodes:
  • Slightly lower latency (~15s instead of ~20s)
  • No trust assumption on runners
  • But still can’t bypass finality requirement
The cost:
  • Every validator needs ~1TB Ethereum node
  • Tight coupling between chains
  • Not worth it for most use cases

Watchtower and Real-time Data Considerations

Watchtower is a versioned data registry for external data (governance proposals, SEC filings, protocol upgrades). Even though some use cases want “real-time” data, validators running Ethereum full nodes doesn’t solve the latency problem. Key insight: Validators and runners serve different purposes
  • Validators: Validate Cowboy consensus, cannot submit Ethereum transactions
  • Runners: Execute off-chain tasks, including Ethereum interactions
Even if validators run Ethereum nodes, you still need runners to:
  1. Monitor Ethereum events → feed Watchtower registry
  2. Submit Ethereum transactions → execute actor commands on Ethereum
  3. Handle MEV-sensitive operations → require mempool proximity
For Watchtower specifically: The runner infrastructure scales to the use case:
  • Basic Watchtower ingestion: Runners use cheap RPC endpoints, no full nodes needed (~$0-10/month)
  • MEV-sensitive operations: Specialized runners with full nodes near mining pools, premium fees (~$500/month)
Runners are not validators - they’re separate infrastructure that anyone can operate. This keeps Cowboy validator requirements minimal while allowing specialized runners to handle high-performance use cases. Bottom line for Watchtower: No validator-run Ethereum nodes needed. Watchtower data changes slowly enough that ~13 minute finalized data ingestion via CIP-2 runners with standard RPC endpoints is the correct architecture.

Key Takeaway

The ~13 minute delay for safe Ethereum event processing is not a bug - it’s a fundamental constraint of having two independent blockchains. You can trade safety for speed (fast mode), but you must handle rollbacks. For most use cases, especially data registries like Watchtower, the safe approach is correct.

Summary

Recommended Approach: Hybrid (Option 4)
  • Phase 1: Ethereum reads via CIP-2 runners (oracle consensus)
  • Phase 2: Ethereum writes via runner-signed transactions
  • Phase 3: Light client proofs for high-value operations
  • Phase 4: Bidirectional asset bridges
Key Insight: Cowboy doesn’t compete with Ethereum on asset issuance (ERC-721, ERC-1155). Instead, Cowboy provides what Ethereum lacks: autonomous execution, AI compute, and Python-native development—all while orchestrating existing Ethereum assets. Next Steps:
  1. Draft CIP-4: Ethereum State Reads
  2. Extend CIP-2 task types to include ethereum_read
  3. Implement EthereumContract wrapper in Cowboy SDK
  4. Deploy reference runner with Ethereum RPC support