Engineering source of truth.

1.1PortfolioGuard

Think of this as the speed limiter on the whole account. It looks across every running strategy and asks: are we, in aggregate, taking on too much risk for one wallet? It tracks four things — total notional exposure, 24-hour drawdown, how much of the account is in any single market, and how much is in clusters of related markets (e.g., three different Senate races in the same election event).

The parameters are all upper-bound percentages. max_account_notional_pct is "don't let total open positions exceed X% of wallet equity". max_24h_drawdown_pct is the rolling-loss circuit breaker. max_cluster_pct stops the user from accidentally betting the same outcome four ways through correlated markets.

1.2KillSwitch

The big red button. It either auto-fires when something is clearly wrong (intraday drawdown breaches the threshold, the CLOB WebSocket dies for more than 30 seconds with positions open, the API starts rejecting orders at a sustained rate), or the user/operator triggers it manually. When it fires, it cancels every open order, posts IOC orders to flatten inventory at top-of-book plus a tolerance, and refuses new orders until someone manually resets it.

intraday_drawdown_pct and weekly_drawdown_pct are the auto-trigger thresholds. require_manual_reset is locked to true — we never let a bot self-reset out of a kill, because if the kill fired the assumption is something is genuinely broken.

1.3OracleRiskMonitor (flagship)

Polymarket settles via the UMA optimistic oracle. Resolution typically completes within the UMA optimistic-oracle cycle (proposal → liveness → finalisation). Disputed markets may remain unresolved through the dispute window, during which positions are effectively frozen with binary settlement risk. Exact windows are configured per market via UMA parameters. This bot watches the UMA queue continuously and reacts to four things: a market we hold entering the proposal stage, a dispute being opened on a market we're in, ambiguous resolution-source flags in the market metadata, and the "Other" outcome in neg-risk events whose definition is shifting.

reduce_at_proposal_pct tells the bot to cut position size by X% the moment a proposal goes live (default behaviour: trim to 50%). block_disputed stops new entries on any market in dispute. max_dispute_window_h is how long you're willing to sit through a dispute before being auto-flattened.

1.4LiquidityGuard

Stops a strategy from eating through a thin order book and taking massive slippage. Before any order goes out, this bot looks at the visible depth at the best bid and ask, the spread vs. that market's typical 30-day spread, and how stale the top of book is. If the order would consume more than X% of visible depth, or the spread is way wider than normal, or the top has been frozen for over a minute (a stale-quote signal that the book may be unreliable), the order gets throttled or blocked.

max_pct_of_visible_depth caps how much of the visible book any single order can sweep — default 5%. min_top_of_book_usd is a floor on resting size before we'll consider quoting at all.

1.5RateLimitGovernor

Polymarket's public-endpoint and trading-endpoint limits are configured at runtime from Polymarket's current published values; exact values are read from configuration, never hardcoded. With many strategies running at once, it's easy to blow through those limits and start getting 429-rate-limited responses, which then cascade into missed cancels and stuck orders. This bot is a token-bucket queue across all strategies, prioritising cancels and risk-driven flattens over speculative new orders.

priority_cancel_over_open means cancels jump the queue. priority_risk_flatten means a Risk-Layer-initiated flatten skips the queue entirely. The user effectively never sees this bot — it just keeps the platform inside Polymarket's published limits.

1.6InventoryUnwinder

Market-makers are supposed to hold balanced inventory — if they keep getting filled on the same side, they end up with a directional bet they didn't sign up for. This bot detects when inventory drifts past the strategy's declared band, when a maker is bleeding mark-to-market while one-sided, or when a strategy crashes with open positions. When it fires, it replaces the strategy's quotes with one-sided passive orders that lean against the inventory until balance is restored, then hands control back.

max_inventory_band is the directional exposure cap. unwind_aggression controls how hard it leans — 0 means very passive resting orders, 100 means take the offer to flatten.

1.7BlacklistKeeper

