← Architecture libraryArchon Merkaba / public architecture

Technical record

Trading Platform

The autonomous trading daemon: tiers, risk gates, and calibration.

Scope note: This document describes architecture, not alpha. Strategy parameters, thresholds, sizing values, capital figures, and venue-specific configuration are intentionally omitted. Nothing here is investment advice.

Overview

The trading platform is an always-on daemon executing systematic strategies on a perpetual futures DEX, with a separate event-market forecasting bot running in paper mode on a prediction-market venue. It has operated live since February 2026 through 350+ deployed change-waves, and it is the system's most demanding proving ground: real capital, an adversarial environment, and no tolerance for silent failure.

Architecture

Rendering diagram…

Multi-tier design. Three time-horizon tiers (scalp / intraday / swing) run as one daemon with shared infrastructure but independent strategy stacks. Tiers can be paused individually — capacity decisions are explicit configuration, not code changes.

Regime awareness. A regime classifier (trending/ranging × risk-on/risk-off) gates which strategies are eligible at any time: mean-reversion always runs, trend-following and breakout require trending risk-on conditions, and so on. An ML regime model runs in shadow mode — its agreement with the production classifier is measured daily (high-80s–90% agreement) and it graduates to control only by passing preregistered promotion criteria.

Signal overlays. A stack of independent overlay filters modulates raw strategy signals. Overlays are measured individually; ones proven dead by data are formally retired through the ADR process rather than left as zombie code.

Sizing and risk. Position sizing derives from Kelly-family logic with configured bounds. A risk gate enforces layered circuit breakers — daily, weekly, and monthly drawdown limits plus a hard equity floor — and a deleveraging band rather than a cliff. A standing philosophy rule: never disable a strategy or direction because of a recent losing sample — structural bugs get fixed; statistical noise gets measured, not curve-fit away.

Execution. Maker-first execution with add-liquidity-only pricing, partial-fill handling, and guaranteed take-profit placement. Fee-awareness is a first-class concern: an early audit found fees consuming an untenable share of gross edge, which reshaped execution toward maker flow and killed churn-heavy behavior.

State Durability: The Real Enemy

The platform's most valuable lesson is unglamorous: over one measured period, the large majority of losses traced not to strategy alpha but to state-loss and reconciliation failures — restarts that forgot positions, orphaned orders adopted with wrong metadata, phantom closes. The response defines the platform:

  • A state-loss gate deployed at the point of maximum blast radius (P0 fix, live).
  • Position adoption as an explicit recovery mechanism with root-caused semantics (the venue's REST API returns incomplete order metadata; recovery classifies orders by reduce-only flags, price geometry, and order-ID recovery instead of trusting it).
  • Reconciliation-first restarts: a single safe-restart entrypoint (hash-aware, notifying, host-level) is the only sanctioned way to restart the daemon — enforced by a pre-tool hook, not just convention.
  • Reboot orchestration: after a VPS reboot incident, autostart ordering was fixed and then proven by an intentional reboot test (~2 minutes of downtime, clean recovery).

Measurement Culture

  • Structured logging: every trade, order event, and decision appends to JSONL logs that downstream analysis treats as the source of truth.
  • Dynamic data cutoffs: analysis code asks a cutoff registry for the valid measurement window per metric — nobody hardcodes "since wave N," so deploys can't silently poison comparisons between old-code and new-code behavior.
  • Calibration pipeline: forecast calibration is tracked continuously with CUSUM change detection and automated resets, with daily health checks reporting by chat-ops.
  • Preregistration: material changes (detector fixes, sizing changes, re-enabling throttles) are preregistered — hypothesis, metric, and decision rule written down before the data comes in. A recent expansion analysis concluded the binding constraint was signal quality, not throttles, and the preregistered plan (measure → select → shadow → canary) was adopted instead of the tempting "just re-open everything."
  • Independent audits: multi-agent audits of the trading stack (the largest: four agents, then nine) produced findings like "kill switches don't actually kill" and "backtest ≠ live semantics" — each converted into tracked remediation waves.

The Forecasting Bot

A separate, smaller system trades weather-derivative event markets in paper mode: it scans forecasts, prices probability against market odds, places paper positions, and runs a daily calibration check journaled to the trading agent's memory. It exists to prove the forecast-calibration loop end-to-end before any real capital touches it — the same graduation discipline as the ML regime models.