Orders & Executions
Supported order types, the order lifecycle, idempotent execution, and reconciliation with the broker — all risk-defined from the start.
Order types
Aegis supports four order types. Orders carry the entry, stop, and target levels produced by a strategy or set manually, so risk is defined the moment an order is created.
| Type | Behavior |
|---|---|
| MARKET | Fills immediately at the best available price. |
| LIMIT | Rests until price reaches your specified level. |
| STOP_MARKET | Triggers a market order once the stop price is hit. |
| STOP_LIMIT | Triggers a limit order once the stop price is hit. |
Order lifecycle
An order moves through clear, auditable states from creation to close:
- Risk check — the order passes the deterministic risk engine; capital is reserved atomically.
- Submission — the order is sent to the broker (exchange).
- Working — the order rests or partially fills until conditions are met.
- Filled / closed — fills are recorded, and the attached stop and target manage the position's exit.
- Cancelled / rejected — reservations are released and the state is logged.
Every transition is written to an immutable audit trail backed by a double-entry ledger, and emitted through a transactional outbox so no state change is lost.
Idempotent execution
Execution is idempotent: each order carries a unique key, so a retry after a network hiccup will not place a duplicate. If Aegis is unsure whether a submission succeeded, it can safely retry without the risk of doubling your position.
Reconciliation with the broker
Aegis continuously reconciles its own view of orders and fills against the exchange. Market data comes from Binance (WebSocket + REST), and order state is checked back against the broker so that fills, cancellations, and partial executions on the exchange are reflected in your ledger and positions. The append-only ledger means reconciled balances always trace back to immutable, summable entries.
For where these executions land in your account, see Risk Management.