Some markets are structurally bad places to trade — ambiguous resolution rules with words like "substantial" or "primary" that aren't defined, single-source resolutions from unreliable feeds, markets with prior dispute history, or markets resolving inside a window where you don't want to be touching them. This bot maintains a list of those markets (curated by the operator and informed by community / shared dispute history) and hard-blocks every strategy from quoting on them.

blacklisted_condition_ids is the explicit do-not-trade list. ambiguity_keywords is a list of phrases that, if found in resolution rules, auto-blacklist the market.

1.8ComplianceGate

The hosted Polytraders runtime enforces session-level access controls: it checks that the connected wallet's IP/connection metadata is not from a restricted jurisdiction, that Polymarket onboarding is complete on the linked wallet, and that no sanctions-list match exists. If any check fails at session start, the runtime does not come up.

Hosted vs SDK posture. The hosted runtime is responsible for enforcing access controls. The SDK exposes the same guard interfaces, but enforcement on self-hosted deployments is the user's responsibility — the SDK ships the checks; deployment ships the policy.

Mid-session changes. If jurisdiction or sanctions status changes during a session (for example, a new IP after a reconnect), the runtime drops to close_only: existing positions can be wound down, no new entries are accepted, and a governance event is emitted. Reactivation requires a fresh session.

Data retention. Connection metadata used for the gate is retained only for the active session and 30-day audit window required by the builder program; the long-term ledger stores only the access-decision and reason code, not the raw IP.

2.1SmartRouter

The strategy says "buy YES on this market for $500". This bot decides how: should it be a fill-or-kill (atomic, used for arbs where partial fills break the trade), a good-till-cancelled resting order (for makers who want queue position), a good-till-time order (for news trades that should auto-expire if the signal goes stale), or an iceberg order broken into smaller children (for large orders that would otherwise telegraph our hand to the book)?

iceberg_threshold_usd is the order size above which we automatically slice into iceberg_child_count smaller orders. gtd_signal_ttl_s is how many seconds we'll let a signal-driven order rest before auto-cancelling — if the signal hasn't filled in that window, the trade thesis has decayed.

2.2AntiToxicFill

"Toxic fill" is trader jargon for getting filled right before bad news — you posted a passive bid, someone hit it because they already knew the price was about to drop, and now you're holding a losing position. This bot looks for the fingerprints of that situation: a sweep through 3+ price levels in the last 5 seconds, a sudden cancel-storm on the opposite side (counterparty pulling out of the way), or a news hit on the relevant entity within 30 seconds of a fill.

When triggered, it pulls quotes for a cooldown_s window — the cooldown is just "don't quote this market again for X seconds while we figure out what's happening". Then it widens the spread on re-quote (requote_widen_bps) so we're paid more for taking the risk, and downsizes the next few orders by downsize_factor. news_window_s is how close in time a news event has to be to the fill for the bot to treat the fill as suspicious.

2.3QueueWarden

On a CLOB, your spot in the queue at a given price level matters — the orders ahead of you fill first. This bot manages queue position: it watches our quote drift in ticks vs. the best price, notices when better-priced orders ahead of us get pulled (good news — we just got promoted in the queue), and detects stale resting orders that have sat too long with no book movement. It re-quotes with discipline — you don't want to spam cancel-replace because (a) it eats into rate limits and (b) it tells the market you're indecisive.

drift_ticks_threshold is how far our quote can drift from the best before we re-quote. cancel_replace_per_min_cap caps how often we can do that, to stay polite on the API and avoid signalling.

2.4NonceShepherd

Polymarket orders are signed messages (EIP-712), and each one needs a unique nonce. Under load, it's possible to sign multiple orders, send them out of order, and end up with a "nonce gap" where order #5 arrives before order #4 — which Polymarket will reject. This bot keeps the signing pipeline reliable: it tracks pending signed-but-unposted orders, detects gaps, re-derives L2 API credentials when needed, and refuses to issue new orders during a gap so we don't make things worse.

