This is an old revision of the document!
Trading terminal – design
Concept design for the trade-term application.
How Trading terminal would be built, if the project is carried out. Part of the Stratum project. See also trade-term.
Concept stage. This is a design sketch, not a finished product and not a commitment. The project may still be retired. Nothing here is built yet; it guides development if and when the project is carried out.
Goal
A web application for trading on crypto exchanges: live charts with indicators, several exchanges connected through their APIs, user-defined indicators and strategies, and multi-session trading – several concurrent trading sessions, each running a chosen strategy. Commercial, licensed per subscription through stratum-license. Delivered as a self-contained appliance on a Debian host running Stratum, in the same spirit as VM Reactor.
Chosen stack
| Layer | Choice |
|---|---|
| Backend | Go – a single self-contained service, embedded web assets, own HTTPS port, systemd, users/roles + 2FA |
| Frontend | Vue.js |
| Charts | TradingView Lightweight Charts (Apache-2.0) with an own indicator layer |
| Exchanges | CCXT, run as a sidecar (Node) |
| Strategies / indicators | User scripting in Lua (embedded, gopher-lua) and JavaScript (sidecar), one shared API |
| Licensing | stratum-license, feature trade-term (subscription) |
| Storage | Light and self-contained (SQLite and a compact candle store) |
Architecture
- Go backend – orchestrates everything: market data, sessions, indicators, the licence check (
stratum license check trade-term), the web API and the UI. One binary, like VM Reactor. - CCXT sidecar (Node) – exchange connectivity (market data now, order routing later). The same Node process can host the JavaScript strategy runtime, so JavaScript and exchange access share one component; Lua runs embedded in Go.
- Market data – WebSocket streams from the exchanges, normalised, kept in a compact candle store and pushed to the frontend over WebSocket; REST for history and backfill.
- Indicators – computed in the backend (MA, RSI, MACD, Bollinger, …) and passed to Lightweight Charts as extra series. The same calculation serves charting, backtesting and live sessions – one code path, three contexts.
- Strategy engine – user indicators and strategies in Lua or JavaScript, through one shared API (
ohlcv(),indicator(),order(), …), so strategies are portable between the two languages. The same engine runs backtests on historical data. - Multi-session trading – a session manager; each session is a supervised worker (strategy + account/exchange + symbols + parameters) with its own state (running / paused / stopped), risk limits, a kill-switch, position and P&L tracking and its own log. Paper trading by default; live is a separate, deliberate switch.
Security principles
- Exchange API keys are the most sensitive part – they can move funds: encrypted at rest, trade-only keys without the right to withdraw, exchange-side IP allowlisting, per-session risk limits and a kill-switch.
- Phase 1 is paper trading only – only public market data is needed, so there are no private trading keys at all in the first phase; private keys and live order routing come later.
- The licence is checked at start and periodically; the licence level may cap the number of concurrent sessions or gate live trading.
Phases
- Phase 1 – charts and one exchange (read-only), paper trading, backtesting.
- Phase 2 – live trading with risk limits and a kill-switch.
- Phase 3 – multi-session trading.
- Phase 4 – user scripting of indicators and strategies (Lua and JavaScript).
Risk and compliance
Automated trading with real funds carries financial risk; this is not financial advice. Strategies must comply with the exchanges' terms of service and with the law (no market manipulation). Start with paper trading, risk limits and a small scale.
Decisions (confirmed)
- Charts: Lightweight Charts with an own indicator layer.
- Exchanges: CCXT sidecar.
- Strategy scripting: Lua and JavaScript.
- First phase: paper trading only.