Home
Documentation
Architecture BlockWire CronSynth Switchboard
Resources
Glossary Use Cases Why Swarms Need Infrastructure Ecosystem Comparison
Systems Operational

EchoRift Architecture Overview

How the Stack Fits Together

The Problem We're Solving

Autonomous AI agents need four categories of shared infrastructure:

  1. Shared Perception — Common awareness of external state (blockchain events, market data, world state)
  2. Shared Time — Coordinated scheduling without background processes
  3. Shared Coordination — Task distribution, state management, and safety controls
  4. Shared Consensus — Leader election, distributed locks, and group decision-making

Without shared infrastructure, agents duplicate effort, build inconsistent views of the world, and step on each other when working together.

EchoRift provides all four through composable, agent-native services.

Stack Overview

The EchoRift stack consists of four core services that work together to provide shared infrastructure for autonomous agent swarms:

Your Agents

Multiple autonomous agents (Agent A, Agent B, Agent C, Agent N, etc.) connect to EchoRift infrastructure to share perception, time, coordination, and consensus capabilities.

EchoRift Infrastructure

Four composable services provide the foundation:

  • BlockWire — Shared Perception
    • Chain events
    • Attestations
    • Event feeds
  • CronSynth — Shared Time
    • Cron triggers
    • Scheduling
    • Webhooks
  • Switchboard — Shared Coordination
    • Task queues
    • Broadcasting
    • Shared state
    • Treasury
    • Circuit breaker
  • Arbiter — Consensus & Agreement
    • Leader election
    • Distributed locks
    • Consensus voting
    • Byzantine Fault Tolerance

Base L2 Blockchain

All critical state is anchored on-chain:

  • Subscription registry (BlockWire)
  • Event attestations (BlockWire)
  • Schedule attestations (CronSynth)
  • Swarm registry (Switchboard)
  • Treasury contracts (Switchboard)
  • Leadership proofs and term numbers (Arbiter)
  • Fencing token registry (Arbiter)
  • Stake deposits and slashing (Arbiter)

Component Deep Dive

BlockWire: Shared Perception

Purpose: Eliminate redundant blockchain polling across agent swarms

How It Works:

  1. BlockWire continuously polls Base L2 for relevant events
  2. Events are batched, hashed, and attested on-chain
  3. Subscribers receive HMAC-signed webhooks with event data
  4. Agents can verify any event against on-chain attestations

Key Capabilities:

  • Event Types: Contract deployments, liquidity events, price movements, large transfers, NFT mints
  • Delivery Modes: Push (webhooks) or Pull (x402 API)
  • Verification: On-chain attestations form a hash chain for audit trails

Integration Points:

  • Triggers can feed into CronSynth for time-delayed processing
  • Events can trigger Switchboard task creation
  • Attestations integrate with ETHYS reputation

Flow:

  1. Agent subscribes to BlockWire via on-chain transaction
  2. BlockWire continuously polls Base L2 for relevant events
  3. BlockWire sends HMAC-signed webhooks to subscribers with event data
  4. BlockWire attests event batches on-chain, forming a hash chain
  5. Agents can verify any event against on-chain attestations

CronSynth: Shared Time

Purpose: Provide time-awareness to serverless agents without background processes

How It Works:

  1. Agent registers a cron expression and webhook URL
  2. CronSynth maintains the schedule and triggers webhooks on time
  3. Each trigger includes run metadata and HMAC signature
  4. Schedule operations are optionally attested on-chain

Key Capabilities:

  • Scheduling: Standard 5-field cron with 1-minute resolution
  • Delivery: HMAC-signed webhooks with 5-second timeout
  • Reliability: Automatic retry with exponential backoff
  • Billing: Free tier + pay-per-trigger via x402

Integration Points:

  • Triggers can claim Switchboard tasks
  • Scheduled checks can query BlockWire for events
  • Attestations feed into ETHYS reputation

Flow:

  1. Agent registers a cron expression and webhook URL via POST request
  2. CronSynth maintains the schedule and monitors time
  3. When the schedule triggers, CronSynth sends a webhook with schedule metadata (scheduleId, runNumber, timestamp)
  4. Each trigger includes HMAC signature for verification

Switchboard: Shared Coordination

Purpose: Enable multiple agents to work together without collision

How It Works:

  1. Swarm is created with membership rules, treasury, and circuit breaker config
  2. Agents register with the swarm and receive credentials
  3. Coordination primitives (tasks, messages, state) enable atomic operations
  4. Circuit breaker monitors for harmful patterns and intervenes automatically

Key Capabilities:

Task Queues

  • Atomic claims prevent duplicate work
  • Priority ordering with configurable rules
  • Auto-release on agent failure
  • Completion tracking

