Abstract
A full-stack Flask application that pulls live Binance market data over WebSocket, computes RSI and MACD indicators, evaluates configurable buy/sell strategies, and exposes a JSON dashboard. The interesting part is the architecture: exchange data, indicator math, strategy logic, and web presentation are separated into distinct layers rather than collapsed into a single polling loop.
1. What This Is
I built this as a trading-platform prototype around the Binance API. It is not a single-script bot; it is a Flask web application with user authentication, live market-data ingestion, technical-indicator calculation, and a configurable strategy engine that can trigger orders through the exchange integration.
The repository also includes a browser dashboard driven by JSON endpoints, so the state of the strategy, current indicator values, and account position are observable without reading server logs. That separation made the project useful as a systems exercise in API integration, streaming data, and rule-based automation in one codebase.
2. How It Works
The pipeline runs continuously once a user is authenticated. Market data streams in, indicators are recomputed, the strategy is evaluated, and the result is either surfaced on the dashboard or passed to the exchange when automation is enabled.
| # | Stage | Input | Tool | Output |
|---|---|---|---|---|
| 01 | Auth & config load | User credentials, strategy parameters | Flask, session layer | Authenticated session, loaded config |
| 02 | Market data ingestion | Binance WebSocket stream | Binance API, WebSocket | Current price / market state |
| 03 | Indicator calculation | Incoming price series | Python (RSI, MACD) | Indicator values per symbol |
| 04 | Strategy evaluation | Indicators, profit thresholds | Configurable rule engine | Buy / sell / hold signal |
| 05 | Dashboard exposure | Strategy state, account data | Flask JSON endpoints, JavaScript | Live dashboard update |
| 06 | Order execution | Eligible signal (automation on) | Binance order API | Placed order, updated position |
3. Implementation Notes
3.1 Layered separation over a single loop
The most deliberate design choice was keeping exchange data, indicator math, strategy evaluation, and web presentation in separate modules. A typical trading bot is one while-loop that fetches, computes, and fires orders in sequence. Here, the Flask app owns the HTTP surface, the WebSocket handler owns market state, and the strategy module is a pure function of indicators plus config. That made it possible to inspect or unit-test the strategy without a live exchange connection.
3.2 Configurable strategy, not hard-coded rules
Buy/sell behaviour is driven by strategy parameters and profit-threshold values loaded at session start rather than baked into the code. Switching from an RSI-oversold entry to a MACD-crossover entry means changing configuration, not editing the evaluation logic. The dashboard reads the same config so the operator can see which rules are active.
3.3 WebSocket-driven market state
Rather than polling REST endpoints on a timer, the app maintains a persistent WebSocket connection to Binance for continuous price updates. Indicator values are recomputed incrementally as new ticks arrive, which keeps the dashboard current without the latency and rate-limit pressure of repeated REST calls.
4. Constraints
-
Prototype, not production
No backtesting framework, no paper-trading mode, and no comprehensive test suite. The order path is wired but has not been exercised against real capital. It is a systems prototype, not a claim of trading profitability.
-
Single-exchange coupling
All market and order calls go through Binance. The abstraction layer exists in principle, but adding a second exchange would require concrete adapter work that was not done.
-
Basic access control
Authentication and IP-banning logic are present but minimal. There is no role-based access, no audit log, and no rate-limiting on the JSON endpoints beyond what Flask provides by default.
-
No risk-management layer
Position sizing, max-drawdown stops, and kill-switch logic are absent. The strategy can signal a trade, but nothing downstream caps exposure or halts automation on anomaly.
5. Next
- a. Add a backtesting harness that replays historical candle data through the same indicator and strategy modules, so rule changes can be validated before touching live data.
- b. Introduce a risk-management layer: max position size, daily loss cap, and an automated kill-switch that disables order execution when drawdown exceeds a threshold.
- c. Extract the exchange adapter behind a clean interface and add a second implementation (e.g. Kraken or Coinbase) to validate the abstraction and enable cross-exchange comparison.
— end of report —