Skip to main content
ouroborai is structured as a Bun + TypeScript monorepo where a Hono API server orchestrates a Claude-backed agent runner, protocol-specific adapters, and ERC-4337 smart account infrastructure. This page explains the data flow, component responsibilities, and design patterns that hold the system together.

High-Level Data Flow

Request Lifecycle

Every prompt follows this sequence:
1

Payment gate

The x402 middleware extracts the X-PAYMENT header, verifies the USDC signature, and checks that the nonce has not been used before (stored in Redis with a 24-hour TTL, or in an in-memory set for local development).
2

Job creation

The API creates an async job in the job queue and returns a jobId + threadId immediately. The caller polls GET /agent/job/:id for results.
3

Skill detection

The agent runner scans the prompt against registered skill definitions. Each skill declares a set of trigger keywords and maps to one or more adapter tools. Matching skills are loaded into the Claude system prompt as available tools.
4

Claude agent loop

Claude receives the prompt, the thread history (if threadId was provided), and the matched tool definitions. It reasons about the intent and emits a sequence of tool calls. The runner executes each tool call against the corresponding adapter and feeds results back to Claude until the agent produces a final text response.
5

Adapter execution

Each tool call dispatches to a protocol adapter. The adapter builds a transaction (or read call), simulates it against the current chain state, and either returns data (quotes, balances, health factors) or submits the transaction through the smart account.
6

Response

The final agent response and any transaction hashes are written to the thread and stored on the job. The client retrieves the completed job with the full conversation and execution results.

Adapter Pattern

Protocol integrations follow a uniform adapter interface. Each adapter exposes a set of tools — typed functions the agent can call — and handles all protocol-specific encoding, simulation, and error handling internally. Adding a new protocol means implementing the adapter interface and registering its tools with the skill system. See the Add a Protocol guide.

Skill System

Skills are the bridge between natural language and adapter tools. Each skill is defined in a SKILL.md markdown file with this structure:
When a prompt matches a skill’s trigger keywords, the runner loads that skill’s tools into the Claude context. Multiple skills can activate for a single prompt (e.g. “Swap USDC for ARB and supply ARB to Aave” activates both spot-trading and lending).
Skills are discovered at startup by scanning the packages/adapters/src/ directory for SKILL.md files. No registration code is required.

State Management

The platform uses a factory pattern for all stateful services. Each service has two implementations — one backed by Redis for production, one using in-memory data structures for local development — selected automatically based on whether REDIS_URL is configured. Threads are recovered automatically when a threadId is passed with a prompt. The web terminal persists the active threadId in sessionStorage so refreshing the browser resumes the same conversation.

Workspace Structure

The monorepo is organized into packages (shared libraries) and apps (deployable services):
Build order matters because of workspace dependencies:
  1. packages/sdk — no internal dependencies, built first
  2. packages/adapters, packages/timeboost, packages/smart-account — depend on sdk
  3. apps/* — depend on one or more packages
External packages @zerodev/*, permissionless, and tslib must be marked as externals in the Bun build configuration to avoid bundling issues.

Smart Account Integration

All on-chain transactions are executed through a ZeroDev Kernel smart account (ERC-4337). This provides three key capabilities: Session keys — The agent operates with a scoped session key that has limited permissions (specific token allowances, time bounds, spending caps). The user’s root private key never touches the agent runtime. UserOperation bundling — Multiple actions within a single prompt (e.g. approve + swap + supply) are bundled into a single UserOperation, saving gas and ensuring atomicity. Spending limits — Each session key is configured with per-token and aggregate spending limits. The smart account contract enforces these limits on-chain, so even a compromised session key cannot drain the wallet.

Stylus Contracts

Performance-critical on-chain logic is implemented in Stylus — Rust compiled to WASM and executed natively on the Arbitrum VM. These contracts use dynamic registries (indexed mappings with soft-delete) so new protocols and DEXes can be added without redeployment. See the Contracts section for detailed documentation.

What’s Next

x402 Payments

How the micropayment protocol gates API access.

Skills & Tools

Deep dive into skill detection and tool registration.

MCP Server

Use the 15-tool MCP server from Claude Code or any MCP client.

Contract Methods

Full reference for all Stylus contract interfaces.