refuse_during_gap_s is how long the bot pauses new orders after detecting a nonce gap, giving the gap time to be filled. l2_credential_ttl_h rotates the L2 API credentials on a schedule for hygiene.

2.5GasOracle

Polymarket runs on Polygon, and on-chain operations (wallet ops, neg-risk conversions, withdrawals) cost gas. Most of the time gas is cheap, but during congestion it can spike. This bot decides whether non-urgent on-chain operations should be deferred until gas is cheaper. It compares current gas to the rolling 24-hour baseline and computes the EV of a pending neg-risk conversion against the expected gas cost.

max_gas_percentile_for_ops is "only run non-urgent ops when gas is below the Xth percentile of the last 24 hours". never_defer_risk is locked true — a Risk-Layer-driven flatten ignores gas entirely and pays whatever it has to.

3.1Maker-Tight (flagship)

Classic two-sided market-making on liquid markets. The bot continuously posts a bid below the mid and an ask above the mid, earning the spread when both sides eventually fill. It tracks four signals: the current mid price, how skewed our inventory is (if we're long, we lean quotes lower to bias selling), realised vs. quoted spread (so we know if we're being adversely selected), and order-flow imbalance over the last few seconds (so we can lean away from the toxic side).

edge_bps is how many basis points away from the mid we quote on each side — a tighter edge fills more often but earns less per fill. clip_size_usd is the size of each individual quote. inventory_skew_factor controls how aggressively the bot shifts quotes when inventory drifts. min_volume_24h_usd is a floor — don't quote on illiquid markets at all (default 250,000).

3.2Maker-Wide

Same idea as Maker-Tight but for thin books. On illiquid markets you cannot quote tight — you'll get picked off every time something moves. Instead, the bot quotes wide spreads (80–200 bps), small clip sizes, and a hard inventory cap so you can't accumulate too much in any direction. It also has a stale-book detector — if there are no fills for X minutes, back off and stop quoting until something happens.

edge_bps is wider here. stale_book_minutes is the timeout after which we stop quoting. hard_inventory_cap_usd is the do-not-exceed inventory band, much tighter than on liquid markets.

3.3Sum-to-One Arb (flagship)

On a binary market (e.g., "Will the Fed cut rates by July?"), YES + NO should always sum to $1 — because exactly one of them will be worth $1 at resolution. If the offer for YES is ¢48 and the offer for NO is ¢49, you can buy both for ¢97 total and walk away with $1 — a guaranteed ¢3 minus fees. The bot watches the WSS book stream on both legs in real time and fires fill-or-kill on both legs simultaneously. If only one leg fills, the FOK on the second leg auto-cancels and InventoryUnwinder picks up the orphan.

min_edge_bps is the required spread after fees. fee_buffer_bps and slippage_buffer_bps are safety margins. Reality check: simple-arb windows collapse quickly; configured TTL is per-strategy and per-market, not a global constant. Most of the profit goes to sub-second HFT scripts — this is profitable only on high-volume markets with low-latency infra.

3.4Neg-Risk Sum Arb

Same logic as Sum-to-One but for multi-outcome events. In a neg-risk event with N outcomes (e.g., "Who will be the next Fed Chair?"), the YES tokens across all outcomes should sum to $1. If they sum to ¢94, there's a 6¢ arb. The bot can either buy YES on each underpriced outcome, or — often more capital-efficient — buy NO on the cheapest outcome and use Polymarket's neg-risk conversion contract to turn it into 1 YES on every other outcome.

prefer_conversion_path tells the bot to use the conversion route when it's cheaper. exclude_other_outcome is locked true — we never trade the "Other" outcome directly because its definition shifts as placeholders are clarified.

3.5Bregman-Projection Arb

A more sophisticated multi-outcome arb. Instead of waiting for the YES tokens to sum below $1 (which rarely happens cleanly), this bot computes the closest valid probability distribution to the observed prices using KL-divergence, and trades the gap between the observed prices and that nearest valid distribution. The Frank-Wolfe optimiser then picks the trade allocation that captures the most divergence with the fewest legs.

