The Problem

Technical teams building prediction-market infrastructure face venue fragmentation — each platform (Polymarket, Kalshi, Limitless) requires custom adapter code, order-book handling, and risk logic. This repository addresses that by providing a venue-agnostic Rust execution core with 10 strategies deployable across multiple markets from a single process.

What This Does

The toolkit delivers a production-grade Rust trading bot framework with 52 files organized around a central execution engine. Twenty-nine Rust source files in src/ implement the core, supported by config, models, service layers, and bot strategies. Seven venues are live in production, two in beta, with 25+ more on the adapter-driven roadmap. The codebase employs a venue-agnostic adapter stack — adding a new market requires writing one adapter, not rebuilding the bot. Ten strategies (copy-trading, directional arb, market making, spread farming, sports execution, resolution sniping, whale signaling, orderbook imbalance, cross-market arb, and bot copy-trading) run on one battle-tested engine. Execution begins at run in src/bot/arbitrage.rs:11, which reaches 29 functions, or execute in src/service/order_executor.rs:89, which reaches 33 functions and is the terminal point for order flow. The internal call graph contains 116 resolved call edges between repository functions, with cfg called from 9 places, pos from 8, and check from 7, establishing these as high-impact control points. Key files by call volume: src/service/clob.rs (16 functions, 5 types), src/service/position_store.rs (16 functions, 2 types), src/service/risk_guard.rs (11 functions, 4 types), and src/utils.rs (8 utilities including clamp_price, usd_to_shares). Configuration lives in src/config.rs (defines is_strict, default_tp_pct, default_sl_pct, default_monitor_secs), while onchain interactions are handled by src/service/onchain.rs (spawn_subscription, run_once, parse_log).

How It Is Wired

Execution flows from run in src/bot/arbitrage.rs:11 through the bot module, filtering markets via build_filter, then spawning tasks. The run function delegates to live_trading_allowed, spawn, and build_filter. Market data flows through src/service/market_cache.rs (contains_token, by_slug, peek) and src/service/onchain.rs (parse_log, RawLog, LogFilter). Order execution traverses src/service/order_executor.rs (execute, check_exposure), which interfaces with CLOB ordering via src/service/clob.rs (build_signed_order, post_order). Risk checks reside in src/service/risk_guard.rs (check_fast, check_with_book, is_tripped, trip). Position tracking uses src/service/position_store.rs (open, close, get, pnl_pct) and src/service/position_monitor.rs (check_exit, take_profit_triggers). Strategy logic lives in src/service/strategy.rs (size_for_trade, adaptive_percent, trade, percentage_basic), while eligibility gates trades through src/service/eligibility.rs (check, ci_eq, market, default_filters_allow_everything). Utility functions in src/utils.rs provide clamp_price, usd_to_shares, and address truncation. The repository defines 144 functions and 52 classes/types including DirectionalArbParams, BotConfig, TradingConfig, RiskConfig, and CopyStrategy.

Duplicated 6-line blocks appear across src/bot/mod.rs, src/main.rs, src/service/eligibility.rs, and src/service/position_store.rs. Deep nesting of 5 levels occurs in src/service/market_cache.rs, src/service/onchain.rs, and src/service/order_executor.rs.

How To Use It

Setup: Clone a venue repository (Polymarket shown in README):

git clone https://github.com/HarrierOnChain/Polymarket
cd Polymarket

Configuration: Copy the example config and edit:

cp config.example.yaml config.yaml

Edit config.yaml with venue-specific keys, wallet addresses, and per-strategy parameters. The default has enable_trading: false — the full execution path runs in dry-run until flipped.

Running it: The entry point is invoked via Cargo:

cargo run --release -- run copy-trading

This starts the arbitrage bot in dry-run mode. Set enable_trading: true in config.yaml to submit real orders. Per-venue configs and walkthroughs live in each venue repo.

Real-World Use

A quant team wants to run a market-making strategy on Kalshi and a directional arb strategy on Polymarket simultaneously. They clone the respective venue repos, configure config.yaml with their API keys and wallet, select the desired strategies via strategy configuration, and run cargo run --release -- run. The single execution core routes orders to both venues through their respective CLOB adapters, while the risk guard monitors exposure and position monitors manage PnL triggers across both markets from one process. If Kalshi experiences order-book latency, the market_cache and onchain subscription layers ensure the Polymarket strategy continues unimpeded.

Code Health & Issues

Six measured findings from static analysis:

  • [MEDIUM/cognitive_load] Deep nesting x5 — files: src/service/market_cache.rs, src/service/onchain.rs, src/service/order_executor.rs — control flow hard to follow; flatten with early returns/guard clauses.
  • [MEDIUM/clarity] Duplicated code blocks — files: src/bot/mod.rs, src/main.rs, src/service/eligibility.rs, src/service/position_store.rs — six repeated 6-line blocks; extract shared helpers.

Code health audit (8 findings, 0 critical, 3 high, 4 medium, 1 low):

  • [HIGH] Pin third-party GitHub Actions to commit SHA — .github/workflows — dtolnay/rust-toolchain@stable, Swatinem/rust-cache@v2 can be moved; pin to SHAs.
  • [HIGH] Add a test suite — 29 source files, no test files — regression reaches production undetected.
  • [HIGH] Commit a lockfile — Cargo.toml has no lockfile — tested artifact may differ from shipped artifact.
  • [MEDIUM] Declare least-privilege permissions for GITHUB_TOKEN — .github/workflows/rust.yml declares no permissions — injected step can push commits or mint releases.
  • [MEDIUM] Enable Dependabot or Renovate — no update bot configured — advisories sit unpatched.
  • [MEDIUM] Gate pull requests on dependency vulnerability scan — no dependency scan in CI.
  • [MEDIUM] Set persist-credentials: false on checkout — .github/workflows/rust.yml — token stays in .git/config for later steps.
  • [LOW] Set timeout-minutes on workflow jobs — .github/workflows/pages-redirect.yml — two jobs declare no timeout.

The Bottom Line

This is a functional, venue-agnostic Rust trading framework that delivers 10 strategies on one execution core across seven live prediction markets. The codebase is well-structured with clear entry points and a resolved call graph, but lacks tests, has no lockfile, and carries duplicated logic and deep nesting that increase maintenance risk. Teams needing multi-venue prediction-market trading with a single codebase will find immediate value; those requiring rigorous test coverage and reproducible builds should plan to add a lockfile and test suite before production deployment.