Overview
SolGlider is execution- and control-first: a trading engine, modular strategy templates, and a dashboard exposing state, metrics, and events.
- Target exchange: NDAX (SOL/CAD).
- Architecture: separation of presentation / logic / data.
- Principle: decisions on closed candles + controlled execution (state machine).
- Traceability: structured logging (trades, errors, events).
Getting Started
Goal: understand the end-to-end flow (data → signal → order → tracking → metrics).
Auth secures access to the dashboard and strategy settings.
e.g., Dip Rebound / Mean Reversion / Semi-auto (as available).
Size, risk limits, entry/exit filters, cadence, etc.
Live / Dry-run / Backtest (as available).
Runtime state (idle/armed/in-position/paused), logs, and PnL summary.
Tip: start conservative; the goal is stable and measurable execution.
Concepts
SolGlider vocabulary is intentionally technical to prevent ambiguity in execution.
State Machine
Typical states: idle → armed → in-position → paused. Prevents inconsistent orders and locks transitions.
Order Lifecycle
Create → place → (open/partial/filled/canceled) → close. Each step emits a logged event.
Data Sources
Ticker (intrabar) for monitoring; closed candles for signals. Reduces noise and stabilizes decisions.
Risk Layer
Loss limits, kill-switch, pauses, max stop-loss/day, and execution safety rails.
Templates
Strategies as parameterized modules, versioned and comparable via metrics.
Observability
Structured logs + metrics: drawdown, winrate, estimated slippage, latency, stability.
API Preview
Preview of typical endpoints (subject to change). The goal is to standardize UI ↔ engine interactions.
GET /api/v1/price?symbol=SOL/CAD
Returns last price and metadata (source, timestamp).
GET /api/v1/bot/status
Returns runtime state and execution summary.
POST /api/v1/bot/start
Starts execution with active config (validation + lock).
POST /api/v1/bot/stop
Stops gracefully (cancel open orders + stable state).
POST /api/v1/config/validate
Validates config: types, bounds, parameter consistency.
Error codes
- 400: invalid parameters (validation).
- 401/403: unauthorized / insufficient permissions.
- 409: state conflict (e.g., start while already in-position).
- 429: rate limit (protection).
- 500: internal error (logged).
Security
SolGlider targets practical security standards: minimize exposure, isolate execution, and trace sensitive actions.
- Secrets: stored server-side (env/keystore), never exposed client-side.
- Sessions: secure cookies (HTTPS recommended), expiry, invalidation on logout.
- Isolation: isolated execution (containers) when available.
- Safety rails: config validation + execution limits (rate limits, timeouts, controlled retries).
- Audit: key events logged (login, start/stop, order errors).
Reliability
A trading platform must prioritize stability: recovery, state consistency, and observability.
- Recovery: controlled restart + state reconstruction (when applicable).
- Network tolerance: timeouts, limited retries, backoff, controlled degradation.
- Consistency: strict state transitions (state machine).
- Logs: rotation + stable format; debugging-friendly events.
- Metrics: drawdown, net PnL, frequency, errors, latency (as available).
FAQ
Is SolGlider financial advice?
No. SolGlider is a technical execution tool. Decisions and risk belong to the user.
Why NDAX only?
Smaller surface area and higher reliability: one solid integration before expanding.
Do you store my keys?
The design aims to keep secrets server-side and minimize exposure. Exact behavior depends on mode and infrastructure.
Is it live now?
Some features may be rolling out. The roadmap describes industrialization steps.