Stoic Citadel — Reliable Python/MT5 execution
Personal engineering R&D for broker integrations: order handling, persistent recovery and risk checks. The case shows how I design failure paths, without a trading-profit claim.
View the evidenceTimeline
2026
Role
Developer
R&D
Project type
Paper
Execution mode
SQLite
Order journal
Engineering outcome
Order lifecycle · persistent journal · recovery
Honest impact
A bounded paper pilot that makes order state, risk checks and recovery rules explicit, with persistent journalling and independent monitoring.
Evidence from the work
What was built. What you can inspect.
- Delivered scope
- Native Python/MT5 execution architecture, a persistent order journal, risk gates and independent watchdog.
- What was checked
- The repository and local safety-regression boundaries support the architecture description. The diagram is an engineering illustration.
- Evidence limits
- No fresh broker acceptance was performed for this case. The stated pilot boundary is paper mode with entries disabled; no trading edge, completed supervised order round trip or production readiness is claimed.
Engineering case · personal R&D
Native MT5: execution and recovery
The current architecture for a supervised paper pilot. The focus is the order lifecycle and failure handling; the diagram is an engineering illustration of the implemented components.
Native execution path
Paper mode · entries disabledStrategy
A closed-bar signal becomes a versioned intent with a defined lifetime.
Safety and risk
Stop-loss, fresh quotes, volume limits and persistent stop states constrain admission.
Account-bound executor
One lifecycle owner checks account identity and reconciles broker outcomes.
MetaTrader 5
An authenticated bridge forms the broker boundary. Paper mode submits no orders.
SQLite order journal
Persistent intents and checkpoints support restart reconciliation. An unknown outcome does not trigger blind resubmission.
Independent watchdog
A separate process checks exposure and heartbeat, with ticket-specific protective closure paths.
Architecture illustration. This page has no broker connection or trading controls.
Problem
A broker acknowledgement can be lost and a process can restart with exposure open. Recovery must not submit the same order blindly.
The Challenge
Keep one lifecycle owner, check admission before broker writes and reconcile uncertain outcomes.
The Solution
I narrowed the native MT5 pilot to an account-bound executor, authenticated bridge, mandatory SQLite journal and independent watchdog. Redis retains risk and heartbeat state.
Technical Highlights
One native MT5 order-lifecycle owner; legacy Freqtrade/ML research is separate.
Mandatory SQLite journal and broker reconciliation after restart or lost acknowledgements.
Checks for stop-loss, quote freshness, volume constraints and account identity before broker writes.
Independent watchdog and ticket-specific protective closure paths.
Local regressions cover rejected requests, unknown outcomes, persistent stops and recovery boundaries.
Paper by default, entries disabled; negative walk-forward research is retained without a profitability claim.
System Architecture
Python · AsyncIO (native pilot lifecycle)
MetaTrader 5 · account-bound HTTP bridge
FastAPI · authenticated broker boundary
SQLite (mandatory order journal and restart reconciliation)
Redis (risk state and heartbeat)
Independent equity watchdog
Pytest · Hypothesis (local safety regressions)
Docker (persistent local Redis)
Core Technologies
Related Projects
Need a Python system that handles failure clearly?
I build API integrations and workflow backends with explicit states, useful logs and recovery rules. We start with one bounded integration and agree how to verify it.