Omeswap

Six AI agents vote on every trade—explainable crypto & equity copilot with strict risk limits

Omeswap

Created At

Open Agents

Project Description

Omeswap is a wallet-connected trading platform built around an Agentic Trading System (ATS): several specialized components work together so trading logic is not a single black-box model, but a pipeline you can inspect.

At the center is an orchestrator (conceptually a LangGraph-style state machine in the architecture) that runs a coordinated workflow each cycle: market and news data are ingested and normalized, downstream modules produce votes (signal direction and confidence, relationship/contagion-style context, regime classification), and a risk gate applies hard limits (including an absolute veto—risk can block a trade even if other modules agree). When consensus criteria pass and risk approves, an execution path places orders using disciplined execution habits (for example favoring limit orders on entries and reserving market orders for urgent exits like stop triggers in the documented MVP behavior).

Users are not forced into one experience. The design supports three modes: Autonomous (system can propose/act within configured boundaries), Assisted (agents produce research and sizing context while the human decides), and Solo (research-focused usage without agent-driven execution voting). This matters because real traders differ in how much automation they want—but the same underlying analytics stack can still support research and post-trade understanding.

A core product idea is explainability: major decisions are intended to produce a structured Decision Receipt—a durable record of what triggered analysis, what each module concluded, regime context, risk sizing, whether the trade executed, and fills/outcomes over time. A conversation layer is meant to answer questions like “why did we take this trade?” by grounding answers in those receipts (reducing “the model just said so” explanations).

On the strategy side, the vision includes a library, marketplace, and builders (visual DAG-style composition and code-oriented strategy authoring) so users can combine indicators and filters rather than being locked into one canned strategy.

Technically, this repository presents as a modern Next.js app with deep trading UX surfaces (including a terminal, trade, portfolio, marketplace/strategies, research, and an agent-builder area), wallet connectivity, and backend-facing configuration for onboarding/data services (for example Supabase-backed APIs in local setup). Optional documentation also describes a chain-agnostic adapter layer so on-chain execution concerns stay modular relative to the agent core.

Important caveat: the documentation frames the ATS as research and educational infrastructure; markets involve substantial risk, past patterns do not guarantee future results, and production trading requires careful compliance, testing, and operational controls.

How it's Made

We built Omeswap primarily as a Next.js 15 (App Router) + TypeScript application: the UI, route handlers, and most “trading brain” logic live in one codebase and deploy as a single web process. React 19 drives the interface; styling and components lean on Tailwind CSS and Radix/shadcn-style primitives. Client-side Web3 is wired with wagmi v2 + viem and RainbowKit, so wallet connection and chain switching stay consistent across pages without bespoke connector glue.

The Agentic Trading System (ATS) is implemented in TypeScript, not as a separate microservice in this tree. lib/ats/orchestrator.ts runs a deterministic multi-phase pipeline: a data agent pulls context (prices/news-style inputs via our data helpers), then regime, signal, and graph logic run as the parallel “analysis” slice, followed by a risk agent that can hard-veto proposals. A weighted consensus step turns agent votes into BUY / SELL / HOLD (with immediate short-circuit if any agent vetoes). Depending on mode (autonomous, assisted, solo), execution may run, require explicit approval, or stay research-only. The orchestrator emits structured run events so the UI can show a live audit trail instead of a single opaque completion.

The research runtime is exposed through POST /api/research/run, which streams results as Server-Sent Events (SSE): each chunk is a serialized RunEvent, so the terminal/research UI gets incremental updates without polling. After a run, we best-effort upload receipt blobs through lib/zerog (0G Storage) and back-fill a storage root hash when upload succeeds—this pairs “app database truth” with decentralized, content-addressed persistence when the network path works.

Supabase is our operational database and admin API surface: we use the service-role server client (@supabase/supabase-js) from Next.js Route Handlers for tables like decision_receipts, user_settings, marketplace/creator flows, and agent_wallets. That choice trades “pure decentralization” for fast iteration: auth-ish gating for many routes is pragmatically done via wallet identity headers (see requireWallet / x-wallet-address patterns), while Supabase holds authoritative rows.

A notable subsystem is the agent wallet: lib/agent-wallet/manager.ts mints a burner EOA per user (via viem key generation), encrypts the private key with AES-256-GCM using AGENT_WALLET_MASTER_KEY, and stores ciphertext metadata in Supabase. At runtime the server decrypts into a viem LocalAccount so autonomous paths can sign transactions without the user signing every micro-action—with the usual security caveat that this is custodial server-side key material, designed carefully for demos/MVP autonomy rather than hardware-wallet parity.

LLM features route through lib/ats/llm.ts: it’s a thin OpenRouter integration implemented with the openai npm package (OpenAI-compatible HTTP API). Keys resolve in priority order: user-provided encrypted key in user_settings, else OPENROUTER_API_KEY. Models default to google/gemini-2.5-flash-lite but can be overridden per user settings.

On-chain configuration is centralized in lib/chain-registry (e.g. 0G Newton testnet as the documented default in ATS flows, plus Avalanche/Ethereum configs). DEX-facing UI and APIs combine viem reads, pool/market helpers (lib/dex, lib/uniswap), and price/chart feeds (CoinGecko SDK + GeckoTerminal helpers appear in the DEX libs). Charts use TradingView Lightweight Charts; the strategy/agent-builder surfaces use React Flow / XYFlow node graphs and a BotRunner-style engine for executing graphs.

There’s also a parallel avax-agent/ subtree with its own route modules and node library—useful to mention as an older/alternate agent-bot composition path that mirrors some concepts (price feeds, swap/limit nodes, backtests) while the main ATS pipeline lives under lib/ats.

Hacky-but-intentional MVP details worth calling out:

Ticker extraction from free text uses a curated symbol list + regex word-boundary checks when users don’t pass an explicit ticker—fast and predictable, not “real NLP entity linking.” USD balance estimation for Kelly sizing uses chain-specific placeholders when there isn’t a clean live oracle path (called out directly in the research route comments), so sizing stays stable rather than failing closed. 0G uploads are best-effort: the core user-visible run succeeds even if decentralized persistence hiccups—good for demos, but it means storage anchoring is eventually consistent, not strictly transactional with Postgres. Partner tech benefits (concisely): WalletConnect/RainbowKit/wagmi reduces wallet UX overhead; Supabase accelerates receipts/marketplace/onboarding persistence; OpenRouter gives multi-model access through one API shape; CoinGecko/GeckoTerminal keeps charts and market metadata approachable without running full indexers; 0G adds a credible path toward off-chain receipt durability + compute aligned with the longer architecture docs.

background image mobile

Join the mailing list

Get the latest news and updates