trading systems

0DTE options · gamma advisory · real-time data warehouse

Three coordinated services on one host. A 104 GB time-series warehouse fed by 5 WebSocket hubs — the REST scaffold has been inactive since the 2026-03-30 cutover. A 73-feature signal evaluator on a 30-second tick. An execution engine with 5 hard gates and a kill switch. Producers write, consumers attach read-only — no message bus, no socket, no internal HTTP in the trading lane. Single-host, single-writer by design: every read is local-disk fast, every write is single source of truth.

Scope: paper trading on IBKR · personal, not a fund · infrastructure validation over strategy backtest.

── daily rollup ─ by date

daily rollup // 2026-06-02

loading…

data: refreshed nightly 00:05 ET · paper account · last successful pull: —

── pipeline ─ signal to execution

● operational ● degraded ● down — travelling pulses tick at the actual 30s poll cadence; metrics from snapshot 2026-05-06.

── subsystems ─ in execution order

svc-paisamaker[TRADING]uptime 100%

paisamaker · automated 0DTE execution

Python 3.12 · ib_insync · Hetzner systemd · uptime 19h 55m at snapshot, NRestarts=0

Two independent signal sources (a custom GEX evaluator on SPX and an advisor poller on 7 equity tickers) feed a unified dispatcher. The dual-lane design came from one specific observation: IBKR gateway reconnects take ~6 seconds, and a single-loop design would miss the next 30-second cycle. Separate lanes, independent cooldowns, per-(source,ticker) gates. The mode state machine (DATA_ONLY → RECONNECT_WARMUP → FULLY_LIVE, with EXECUTION_DEGRADED on disconnect) blocks new entries during recovery instead of retrying synchronously.

positions (lifetime)163

closed trades40

tickers8

safety gates20+ pre/post-trade

Python 3.12ib_insyncasyncioSQLite WALsystemdDocker (IB Gateway)

design note: paisamaker-dual-lane →

svc-gex-advisor[POLLING]uptime 99.8%

gex-advisor · multi-ticker signal evaluator

Python 3.11 · 8 tickers · 30s cycle · 240-reading rolling window

Four alert types on a 73-feature pipeline + five-force alignment model. CASCADE+CHARM combined: 29 wins / 46 resolved (63%) over 27 RTH sessions, n=57 — larger sample than earlier, more honest aggregate. STRUCTURE_BREAK fired 41 times with 0/37 wins → spawned filter #50 (counter-trend suppression); zero fires since 2026-03-31. Every alert lands in alert_log.db with full feature snapshot + outcome fields (MFE, MAE, target_hit, stop_hit) — new signals ship as shadows first (20,670 shadow rows currently logging passively), validate against data, then promote.

alerts (lifetime)20,979

features / tick73

tickers monitored8

CASCADE+CHARM (n=57)63%

Python 3.11SQLite WALpandasDiscord webhookssystemdStreamlit

svc-market-data-fetcher[INGESTING]uptime 99.95%

market-data-fetcher · real-time data warehouse

Python 3.11 · stdlib + asyncio · WAL · 5 WS hubs + 11 REST endpoints / ticker

WebSocket-only in production since the 2026-03-30 cutover — 5 Azure Web PubSub hubs, 39 tickers, 13 categories, server-side downsampled to 30s buckets. Wire is protobuf-over-zstd with a dual-path decoder. Sole writer; the REST poller (39 × 11 = 429 concurrent / 30s) is `inactive` on disk for instant rollback. Today's outage (11:18 → 14:07 ET) exposed lack of REST passive-failover — issue #92. Per-hub circuit breaker (5 fails → 300s pause), per-task exponential backoff (2s → 120s), batched serial SQLite writer with p99 ~2 ms steady. Stdlib only — no frameworks, no ORM.

ingest / RTH day~487k

rows (live)11.4 M

p99 write2 ms

db size104 GB

Python 3.11asyncioaiohttpSQLite WALprotobufzstdsystemd

── safety gates ─ 20 gates, every trade path

/opt/paisamaker-app/safety/20 gates · all tested

gate	category	fail behavior	tested by
kill-switch L0	kill-switch	system running, entries allowed	test_gex_watch
kill-switch L1	kill-switch	halt entries, exits still run	test_gex_watch
kill-switch L2	kill-switch	flatten all + no new entries	test_gex_watch
max positions global	pre-trade	reject entry, log reason=max_positions	test_signal_dispatcher
max positions per-ticker	pre-trade	reject entry, log reason=ticker_limit	test_signal_dispatcher
max daily loss	pre-trade	halt entries for the day	test_gex_watch
paper-port fail-closed	pre-trade	reject if IBKR port ≠ 4002	test_gex_ibkr_mode
contract validation	pre-trade	reject if 0DTE expiry or class mismatch	test_contract_map
spread gate	pre-trade	reject if bid-ask spread > 30%	test_gex_strike_selector
bid > 0 gate	pre-trade	reject into empty markets	test_gex_strike_selector
fresh quote re-fetch	execution	re-validate drift + spread at submit	test_executor
IBKR mode state machine	state	DATA_ONLY → DEGRADED → WARMUP → FULLY_LIVE	test_gex_ibkr_mode
post-resume warmup	state	60s stability before trading resumes	test_gex_ibkr_mode
position dedup (UNIQUE)	execution	DB rejects duplicate contract_id rows	test_gex_db
idempotent advisor alerts	data	UNIQUE on advisor_alert_id	test_advisor_poller
EOD flatten	exit	force close 15:45 ET	test_exit_lifecycle
EOD panic window	exit	MKT escalation from 15:35 ET	test_exit_lifecycle
max hold time	exit	90m SPX / 60m QQQ / 30m singles	test_exit_lifecycle
exit escalation (3-tier)	exit	LMT@mid → LMT@bid → MKT	test_exit_lifecycle
per-source cooldown	pre-trade	gexwatch doesn't block advisor	test_signal_dispatcher

Every gate returns a specific reject reason that's logged to discord_signals.db.gex_execution_log. No silent failures. Audit by reading the log.

── planned ─ requires read-only VM API

A live alert feed and live trade feed are planned next. Both require a read-only HTTP API on the Hetzner VM that exposes alert_log.db and gex_execution_log to the public internet. About four hours of FastAPI + systemd config, pending a safer deployment posture (rate limits, read-only contracts enforced at the server layer, not trusted from the client).

Live alert feed — tail of the last N alerts with outcome fields
Live trade feed (market hours) — current positions + today's fills
Week-by-week P&L + fill-rate charts
Shadow signal log — signals being validated before promotion

── eof ─