Traadence's Trading Bot Binance is a research-and-execution system built around Binance Spot WebSocket streams that expose a documented 1s kline interval. It ingests closed one-second candles, scores local peak and valley conditions, and converts validated states into timed position decisions. Historical windows can also be pulled through the Binance Spot market-data endpoints so the same signal logic can be replayed before live orders are enabled.
Research first, execution second: every turning-point signal is reproducible, timestamped, and gated before an order can leave the process.
What the one-second research loop actually measures
This system should be understood as a high-frequency bar-based trading engine, not a co-located sub-millisecond market-making stack. One-second candles compress many underlying trades into OHLCV observations, so they can support short-horizon pattern research and position timing but cannot reconstruct queue position or every order-book event. That distinction matters: the research layer evaluates turning points from information available at the decision timestamp, while the execution layer separately records API timing, order acknowledgement, rejects, and fills.
A full 24-hour session contains 86,400 one-second bars per symbol. The replay engine processes those bars in timestamp order and forbids future candles from leaking into the current decision. Peak and valley candidates are confirmed only from the configured historical window, which keeps research results auditable instead of letting centered indicators look ahead.
Core Features
| Feature | Description |
|---|---|
| One-second candle ingestion | Missing or duplicated bars make short-horizon research unreliable. The feed handler consumes closed 1s klines, normalizes timestamps, rejects duplicates, and records gaps before signals are evaluated. |
| Peak and valley scoring | A raw local high or low is too noisy to trade mechanically. The research layer scores turning points using configurable distance, prominence, volatility, and lookback conditions rather than treating every reversal candle as a signal. |
| Replayable quant research | It is hard to refine timing rules when live behaviour cannot be reproduced. Historical sessions run through the same feature and signal pipeline used in live mode, with signal timestamps and reasons written to an event log. |
| Position timing state machine | Independent buy and sell conditions can otherwise fire in contradictory order. A state machine tracks flat, candidate, entry, holding, and exit states so timing decisions have explicit transitions. |
| Order and risk gate | A valid signal can still produce an invalid exchange request. Before routing, the bot checks signal age, position state, and exchange constraints, then submits through the venue adapter. |
| Execution audit trail | Short-horizon systems are difficult to debug from P&L alone. Each decision stores candle time, feature values, signal state, request time, exchange response, and resulting order status. |
Tech Stack
The runtime uses Python asyncio because market-data handling, timers, and order acknowledgements need concurrent I/O without blocking the signal loop. Turning-point research uses SciPy find_peaks as a deterministic primitive for prominence and distance tests, wrapped so only past data is visible at decision time.
Live order requests go through the documented Binance Spot trading endpoints. Before submission, symbol rules are checked against the exchange's price, lot-size, and notional filters, keeping research signals separate from venue-valid order construction.
Research workflow from pattern study to live timing
- Capture: store closed one-second candles with exchange timestamps and gap markers.
- Study: replay sessions and inspect candidate peaks, valleys, volatility context, and false reversals.
- Validate: compare rule variants on held-out time windows without changing the execution code path.
- Promote: move an approved parameter set into paper mode, then enable live routing only after execution logs match expectations.
Performance Benchmarks
The benchmark suite measures mechanics, not trading returns. For each replay or paper session it reports bars processed, dropped-bar count, signal count, p50/p95 decision latency, stale-signal rejects, order-request timestamps, acknowledgement timing, and exchange rejects. A 24-hour replay should account for all 86,400 expected bars when the source session has no gaps; any mismatch is surfaced rather than silently filled.
That separation follows the broader evidence on speed-sensitive markets. The BIS study of high-frequency trading races shows that speed contests can occur on extremely short horizons, while a later BIS study on HFT and market characteristics finds that effects vary across instruments and liquidity conditions. For this bot, feed freshness and execution latency are therefore benchmarked independently from strategy quality.
Use Cases
- Test whether short-lived local highs and lows contain repeatable timing information by replaying the same one-second signal logic across historical sessions.
- Refine entry and exit timing without changing order-routing code, so research iterations stay isolated from exchange integration.
- Run paper sessions that expose stale signals, data gaps, rejected orders, and state-transition errors before live routing is enabled.
- Operate a live short-horizon strategy with an auditable record of what the bot saw, why it acted, and how the venue responded.
For teams moving an approved research rule into production, Traadence can also handle bot deployment and exchange integration, plus monitoring and maintenance around the same execution path.
Project Directory
binance-hft-research-bot/
├── README.md
├── pyproject.toml
├── config/
│ ├── settings.example.yaml
│ └── symbols.yaml
├── src/
│ ├── app.py
│ ├── market_data/
│ │ ├── binance_stream.py
│ │ ├── history_loader.py
│ │ └── candle_buffer.py
│ ├── research/
│ │ ├── turning_points.py
│ │ ├── features.py
│ │ └── replay.py
│ ├── strategy/
│ │ ├── signal_rules.py
│ │ └── timing_state.py
│ ├── execution/
│ │ ├── binance_orders.py
│ │ ├── risk_gate.py
│ │ └── order_state.py
│ └── observability/
│ ├── metrics.py
│ └── event_log.py
├── scripts/
│ ├── replay_session.py
│ ├── run_paper.py
│ └── run_live.py
└── tests/
├── test_turning_points.py
├── test_no_lookahead.py
└── test_risk_gate.py
How to Time Positions Using Traadence's Trading Bot Binance
Download & Set Up the Project
Download, set up, and install Traadence's Trading Bot Binance to get the project running. If you hit any difficulty, contact us here.
Open the Runtime
Launch run_paper.py for paper mode or replay_session.py for research, then confirm the market-data connection and event log are active.
Configure the Signal Window
Set the symbol, 1s interval, lookback length, prominence, distance, volatility filter, and signal-age limit in the project configuration.
Run and Review Output
Start the session, then review timestamped peak/valley signals, state transitions, latency metrics, and order responses in the event and metrics logs.
Questions
Does 1-second candle data make this a true high-frequency trading system?
It makes the system high-frequency relative to ordinary minute- or hour-bar strategies, but not equivalent to sub-millisecond exchange-level HFT. One-second klines aggregate underlying trades, so the bot can research short-horizon timing while remaining unable to observe every order-book event or queue change.
How does the bot detect peaks and valleys without using future candles?
The live and replay pipelines evaluate each candle using only data available up to that timestamp. Turning-point conditions use backward-looking windows and configurable prominence, distance, and volatility tests; centered calculations that require future bars are excluded from decision logic.
Can the research logic be tested before live order execution?
Yes. Historical replay and paper mode use the same feature, signal, state, and risk-gate path as live mode, while keeping order submission disabled or simulated. This lets timing rules and execution-state behaviour be checked before API keys are allowed to place live orders.