kl_divergence_threshold is the minimum mispricing required before trading. frank_wolfe_iters caps how long the optimiser runs. The strategy is research-grade — reference: LayerX research on probability-simplex arbitrage.

3.6Cross-Market Arb

Different Polymarket markets that are logically related shouldn't have prices that contradict each other. "X wins the primary" must price at most as high as "X is the nominee". "Total goals over 2.5" must price at least as high as "Total goals over 3.5". When those constraints are violated, there's a hedged arb. The bot uses sentence embeddings (e5-large-v2 or similar, running locally) to cluster related markets, then a constraint checker flags violations.

min_similarity_score is the embedding-similarity threshold for treating two markets as related. require_manual_pair_review defaults true on this strategy — the cost of a wrong pairing is too high to fully automate.

3.7Cross-Venue Arb

If the same event is priced on Polymarket and on Kalshi, PredictIt, or a sportsbook, and there's a gap after both sets of fees, you can buy on the cheap venue and sell on the expensive one. The catch — and it's the #1 way people blow up on this strategy — is that the two venues must resolve from the same source. If Polymarket resolves on Reuters and Kalshi resolves on AP and they disagree, you can be right on both legs and still lose.

require_resolution_source_match is locked true. Sportsbook legs are semi-automated with manual approval because they don't expose APIs and have voiding/limit risk.

3.8News Materiality Trader code: news_reactor

Material news — a corporate earnings beat, a political resignation, a court ruling — moves prediction markets, and there's usually a window of a few minutes before the book fully digests it. The bot consumes the NewsIngest feed (Reuters, AP, Bloomberg, league wires), runs each item through an NLP materiality classifier, matches it to a watchlisted market, and if confidence is high enough, sends a time-bounded GTD order sized by confidence × liquidity. Latency target: under 1 second from feed to order.

materiality_threshold is the minimum classifier score required to fire. cooldown_s prevents firing twice on the same news cycle. order_ttl_s auto-cancels if the move hasn't played out in 60–300 seconds.

3.9Sports Model

A quantitative power-rating model produces a fair value for each sports market. When Polymarket's mid diverges from the model's fair value by more than 200 bps, the bot enters — sized via fractional Kelly with a hard per-bet cap. Inputs include lineups, injuries, weather (for outdoor sports), and live in-game state for in-play markets. Auto-disables on a sport when 30-day Sharpe goes negative for two consecutive weeks.

min_edge_bps_vs_model is the entry threshold (default 200). kelly_fraction caps sizing at a fraction of full-Kelly (full Kelly is too aggressive in practice). auto_disable_neg_sharpe_weeks is the model-drift kill switch.

3.10Resolution Fair-Value code: resolution_snipe

The event has clearly happened — the news has confirmed the outcome — but the market is still trading at ¢96 instead of ¢99 because traders haven't woken up yet. The bot buys these mispricings, but with a strict size cap because the tail risk is full loss on a wrong call. OracleRiskMonitor must approve (no active dispute), the resolution source must be unambiguous, and multiple independent news sources must confirm.

max_size_per_market_usd is capped at ≤ $2,000 — small enough that a wrong call doesn't break the account. require_unambiguous_source and require_oracle_clean are both locked true.

3.11Late-Resolution Spread code: endgame_arb

In the final minutes before resolution, winning shares often trade at ¢95–¢99 even though they will resolve to $1. That spread, after fees and gas, is small but reliable. The bot takes the offer up to a bounded clip and — critically — never averages down: if the price dips, it usually means new information arrived, not that the trade got better. OracleRiskMonitor must approve.

max_minutes_to_resolution is the entry window. never_average_down is locked true — a hard learnt rule.

3.12Mean-Reversion Sniper

