Explicit approval conditions
Checks cover data freshness, the local emergency stop, disk capacity and unresolved orders. A running process alone does not establish trading readiness.
Personal project · Trading systems backend
Auto Trader Token — Order Execution & Risk Controls
An execution core that makes the conditions for sending and stopping orders explicit. Risk checks, an order ledger, protective orders and recovery share a defined workflow, with offline research kept separate from execution.
Content reviewed:
- Stack
- Python · FastAPI · Pydantic · SQLAlchemy · SQLite / PostgreSQL
- Implementation
- Order contracts · risk checks · execution ledger · observation API · operations UI
- Current status
- Fake offline mode by default · optional Testnet observation · Live trading disabled
The problem
Duplicate requests and interrupted exchange responses can leave order outcomes uncertain. The system records approval conditions and execution state together so stale market or account data cannot silently authorize a new entry, and an uncertain order is not immediately resent.
Order processing
Each stage records its state, from order intent through dispatch and reconciliation. General new-entry approval and dispatch are currently limited to the offline simulator.
Observe state
Check freshness of market data, user streams, exchange metadata and reconciliation results.
Assess risk
Evaluate order limits, available margin, open-order exposure and active reservations.
Record and dispatch
Persist approval and pending execution, then recheck approval expiry and policy changes before dispatch.
Reconcile and recover
Keep uncertain responses as UNKNOWN and reconcile them through exchange queries and fill events.
Implementation
Duplicate prevention and protection
Repeated requests return the existing submission. Approved entry and protective-order plans are stored together, and the first partial fill activates the protective-order outbox.
Observation and operations
REST collection and private WebSocket events are coordinated per account. Supporting tools handle data retention, database migrations, database roles and an independent emergency stop.
Separate offline research
Local CSV research checks data timing, cost and latency sensitivity, chronological splits and holdout usage. Research output does not automatically authorize new orders.
Implementation and validation scope
- The offline execution core and optional Binance USD-M Futures Testnet REST and User Stream adapters are implemented.
- A separate Demo validation tool has recorded order, protection and closeout checks. General automatic entry and Live trading remain blocked.
- Local regression tests and real exchange validation are tracked separately for partial fills, uncertain responses and restarts. Additional live-readiness design requirements are not presented as completed implementation.
Implementation references
src/auto_trader/readiness.py · risk.py— Readiness and order risk checkssrc/auto_trader/service.py · database.py— Duplicate requests, ledger, dispatch and reconciliationsrc/auto_trader/observation.py · research.py— Observation collection and offline research