MERCURY
Integrating markets takes more than comparing prices.
Offline suite with fixtures, mocks and SQLite. A stale alert snapshot was corrected before the final run. Zero failures; no live trading took place.
Objective and distinction from Argus
MERCURY is an engineering research project for integrating prediction markets and examining cross-platform opportunities. Unlike Argus, which emphasizes data foundations and replay, its focus includes price comparison, costs, multi-leg execution and position tracking.
A theoretical opportunity must survive available liquidity, fees, feed delays and execution failures. The project models these problems in code without presenting validated profitability or live operation as a result of this study.
Asynchronous architecture and event flow
Rust and Tokio support feed, detection, execution, inventory and monitoring tasks. Channels transport validated opportunities, trade results and alerts; traits separate database access and order clients from their implementations.
The flow is event-driven: a tick changes a market’s book, triggers its evaluation and may produce an opportunity. This organization reduces the need to scan all markets for every update.
Feeds, discovery and normalization
The repository contains adapters for Polymarket, Kalshi, CDNA and ForecastEx plus market discovery and registration. Each integration has its own identification, authentication and price-representation contracts.
Normalization converts inputs into comparable ticks with sequence, timestamp, price, quantity, depth and fees. Matching markets requires attention to question, resolution and expiration; similar prices alone do not establish economic equivalence.
Unified book and net spread
UnifiedOrderBook organizes data by market and platform. NetSpreadEngine evaluates complementary purchase directions and computes differences after costs, using rust_decimal for prices and values.
Fees, slippage estimates and on-chain costs participate in the calculation. Available depth bounds the evaluated size; walking the book estimates execution prices beyond the best level. These estimates remain dependent on data quality and freshness.
Detection, rejection and sizing
The detector records rejection reasons related to spread, liquidity, stale data, exposure and risk budget. It also tracks platform liveness, concurrency and histories used to adjust thresholds under volatility.
BankrollManager and KellyCalculator participate in sizing. These are implemented research mechanisms, not allocation recommendations. A formula’s presence in the system does not demonstrate that its assumptions are calibrated for real markets.
Circuit breakers and controlled interruption
Breakers consider trade size, losses, drawdown, platform and market exposure, aggregate exposure, consecutive failures and feed delays. Thresholds and pause state explicitly represent reasons for stopping new operations.
A cooldown can govern recovery after certain conditions. The engineering value lies in turning risk conditions into testable states and decisions; limit suitability requires evaluation beyond code inspection.
Execution, idempotency and partial failures
ExecutionEngine receives validated opportunities and uses platform-specific clients. Code provides dry-run mode, an LRU cache of processed opportunities and rate-limit handling with backoff.
Executing two legs is not an atomic cross-platform transaction. Results model fills, price, quantity, fees and errors; unwind and position-tracking paths address cases where only one leg fills.
Inventory, reconciliation and persistence
PositionTracker receives results and maintains persisted inventory. Reconciler compares state with available platform information; SettlementMonitor follows resolution. A watchdog looks for orphaned positions and alerts or attempts exposure reduction along implemented paths.
The Database layer has a SQLite implementation using SQLx and migrations. This separation supports in-memory database tests and investigation after failures, rather than relying solely on transient logs.
Telemetry and scenario testing
Atomic counters track ticks, spreads, opportunities, reconnects and failures per platform. Health checks, Telegram alerts and reports provide operations surfaces while separating monitoring from primary processing.
Integration tests use in-memory SQLite and simulated clients for opportunity, insufficient-spread, stale-data and risk scenarios. Feed tests, properties and snapshots also exist. The local library suite passed 79 tests after a stale alert snapshot was corrected. No orders were placed and no gains or latency were measured.
Current state and skills
The project demonstrates external APIs, asynchronous programming, decimal precision, event modeling, persistence, testing and partial-failure recovery. It connects economic problems to distributed-systems engineering.
Remaining validation includes controlled connector environments, market equivalence, reconciliation and behavior under real failures. This page presents a public repository without guarantees of profit, availability or operational security.