Yes/No price asymmetry is treated as a hypothesis to be measured per market, not a global assumption. The bot fades extended spikes when two conditions are met: price above a configured probability threshold with a high z-score on the last-N price change, and a flip in the aggressor side (the side that was lifting offers stops lifting). It enters with a tight stop and a time-based exit. Crucially, it auto-disables during high-event-density windows — fading momentum during a breaking news cycle is a great way to get run over.

price_threshold is the minimum probability before the fade is even considered (default 0.80). z_score_min is the velocity filter. stop_bps and time_exit_s bound the loss.

3.13Breakout-Follower

The opposite-shaped twin of Mean-Reversion. When NewsIngest fires a high-confidence asymmetric event, prices break out of their recent range and momentum tends to continue for a window. The bot enters in the direction of the break, scales in over several entries, and trails the take-profit by ATR (average true range) so winners run and losers get cut early.

news_confidence_min requires a high NLP score before entry. scale_in_steps spreads the position over multiple entries. trail_atr_multiple sets the trailing-stop distance.

3.14Liquidity-Pulse

Markets that are about to get attention but haven't yet are the best place to be a liquidity provider — you set wide quotes early, get a queue position, and tighten as volume arrives. Triggers include news mentions on a topic spiking while the related Polymarket volume hasn't moved, related markets moving while this one sleeps, and scheduled events under six hours away with low pre-event volume.

initial_spread_bps is the wide quote at first. tighten_at_volume_usd is the volume threshold at which we narrow the spread. max_pre_event_position_usd caps how much inventory we'll accumulate before the event hits.

4.1NewsIngest

The wire room. NewsIngest reads Reuters, AP, Bloomberg, league and federation feeds and a curated set of official organisation handles in real time, then does two things — entity resolution (figuring out which Polymarket markets a headline actually concerns) and materiality scoring (how much should this move price). It deliberately only watches a tracked-market watchlist so it isn't drowning in unrelated news, and it dedups near-identical headlines that hit multiple wires within a few seconds.

entity_watchlist is the list of markets / entities the bot cares about — anything outside the list is dropped at the door. materiality_min is the floor classifier score (0–1) below which the headline is ignored even if it's on a watched entity. source_priority is the ordered list of wires we trust most when two contradict each other. dedup_window_s is how long we treat near-duplicate stories from different wires as the same event.

4.2OracleWatcher

Polymarket markets resolve via UMA's Optimistic Oracle — anyone can propose a resolution, anyone can dispute it, and a vote follows if there's a dispute. The window between proposal and finalisation is when bad things happen to traders who don't know the resolution is live. OracleWatcher polls the on-chain UMA contracts, tracks the dispute and vote queues, and emits a per-market resolution-risk state plus a countdown. Layer 1's OracleRiskMonitor is the bot that actually uses this signal to gate other strategies — OracleWatcher just produces it.

watched_condition_ids is the list of Polymarket condition IDs to track. poll_interval_s is how often we re-read on-chain state — too fast wastes RPC budget, too slow misses state transitions. alert_on_state_change emits a signal the moment a market moves between proposed / disputed / vote / finalised so downstream strategies can react.

4.3OrderFlowAnalyzer

The microstructure layer. OrderFlowAnalyzer subscribes to the WSS book stream for every market we touch and computes the features that maker strategies depend on — order-book imbalance over a short window (how much more size is on the bid vs the ask), our queue position at each price level, micro-volatility over the last few seconds, trade-print flow, and cancellation rate. It publishes those features at a fixed rate so Layer 3 strategies can consume them without each one having to recompute the same signals.

imbalance_window_s is the lookback window for book imbalance — short windows are noisier but react faster. queue_position_method is the algorithm we use to estimate where in the queue our resting order is (queue position is private info on Polymarket so it has to be inferred). micro_vol_window_s sets the volatility window. publish_rate_hz is how many times per second we emit the feature snapshot.

4.4CrossMarketGraph

