Architecture

Matchpoly runs as six independent layers operating simultaneously. Each layer handles a distinct part of the process — pulling data, estimating probabilities, generating signals, executing trades, managing risk — and passes information to the next without waiting for it to finish. Nothing in the pipeline is blocking. A slow news classifier doesn't delay a structural arb execution. A database write doesn't stall an order submission.

// THE SIX LAYERS

Data. The foundation. Live price feeds from Polymarket via WebSocket, odds from Pinnacle and other sharp books, official league injury feeds, wire services, and real-time blockchain data from Polygon. Every trade on Polymarket is an on-chain event — the data layer reads those events as they happen, maintaining a live mirror of the order book in memory so the rest of the system never has to make a slow REST call for current prices.

Probability Engine. Takes raw data and outputs a single number per market: Matchpoly's best estimate of true probability, with a confidence interval. For markets where a sportsbook match exists, that estimate is anchored to Pinnacle's vig-free line, cross-referenced against Betfair and other sharp references. For news events, an AI ensemble of three models runs in parallel and produces a revised estimate. Both inputs flow into a Bayesian updater that prevents overreaction to any single signal.

Signal Generation. Compares the probability estimate to Polymarket's current price and produces ranked trade signals. Signals are scored by edge size, market liquidity, how many independent sources confirm the view, and how much time is left before the market closes. Conflicting signals cancel each other — if one engine says buy YES and another says buy NO on the same market, no trade happens until the signals converge.

Strategy Modules. Each of the four strategies — Pinnacle Gap, Structural Arb, Whale Copy, News Reflex — runs as an independent module. Any module can be paused, adjusted, or disabled without affecting the others. They pull from the same signal queue but have separate entry criteria, sizing logic, and exit rules.

Execution Engine. Translates signals into on-chain transactions. Checks risk limits before every order, models slippage against the live order book, and fires trades via Polymarket's order system. Tracks every order through its full lifecycle — submitted, filled, partially filled, cancelled, rejected — and reconciles against on-chain balance as ground truth.

Risk & Monitoring. Runs in parallel with everything else. Tracks open exposure per market, per game, per sport. Enforces drawdown limits. Monitors for adverse selection signals in market-making positions. Operates the kill switch. Nothing in the layers above it can override it.

// LATENCY AND INFRASTRUCTURE

Speed is the constraint that shapes every other infrastructure decision. For arbitrage strategies — Structural Arb and, to a lesser degree, Pinnacle Gap — the target from signal detection to order submission is under 100 milliseconds. For directional strategies with a longer edge window, under 500 milliseconds. These requirements dictate that the system runs on dedicated, bare-metal infrastructure co-located near Polymarket's servers and Polygon RPC endpoints rather than shared cloud instances, which introduce unpredictable latency spikes.

The system maintains a dedicated Polygon node connection — not a public shared RPC — for direct transaction submission and on-chain balance verification. Gas prices are monitored continuously; time-critical orders submit at a premium to ensure rapid block inclusion, while lower-priority operations use standard gas to avoid unnecessary cost.

Fail-safe defaults govern every failure mode. If any component loses its connection, times out, or throws an error, the system defaults to holding existing positions and opening no new ones — never to placing orders based on stale data. All state is persisted continuously, so a restart picks up exactly where it left off without manual reconciliation.