Message Broadcasting

  • Post once, all members receive
  • Webhook delivery with sender exclusion
  • No polling overhead

Shared State

  • Key-value store with optimistic locking
  • Version conflict detection
  • Consistent reads across all agents

Treasury Management

  • Swarm-level USDC wallet
  • Per-agent budgets and spending limits
  • x402 integration for automatic service payments
  • On-chain audit trail

Circuit Breaker

  • Detects message loops, claim hoarding, broadcast storms
  • Rate limiting and automatic intervention
  • Event emission for monitoring

Integration Points:

  • BlockWire events can trigger task creation
  • CronSynth schedules can claim tasks
  • Treasury pays for BlockWire/CronSynth subscriptions via x402
  • Arbiter can elect leaders for swarm coordination
  • Arbiter locks can protect critical resources accessed by Switchboard tasks

Common Patterns

Pattern 1: Event-Driven Task Processing

A swarm that processes blockchain events as they arrive.

Flow:

  1. BlockWire detects new contract deployment
  2. Webhook triggers coordinator agent
  3. Coordinator creates task in Switchboard
  4. Worker agents claim and process tasks atomically

Pattern 2: Scheduled Swarm Operations

A swarm that runs coordinated operations on a schedule.

Flow:

  1. CronSynth triggers leader agent hourly
  2. Leader broadcasts "sync" message to swarm
  3. All agents receive broadcast and execute sync logic

Pattern 3: Treasury-Funded Operations

A swarm that pays for external services from a shared treasury.

Flow:

  1. Agent requests budget allocation from swarm treasury
  2. Agent queries BlockWire using x402 payment
  3. Payment deducted from agent's swarm budget
  4. Treasury tracks all spending for audit

Pattern 4: Circuit Breaker Protection

Automatic safety intervention when harmful patterns are detected.

Flow:

  1. Faulty agent enters broadcast storm
  2. Circuit breaker detects pattern
  3. Rate limiting applied automatically
  4. Event emitted for monitoring/alerting

Data Flow

On-Chain State

ServiceWhat's On-ChainPurpose

-----------------------------------

BlockWireSubscription registryVerifiable subscriptions

BlockWireEvent attestationsProve data authenticity

CronSynthSchedule attestationsReputation integration

SwitchboardSwarm registryVerifiable membership

SwitchboardTreasury balancesAuditable finances

Off-Chain State

ServiceWhat's Off-ChainPurpose

------------------------------------

BlockWireEvent cacheFast queries

CronSynthSchedule storageTrigger management

SwitchboardTask queuesLow-latency coordination

SwitchboardMessage buffersBroadcast delivery

SwitchboardState storeConsistent shared state

Authentication & Payment

x402 Payment Rails

All paid endpoints use Coinbase's x402 protocol:

  1. Agent makes request without payment
  2. Service returns HTTP 402 with payment requirements
  3. Agent signs USDC payment on Base
  4. Agent retries request with payment proof
  5. Service verifies payment and responds

No API keys. No subscriptions. No accounts.

HMAC Webhook Verification

All webhooks include verification headers:



X-BlockWire-Signature: 


X-BlockWire-Timestamp:

Agents verify by:

  1. Reconstructing the signature from payload + secret
  2. Comparing against header value
  3. Checking timestamp freshness (reject if >5 min old)

Deployment Architecture

All EchoRift services run on:

  • Compute: Serverless functions on Vercel/Cloudflare
  • Chain: Base L2 (mainnet)
  • Payments: USDC via x402
  • Data: Edge-cached with on-chain anchoring

Contract Addresses (Base Mainnet)

ServiceContractAddress

----------------------------

BlockWireRegistry0x20Fa63E8A50C3F990c67EF7df6e0D10a7005686a

CronSynthRegistry0x3846Ab73eCb4A1590B56cEB88D9779471B82A314

SwitchboardRegistryIn development

Getting Started

For Individual Agents

Start with the service that solves your immediate need:

For Swarm Architects

  1. Define your swarm's purpose and agent roles
  2. Set up Switchboard for coordination primitives
  3. Add BlockWire for shared blockchain awareness
  4. Add CronSynth for scheduled operations
  5. Add Arbiter for leader election and consensus decisions
  6. Configure circuit breaker thresholds
  7. Fund treasury and set budgets

Related Protocols

EchoRift is designed to compose with the broader agent ecosystem:

ProtocolRelationship

------------------------

A2A (Google)BlockWire events can trigger A2A tasks; Switchboard agents can use A2A for communication

MCP (Anthropic)EchoRift services can be exposed as MCP tools

x402 (Coinbase)Native payment rail for all EchoRift services

ETHYS Subscription and schedule attestations feed reputation scores

*EchoRift. Infrastructure for the machine age.*