Polymarket has hundreds of markets that are logically related — the same election asked three different ways, an over/under hierarchy that should be monotonic, a primary market and a nominee market that should respect each other. CrossMarketGraph reads market titles and rules text from the Gamma API, runs them through a local sentence-embedding model, and builds a graph of which markets are semantically equivalent or logically linked. It also accepts manual operator overrides because embeddings get the obvious 95% right and the subtle 5% catastrophically wrong.

cluster_threshold is the embedding-similarity score above which two markets are treated as related — too high and we miss real pairs, too low and we trade pairs that aren't really linked. manual_pair_overrides is the operator-curated list that always wins over the model. logical_relation_types tells the graph which kinds of relation we model (equivalence, implication, hierarchy).

4.5SportsFeed-Adapter

The plumbing that turns external sports data into something Layer 3's Sports Model can actually consume. League APIs (NBA, NFL, EPL, ATP/WTA, MLB) all have different shapes; odds-feed providers carry lineup, injury and weather data; and a handful of sports we care about (smaller leagues, niche tournaments) only have web sources. The adapter normalises all of those into a single typed schema and falls back to web parsing only when no API exists.

enabled_sports is the whitelist of sports we ingest data for. preferred_provider per sport is which odds-feed vendor we trust first. refresh_interval_s controls how often each feed is re-pulled. fallback_to_web is the kill switch — set false in production for any sport where web parsing has been flaky.

4.6SocialSentiment

Social signals are loud, easily manipulated, and full of sarcasm. SocialSentiment is deliberately built as a secondary input — it can support a thesis another bot already has, but it can never be the primary trigger that opens a position. It runs a sarcasm-aware classifier on rate-capped public streams, decay-weights older posts so a single viral thread doesn't dominate, and exposes its weight in the final signal as a configurable parameter capped at 0.3 by design.

weight_in_signal is the maximum contribution to any composite signal (capped at 0.3). decay_half_life_min is how fast old posts lose influence. per_topic_rate_cap stops a single topic from flooding the signal. require_secondary_only is locked true — it's a permanent guardrail, not a tweakable parameter.

4.7OnChainWatcher

Polymarket positions are public on-chain. OnChainWatcher tracks a curated list of wallets — known sharp traders, market makers, identified-as-informed actors — and emits a signal when their net position in a tracked market changes by more than a threshold. The publish_delay_s is deliberate and important: we never publish a wallet's move with zero delay, both to avoid front-running them ourselves and to prevent obvious copy-trading patterns from forming around our signal.

watched_wallets is the operator-curated list of addresses. min_position_change_usd is the size threshold below which moves are ignored as noise. publish_delay_s is the deliberate lag between observing the move and emitting the signal.

6.1BuilderAttribution (flagship)

BuilderAttribution is commercially load-bearing — it is the source of truth for builder-program reporting and revenue reconciliation, and any drift here directly impacts our standing with Polymarket. Safety load-bearing modules are PortfolioGuard (1.1), ContractAddressGuard (5.8), OrderLifecycleManager (2.6), and KillSwitch (1.2). Every order — without exception — leaves Polytraders with our builder code stamped on it. BuilderAttribution is the bot that does the stamping at the order-router seam, logs every code-tagged fill to our own ledger, and every 24 hours pulls Polymarket's official Builder-Code report and reconciles it against what we logged. If those two reports drift, the affected strategy is automatically quarantined until an operator clears it. This is how we prove what we did, who we did it for, and that we're a builder partner rather than a counterparty playing against users.

builder_code is locked at the org level — no strategy or operator can override it. reconcile_window_h is the rolling window over which we compare our log against Polymarket's report (default 24h). quarantine_on_drift is locked true — if our number disagrees with Polymarket's number, we stop trading until it's resolved. alert_on_missing_code is also locked true — a single uncoded order pages an on-call operator immediately.

6.2Health & Heartbeat

