Traadence's Fully Automated Futures Trading is a continuous MES order-sequencing bot for Interactive Brokers accounts. It connects through the Interactive Brokers TWS API using Trader Workstation or IB Gateway, supports paper and live environments, and advances only after a confirmed full fill. The operator defines as many as four buy or sell orders in any sequence; the application owns the handoff between them.
A fill is the trigger. Until the current order is complete, the next order stays locked.
Core Features
| Feature | Description |
|---|---|
| Fill-gated order chain | Premature follow-up orders create exposure the operator did not intend. The state machine waits for broker-confirmed completion before releasing the next configured order, with a hard maximum of four linked legs. |
| Buy and sell sequence editor | Rigid one-direction chains force manual intervention. Each step stores its own side, quantity, order type, price fields, and time-in-force so buy and sell actions can alternate freely. |
| MES contract resolver | Hard-coded expiry months eventually point at an obsolete contract. The resolver queries actual futures contracts through IBKR contract definitions and submits orders against a tradeable FUT, not a chart-only continuous future. |
| Quarterly rollover handling | Expired or thin lead-month references can break unattended execution. The resolver follows the CME equity index roll convention and refreshes the selected MES expiry before a new sequence starts. |
| Paper/live environment switch | Testing logic against a live account is an unnecessary operational risk. The same sequence engine can run against Interactive Brokers paper trading first, then use the live account only when the operator selects it. |
| Reconnect-safe state recovery | A socket interruption should not duplicate a filled leg. The journal persists sequence ID, broker order ID, current leg, fill state, and selected contract so restart logic reconciles before submitting anything new. |
Why Fill Confirmation Controls the Sequence
The bot treats broker execution state as the source of truth, not elapsed time and not an assumed fill. Interactive Brokers exposes order and execution callbacks for this purpose; its order placement guidance documents orderStatus, while execution records distinguish partial fills. A leg becomes complete only when the remaining quantity reaches zero and the order is confirmed filled. Partial fills update the journal but do not unlock the next leg.
MES Contract Selection Without Stale Expiries
MES is the CME Micro E-mini S&P 500 future. CME lists the contract on the March, June, September, and December cycle with a 0.25 index-point minimum tick, documented in the MES contract specification. Because IBKR continuous futures are not orderable contracts, the application resolves a specific live expiry and records its contract identifier before Order #1 is transmitted.
Runtime and Reliability Design
| Component | Implementation choice | Why it fits this build |
|---|---|---|
| Runtime | Python 3 event-driven service | The API workflow is callback-heavy, and Python keeps order-state transitions, reconnect handling, and configuration readable without adding a separate execution framework. |
| Broker adapter | Official Interactive Brokers socket API | The adapter owns connection state, order IDs, contract requests, fill callbacks, errors, and account mode while keeping broker-specific events outside sequence logic. |
| Sequence engine | Finite-state machine | Only one leg may be active at a time. Explicit states such as READY, WORKING, PARTIAL, FILLED, HALTED, and COMPLETE make that invariant testable. |
| Persistence | Append-only JSON event journal | The application can rebuild its last known state after restart and compare that state with broker open orders and executions before taking further action. |
| Supervisor | Long-running OS service wrapper | The process can restart after a local failure while preserving its journal. It does not bypass Interactive Brokers authentication or exchange trading-hour constraints. |
For a production host that already runs an Interactive Brokers session, Traadence can handle trading bot deployment and broker integration around the same packaged runtime without changing the order-state rules.
Performance Benchmarks
| Benchmark | Target | Method |
|---|---|---|
| Active sequence concurrency | 1 working sequence leg at a time | Replay fill events and query broker open orders while each leg transitions from submitted through complete. |
| Partial-fill protection | 0 premature next-leg submissions | Inject partial fills with nonzero remaining quantity and verify the following leg stays locked. |
| Sequence boundary | 1–4 configured legs | Run minimum and maximum chains and confirm the engine finishes at the declared final leg without reading extra configuration. |
| Contract identity | 1 specific MES FUT contract per sequence start | Resolve the expiry before Order #1 and log the broker contract identifier used for all submitted legs in that sequence. |
| Restart duplicate protection | 0 duplicate next-leg submissions after reconciliation | Force-stop the process between broker callbacks, restart it, and compare the journal with open orders and executions before resuming. |
| Control methodology | Documented failure handling and monitored state transitions | Review deployment against FIA automated-trading safeguards and the CFTC automated-orders study. |
Use Cases
- Run a four-step MES entry/exit sequence where a sell order must not exist until the preceding buy has completely filled.
- Alternate buy and sell legs in a predeclared sequence while the application handles order IDs, fill tracking, and progression without manual button presses.
- Validate the same mechanics in an Interactive Brokers paper account before selecting the live environment.
- Keep a long-running MES executor ready across quarterly expiries without editing the contract month by hand before every sequence.
How to Run Linked MES Orders Using Traadence's Fully Automated Futures Trading
Download & Set Up the Project
Download, set up, and install Traadence's Fully Automated Futures Trading to get the project running. If you hit any difficulty, contact us here.
Connect the Broker Session
Run python run.py --mode paper or --mode live; the CLI verifies the TWS or IB Gateway socket and reports the account connection state.
Define the Order Chain
Edit config/orders.json with one to four MES legs: side, quantity, order type, limit or stop price when used, and time-in-force.
Start the Sequence
Run python run.py start. The console reports the active contract, current leg, broker order ID, fill progress, and final COMPLETE or halted state.
Project Directory
mes-order-sequencer/
├── app/
│ ├── main.py
│ ├── broker/
│ │ ├── ib_adapter.py
│ │ ├── callbacks.py
│ │ ├── contracts.py
│ │ └── orders.py
│ ├── engine/
│ │ ├── sequence.py
│ │ ├── state_machine.py
│ │ ├── reconcile.py
│ │ └── rollover.py
│ ├── storage/
│ │ ├── journal.py
│ │ └── models.py
│ ├── config.py
│ └── cli.py
├── config/
│ ├── orders.example.json
│ └── settings.example.json
├── tests/
│ ├── test_fill_gate.py
│ ├── test_partial_fills.py
│ ├── test_rollover.py
│ └── test_reconnect.py
├── requirements.txt
├── README.md
└── run.py
Questions
Can I test the MES order sequence in paper trading before using live mode?
Yes. The application supports Interactive Brokers paper and live sessions through the same execution path, so the fill gate, sequence order, contract selection, and restart behavior can be checked before live use. Switching environments changes the broker session target; it does not change the sequence rules.
How does the bot choose the active MES futures contract at rollover?
It resolves a specific tradeable MES futures expiry before a new sequence begins and refreshes that selection around the quarterly roll. The logic does not send orders to an IBKR continuous-futures symbol, because continuous contracts are for historical-data workflows rather than order placement.
What happens if an order only partially fills or the broker connection drops?
A partial fill leaves the current leg active and keeps the next leg locked. If connectivity drops, the application persists its last state and reconciles broker orders and executions after reconnect; it does not blindly resubmit the next order from local memory.