Recorder Deployment Snapshot

Polymarket Recorder + Arb Detector

Current runtime architecture for the backtesting_harness branch Leo has been shaping: one Rust runner, two mounted strategies, one shared market-data hub, full-depth JSONL capture, a read-only inspection API, and a replay path for later backtests.

Host go-trading-eu / 54.171.188.62:8090

Mode data_recorder + combinatorial_arb

Universe 4 fixtures / 12 sets / 92 tokens

Guardrail no live trading on this deployment

Shared Hub One websocket, many consumers Both strategies subscribe once and read the same in-memory order books.

Recorder Full depth, not just top-of-book Bids, asks, and last trades flush to daily JSONL so the replay path keeps the real state space.

Replay Path Record now, analyze later The same JSONL can reconstruct hub state offline for backtests, slippage analysis, and fillability checks.

System Flow

How the runtime moves from market input to replayable evidence

Same architecture, just easier to read: external inputs feed one runtime core, the mounted strategies branch off that shared hub, and the outputs split into safe inspection, durable storage, and offline analysis.

Input surface

Two upstream sources seed the recorder deployment before any strategy logic does its thing.

Gamma API resolves fixture and event slugs into the token sets to watch.
Polymarket CLOB websocket streams unauthenticated book updates plus last trades.
The current recorder env is watching 92 subscribed outcome tokens.

Runtime core

One Rust binary runs the deployment and keeps the shared market state in one place.

copy-bot runner is the single process entrypoint.
MarketDataHub owns one websocket client and fans events out to both strategies.
The hub caches best bid/ask and full depth per token, so duplicate subscriptions are avoided.

Mounted strategies

The recorder box mounts capture and arb detection together, while leaving the trade executor out.

DataRecorderStrategy expands 4 fixture slugs into exact-score and halftime siblings, then subscribes the full token universe.
CombinatorialArbStrategy evaluates each set every 2 seconds and logs edges at or above the default 2% threshold.
Copy-trade lane exists in the repo but is not mounted here: no executor, no halt/resume, no orders.

Outputs

The box exposes the state safely, stores it durably, and leaves a clean path for offline replay.

Recorder writes one UTC-day JSONL file per day at /data/recorder/YYYY-MM-DD.jsonl.
Read-only API exposes health, strategy, snapshot, detection, and balance surfaces without mutating access.
S3 sync + replay harness move the capture off-box and let later analysis reconstruct book state.

Component Detail

Operational detail without the giant SVG headache

This keeps the specific facts from the original artifact, but groups them by what an operator actually needs to inspect: runner config, strategy behavior, exposed interfaces, storage, and replay.

Runner and environment

The deployment is a systemd-managed recorder shape running from /opt/copy-bot on the backtesting_harness branch.

Recorder env

COPY_STRATEGIES=data_recorder,combinatorial_arb
API_PORT=8090
RECORDER_ENABLED=true

copy-bot@recorder.service keeps the runner alive on EC2.
The recorder deployment is explicitly detection-only, not a trading lane.

Recorder strategy

The recording lane exists to capture the whole market state now so future analysis does not depend on partial or top-of-book snapshots.

Expands the 4 fixture slugs into exact-score and halftime sibling markets.
Subscribes all resulting tokens through the shared hub instead of opening duplicate data paths.
Flushes full bids, full asks, and last-trade lines into daily JSONL output.
This is the granular dataset Leo wanted for later backtesting and slippage work.

Combinatorial arb detector

The arb lane shares the same token universe, then runs recurring checks on the combined books rather than touching any execution path.

Uses the same fixture-derived sets as the recorder.
Sums asks and bids across each combinatorial set.
Logs edges at or above the default 2% threshold.
Keeps a ring buffer, total counts, and best_edge_seen.
Current recorder interval: 2 seconds.

Read-only inspection surface

Apollo and teammates can inspect the recorder box without SSH and without mutating anything, because the mounted API is intentionally narrow.

Exposed routes

/health
/strategies
/snapshot
/detections
/balance

The API is safe in this deployment specifically because copy-trade is absent.
The inspection surface is built for observability, not control.

Storage and sync

Durability is split between local JSONL capture and an hourly S3 sync path so the recorder does not depend on the box staying perfect forever.

Recorded outputs

/data/recorder/YYYY-MM-DD.jsonl
/data/detections

upload-recordings.timer runs the off-box sync loop.
upload-recordings.service uses the instance IAM role plus aws s3 sync.
S3 target: go-trading-db-backups/backups/recorder/go-trading-eu.

Replay and backtest path

The replay harness is where later work plugs in: it reads the recorded JSONL, reconstructs hub state, and reruns strategies offline against the real observed book.

Historical sessions can be pulled back from the S3 archive.
The harness reconstructs MarketDataHub-like state from recorded events.
This is the future slot for duration, slippage, and fillable-edge analysis.

Guardrails and non-goals

The important design choice here is what the box does not do. That absence is the safety model.

No copy-trade executor is mounted on this deployment.
No live orders, no halt/resume control surface, and no write path to exchange state.
The point today is evidence capture plus detection, not trading.

Why This Layout Matters

Leo is optimizing for future truth, not current action

The core move is not "trade now." It is "capture the full market state now so later analysis can answer the real questions." That is why the recorder keeps full depth, why the arb detector only flags edges instead of acting, and why the replay harness matters: visible edge is cheap, fillable edge is the real question, and this layout is built to answer that later without contaminating the data now.

2026-06-18-polymarket-recorder-architecture