Every bot in the system emits a heartbeat on a fixed cadence. Health & Heartbeat is the bot that watches those heartbeats, watches order-reject rates, watches fill anomalies and latency spikes, and decides whether to auto-restart, alert, or page. The point is that silence is failure — if a bot stops emitting heartbeats, we treat it as broken and either bring it back automatically or pull a human in. Many failure modes don't crash loudly, they just stop making decisions, and this layer catches that.

heartbeat_interval_s is how often each bot is expected to phone home. missed_heartbeats_to_alert is how many in a row before we treat the bot as down. auto_restart controls whether we attempt a clean restart automatically before paging. page_on_failure wakes a human — used sparingly because alert fatigue is real.

6.3PnL Reporter

Realised PnL (closed positions, fees included) plus unrealised PnL (open positions marked-to-market against the current Polymarket price), broken down per bot, per market, and per author. The point of breaking it down per author is governance: every strategy in the system has an owner, and that owner's positions and PnL are explicitly attributed back to them so the team can see who shipped what and how it actually traded. Reports run daily and weekly and can include or exclude paper-trade signals.

report_window picks daily or weekly cadence. group_by chooses the slice (bot, market, author). include_paper toggles whether shadow-mode strategies are included in the same view (useful for evaluating not-yet-live strategies side-by-side with live ones).

6.4Backtester

Tick-level historical replay over CLOB snapshots — not a synthetic simulation. The Backtester replays the exact same WSS event stream that Layer 3 strategies would have seen on the day, runs them through the exact same execution path, and reproduces fills under the exact same fee and gas model. That "same path" rule is the whole point: a strategy that backtests well via a custom shortcut and then fails in production is a strategy that was never really backtested. Parameter sweeps run as a list, so you can sweep edge_bps or kelly_fraction and compare side-by-side.

start_ts and end_ts bound the replay window. strategy is the bot under test. parameter_sweep is a list of parameter sets the engine runs in parallel.

6.5Paper-Trade Runner

Mandatory shadow mode. Before any new strategy is allowed to deploy capital, it has to run against live signals through Paper-Trade Runner for a minimum number of days, against a simulated capital pool, and produce a positive risk-adjusted result. This isn't a backtest — it's the real live signal stream with simulated fills, so it captures the things backtests miss (latency to feed, real network conditions, real news interruptions). It's the gate between "good idea on paper" and "the firm is risking real money on this".

min_paper_days is the minimum shadow run before promotion is even allowed (default 14). require_positive_risk_adj is the gate — the strategy has to clear a risk-adjusted floor over the paper window. simulated_capital_usd is the pretend bankroll the paper run trades against.

6.6Cron Runner

Scheduling, in operator-controllable terms. Cron Runner enables and disables strategies on a schedule (NFL strategies dark on Tuesdays; election-bot quoting cycle starts six hours before US polls close), kicks off scheduled rebalances, and runs pre-event quoting cycles that need to start at a specific UTC time. Everything runs in UTC internally because mixing timezones in a 24/7 trading system is how mistakes happen. Operators can also define quiet hours during which all non-essential strategies are paused.

cron_expression is a standard cron string in UTC — always UTC, never local time. enabled_strategies is the list of strategies the cron entry controls. disable_during_quiet_hours respects the org-wide quiet-hours band where applicable.

6.7Portfolio Sync

The reconciliation loop between our internal view of positions and Polymarket's view. Every N seconds, Portfolio Sync pulls the Data API positions for each connected wallet and compares them line-by-line against our internal position store. If a discrepancy above the alert threshold appears — a position size we don't have on our books, a fill we never logged, a balance that drifted — we can automatically pause the affected strategy until an operator reconciles. This is the bot that catches the worst class of failure: thinking you're flat when you aren't.

sync_interval_s is the polling cadence. discrepancy_alert_usd is the dollar threshold above which a drift becomes an incident rather than a rounding-error. auto_pause_strategy_on_drift is the safety — if positions don't match, the affected strategy stops trading until a human signs it off.