Binance Auto Trader
user manual

If this is your first time, just follow these steps

Binance Auto Trader categorizes market conditions in the Binance USDⓈ-M futures market, Trend Following class Mean Reversion Execute your strategy automatically. It is important not to start with actual trading immediately after turning on the program, but to follow the order below.

The fastest way to read this manual

• First-time user: Sign up · API settings → First execution sequence → Backtest step 3 → Live trading check
• Operating User: Trading Settings → Screen Panel → Trade History → Troubleshooting
• User adjusting strategy: Regime → TF/MR → Position Sizing → Backtest Engine

Sign up for Binance and set up API

1. Prepare a Binance account

at the top of the program Sign up for Binance Click the button to open the signup page. Complete account creation, identity verification, and USDⓈ-M Futures activation in order. If you already have an account, skip this step.

2. Generate API Key on Binance

1. 1
   Open API Management
   Go to the API management screen of your Binance account.
2. 2
   Create new API
   Give it a friendly name and complete the security authentication.
3. 3
   Key and secret storage
   A Secret can only be displayed once, immediately after creation, so keep it in a safe place.
4. 4
   Permission settings
   It only enables reading and Futures trading permissions, but does not enable withdrawal permissions.

API permission check

3. Enter API into the program

1. 1
   at the top of the program API Settings Press the button.
2. 2
   API Key and Secret Key Paste . Secret is masked on the screen.
3. 3
   When you first practice Testnet Select and enter the testnet-specific key. The live trading key and testnet key are different.
4. 4
   After saving, check the connection status and balance display in Account Dashboard.

First run order

• 1
  run program
  Run your distribution executable or the latest Python file. Make sure the window title is the current distribution version.
• 2
  Check API connection
  API Settings Save the key and check that the balance appears in Account Dashboard.
• 3
  Setting market and excluded items
  Select the target among CRYPTO / TRADFI / ALL and enter trading restricted or unwanted items one line at a time in Excluded Symbols.
• 4
  Check Cache Manager
  The initial candle download continues in the background. Trading can begin once the latest data is available, but it is better to run long-term backtests only after the cache for the required period is ready.
• 5
  Execute 3 steps of backtesting
  Find candidates with sweep and check for over-optimization with validation and walk-forward.
• 6
  Apply recommended settings and check again
  After clicking Apply Best Settings, directly check whether the Market, Top N, Timeframe, and regime-specific parameters are reflected in the Trading tab as intended.
• 7
  Start with Testnet or a small amount
  Start Auto Trade Press and check Log, Current Top N, Open Positions, and Trade History together.

Recommended starting value (conservative)

Cache Manager

The program uses Parquet-based candle cache. When running for the first time, the necessary candles are built in the background, and thereafter only newly closed candles are incrementally updated.

How it works

• 1
  Check manifest
  When the program starts, it reads manifest.json to immediately check the cache status for each symbol. The manifest is a lightweight index (65KB level) that stores only the first and last candle times of each symbol.
• 2
  Trading first
  Automated trading can begin immediately after obtaining the latest data, and the rest of the history continues to be built in the background.
• 3
  Periodic incremental updates
  We periodically add 4h candles for selected Decision / Execute / Trailing TF and Dynamic TopN volume ranking. After the update is finished, it waits until the next deadline, so the next update is not queued during long downloads.
• 4
  Backtest API Skip
  When running a backtest, the manifest is loaded into memory and an O(1) freshness check is performed for each symbol. If the cache is fresh, only the parquet file is read and returned without calling API. After the cache build is complete, API calls are reduced to 0 in the iterative backtest.
• 5
  safe storage
  Protect existing caches even during shutdown using Atomic Write (.tmp→rename). The manifest is saved in batches up to twice at the end of the backtest pass.

Trading tab

All settings for live automated trading are concentrated in this tab. Setting fields are disabled during automated trading.

default settings

3-TF Entry Engine

The Trend Following strategy uses a three-step timeframe structure that separates judgment and execution. The Decision TF authorizes direction, the Execute TF confirms the actual entry timing, and the Trailing TF manages position close after entry.

Regime Settings

Strategies and parameters are set independently for each regime (QUIET · NORMAL · TREND · PANIC). If checkbox OFF is checked, there will be no new entries in that regime.

Exit Mode Comparison

CI Filter (optional)

Use Choppiness Index (CI) to block trend following entry in sideways movements. Does not apply to Mean Reversion strategies.

Server Stop (Server-side STOP_MARKET)

When entering a position, the Binance server Order STOP_MARKET automatically registers. Even in situations where the bot process is down or the network is down, the exchange will execute the stop loss on your behalf.

Suspension/Emergency Position Close

Trading screen panel

During live trading, you will check the status panel more often than the settings. You can quickly determine the current program status by learning just the four areas below.

Excluded Symbols

Enter the symbols you want to exclude from automated trading, one per line. yes: BTCUSDT. The saved list applies not only to live trading but also to sweep, validation, and walk-forward.

Start · Stop · Emergency Close

Trade History

It shows entry, position close, and realized profit and loss based on the trades managed by the program and Binance conclusion history. When you run the program again, it will load the last three days of Binance trades to supplement your history.

Backtest Sweep Tab

Batch test multiple parameter combinations to explore optimal parameters for each regime. Sweep is the step of testing each regime independently to find candidate settings, and verification of actual time-base adaptive performance is performed in the Validation tab.

Sweep method

Enter parameter list

If you enter multiple values ​​separated by commas (,) in each parameter field, they will be tested as the Cartesian Product of that regime.

# Example: NORMAL regime
ADX Min:  20, 25, 30
ATR Mult: 1.5, 2.0
Vol Mult: 1.2
Trigger R: 1.0, 1.5
Risk %:   0.5

# NORMAL Number of combinations: 3 × 2 × 1 × 2 × 1 = 12

Sweep setup parameters

Sweep Combos Card

This card appears on the right side of the Settings box. Based on the current input value, the number of combinations for each regime, the total, and the estimated time required are calculated in real time.

Interpretation of results

Apply Regime Best

After completing the sweep, click the [Apply Regime Best #1] button and the optimal parameters for each regime will be automatically applied to Regime Settings in the Trading tab.

Backtest Validation Tab

The best settings for each regime selected through sweep are verified using an adaptive method on the actual time axis. By reflecting Top N application, regime conversion, position limits, and profit and loss curve together, we confirm results that are close to actual operation.

Sweep vs Validation Comparison

Walk-forward tab

Entered in the Validation tab single setpoint By repeatedly applying to multiple time intervals, we check how similar the in-sample (IS) performance remains in the out-of-sample (OOS). Walk-forward is not a function of finding profitable settings, but of the settings you have already chosen. Time base generalization stability This is a function to check.

Sweep·Validation·Walk-forward comparison

How it works

# Fix once at run time
Validation Settings Snapshot→ Commonly applied to all Windows W1→ IS calculation + OOS calculation → PF Similarity evaluation W2→ IS calculation + OOS calculation → PF Similarity evaluation W3→ IS calculation + OOS calculation → PF Similarity evaluation

Setting method

① Validation tab — Prepare a single setting to be validated

Enter the settings you want to validate in the Validation tab. You can apply the Sweep results, or use the settings entered directly by the user.

② Walk-forward tab — Period/Window settings

Result Table Columns

Generalization evaluation criteria

last summary window

Recommended Use Procedure

• 1Sweep
  If necessary, explore candidate settings in multiple combinations.
• 2Validation
  See absolute performance including PF, Net PnL, MDD, number of trades, etc. for a single setup of your choice.
• 3Walk-forward
  Check PF Similarity and Generalization Risk of multiple Windows with the same validation settings.
• 4final judgment
  Validation When profitability is sufficient and walk-forward risk is low or acceptable, it is considered as a candidate for practical use.

run-time

Final check before live trading begins

If any of the items below are not confirmed, postpone starting actual trading.

• In the API settings, I selected live-trading mode and live trading API Key rather than Testnet.
• API has only Reading/Futures permission and no Withdraw permission.
• Account Dashboard balance and Binance Futures balance match.
• Sweep candidates were verified through validation and walk-forward at different periods.
• Even in the results including fees and slippage, PF, MDD, and number of trades are within the acceptable range.
• After Apply Best Settings, I checked the values ​​for Market, Top N, TF, and regime again in the Trading tab.
• Trading restricted items and unwanted items were entered into Excluded Symbols.
• Start with conservative values ​​such as Leverage 3 to 5 times, Risk 0.25 to 0.5%, and Max Position 10 to 15%.
• After starting, the live order, server stop, and position quantity are directly compared in the Binance app.
• You can log in to the Binance app to respond even in the event of an internet outage or program termination.

Market Regime Classification

At each closing time ATR% Calculate (= ATR ÷ current price × 100) and classify it into 4 regimes. Strategy and parameters are automatically switched depending on the regime.

Parameter tuning guide for each regime

Trend Following Strategy

Used in the NORMAL · TREND · PANIC regime. EMA cross + Donchian breakout + surge in trading volume + ADX filter Enter when all four conditions are met.

Usage Metrics

Entry conditions (4+1)

Trailing stop mechanism

Trailing TF When the bar standard ATR changes, the trailing distance is also dynamically updated.

Time Exit

After opening a position 72 hours After this period, compulsory position close will occur. It is a safety net that protects against cases where mean reversion fails over a long period of time.

Mean Reversion Strategy

Used in the QUIET regime (ATR% < 2, low volatility sideways). Entry occurs when all three conditions are met: Bollinger Band Breakout + RSI Oversold/Overbought + ADX Max Filter, and returns to the BB middle band (SMA20).

Usage Metrics

Entry conditions (all 3)

Exit logic

Position Close priority

In the position monitoring loop, position close conditions are checked in the following order:

position sizing

Quantity is calculated based on two criteria and the smaller value is used as the final quantity.

Calculation example

# Settings: Balance=1000 USDT, Risk%=0.5, ATR=50, ATR Mult=2.0
# Leverage=5, Max Position%=15, current price=2000 USDT

stop loss          = 50 × 2.0 = 100 USDT
Risk standard quantity  = (1000 × 0.5%) ÷ 100 = 0.05 units
Quantity based on Cap   = (1000 × 15% × 5) ÷ 2000 = 0.375
final quantity       = min(0.05, 0.375) = 0.05 units
# → Notional 0.05 × 2000 = 100 USDT / Margin = 100 ÷ 5 = 20 USDT

WebSocket & API Structure

PriceWebSocketManager

This is a mark-price WebSocket that only subscribes to currently held positions. Automatically resynchronizes subscriptions when you change positions.

UserDataWebSocketManager (UDS)

Receive account events (position changes, order execution) in real time with the Binance User Data Stream.

REST Fallback

If the WS connects but there is no payload for more than 5 seconds, DashboardThread takes a full price snapshot as REST. GLOBAL_PRICE_CACHE Supplements .

API Monitor

You can check the call status of API in real time in the API Monitor panel at the top of the Trading tab.

Troubleshooting

When there is no entry signal at all

WS connection issues

Position related

Backtesting is slow

Disable Apply Regime Best button

If the button is disabled even after the sweep is completed, backtest_results/parameter_sweep_summary.csv The file does not exist. Check the log to see if the sweep was completed normally.

Log interpretation

The format and meaning of messages displayed in the Log window are organized in chronological order. In the message {} Parts are replaced with actual values.

① At startup (Startup)

② Entry signal (Signal)

③ Position opening (Open)

④ Position monitoring (Monitor)

⑤ Close

All exit logs are reason Separate causes by fields.

⑥ Warning & Error

⑦ Backtest log (Backtest)

Example of normal entry to position close log flow

# ① Signal detection
SIGNAL BTCUSDT LONG / trend_following / REGIME=TREND ATR%=5.21 SET=...
# ② Quantity calculation
BTCUSDT sizing: balance=1000.0, available=850.0, risk=5.0000(0.50%), ...
# ③ Entry and conclusion
OPEN BTCUSDT LONG qty=0.050 entry=42000.000000 SL=41520.000000 TRAIL_TRIGGER=42480.000000 ...
# ④ Server stop registration
[SERVER STOP] BTCUSDT LONG stop=41520.000000 orderId=12345678
# ⑤ WS subscription renewal
[WS] Active price stream symbols=3 reason=position_open
# ⑥ Activate trailing
TRAILING ON BTCUSDT LONG trigger=42480.000000
# ⑦ Stop loss update + server stop update (repeat)
TRAIL UPDATE BTCUSDT LONG SL=42200.000000 high=42680.000000
[SERVER STOP] BTCUSDT LONG stop=42200.000000 orderId=12345679
TRAIL UPDATE BTCUSDT LONG SL=42400.000000 high=42880.000000
[SERVER STOP] BTCUSDT LONG stop=42400.000000 orderId=12345680
# ⑧ Position Close + Server stop cancellation
CLOSE BTCUSDT LONG reason=TRAILING_TAKE price=42400.000000 PnL=+20.0000 USDT
[SERVER STOP CANCEL] BTCUSDT orderId=12345680 TRAILING_TAKE

glossary of terms

All terms that appear in the program UI and log are organized in alphabetical order.

Technical Indicators

Setting parameters (Parameters)

Strategy & Regime

Position Close and Risk (Exit & Risk)

Backtest Performance Metrics

Infrastructure and API (Infrastructure)

overall architecture

The program operates divided into GUI, data collection, cache, backtest engine, live trading engine, and order execution layer. The core goal is to keep the stock selection, indicator calculation, entry/position close logic of real trading and backtesting as the same as possible, while improving the repeat execution speed with cache.

architecture diagram

PySide6 GUI
  │
  ├─ Trading Tab
  │    ├─ AutoTradeThread
  │    ├─ Price WebSocket
  │    ├─ User Data Stream
  │    └─ Order / Position Manager
  │
  ├─ Backtest Sweep
  │    └─ BacktestThread
  │
  ├─ Backtest Validation
  │    └─ BacktestThread
  │
  └─ Walk-forward
       └─ WalkForwardThread

Binance REST / WebSocket
  │
  ├─ Public Market Data
  │    └─ Candle Cache
  │         └─ Historical Build
  │              └─ Indicator Cache
  │                   └─ market_data Memory Cache
  │                        └─ Backtest / Validation / Walk-forward
  │
  └─ Private Account Data
       ├─ UserDataStream
       ├─ Position State Store
       └─ Order Engine

main components

data flow

Data comes from REST and WebSocket, passes through cache and memory structures, and is then delivered to the strategy engine. Real trading and backtesting differ only in the timing of execution, and are designed to use the same indicators and conditions as much as possible.

Live trading data flow

Price WebSocket
      │
      ▼
Global Price Cache
      │
      ▼
Position Monitor / Trailing Stop
      │
      ▼
Order Engine
      │
      ▼
Binance Futures

User Data Stream
      │
      ▼
Balance / Position / Order Event
      │
      ▼
Dashboard / Position State Store

Backtest data flow

Binance REST or Local Candle Cache
      │
      ▼
OHLCV DataFrame
      │
      ▼
Historical Build
      │
      ▼
Indicator Cache
      │
      ▼
market_data
      │
      ▼
Dynamic Top N Universe
      │
      ▼
Strategy Signal
      │
      ▼
Virtual Position/Exit Simulation
      │
      ▼
PnL / MDD / PF / Trade Log

Where data is used

cache structure

Cathy is Disk files (retained across restarts) class Memory during execution (maintained for one backtest) It consists of: Each layer divides roles to minimize API calls and disk I/O.

Cache hierarchy

── Disk (remains after restart) ──────────────────────────────

1. manifest.json candle_cache/manifest.json
   first/last open_time index by symbol (65KB level)
   Used to immediately determine cache freshness without calling API

2. Candle Cache (parquet) candle_cache/{SYMBOL}/{interval}.parquet
   Actual OHLCV candle data (100~200KB per symbol)
   CacheUpdateThread only incrementally adds new candles every 5 minutes

── Memory (maintained while running one backtest) ──────────────────────────

3. manifest_cache Load entire manifest.json when backtest starts
   O(1) freshness check for each symbol → Determine whether to skip API
   Only memory is updated during download, saved once to disk when pass ends

4. market_data {symbol: {entry/execute/trailing: DataFrame}}
   Keep parquet read results in memory
   Reuse when parameter combination changes within the same execution (when TF and period are the same)

5. Indicator Cache {symbol: DataFrame with EMA/ADX/ATR/RSI/CI}
   _precompute_indicators() result
   Shared by all parameter combinations within the same run

market_data reuse conditions

When changing parameter combinations within the same backtest run, whether or not OHLCV data (market_data) can be reused is determined according to the conditions below.

Dynamic Top N Algorithm

Dynamic Top N is a function to reduce the difference in stock selection between actual trading and backtesting. Rather than using a fixed Top N list for the entire period, the Top N is re-selected every 4 hours based on trading volume over the past 24 hours.

basic concepts

Every 4 hours:
  1. Sum of quote_volume for the previous 24 hours for each item
  2. Sort by trading volume in descending order
  3. Designate the top N as the active Universe for that 4-hour period.
  4. Continue to manage existing positions
  5. New entries are limited to stocks included in the Top N at the time.

Why Prepare Full Universe Data?

In long-term backtesting, it is impossible to know in advance which stock will enter the Top N due to a surge in trading volume at a specific point in time. Therefore, to maintain the accuracy of Dynamic Top N, the Top N for each 4-hour bucket must be calculated based on the volume data of the entire universe.

2-pass download and ever-active

Only 4h candles are used to calculate trading volume rankings, and strategy TFs (15m/5m, etc.) are downloaded only for symbols that have entered Top N at least once (ever-active). Since the 4h candle is built in advance by the Cache Manager in the background, when running Sweep, Pass 1 mostly performs only cache reads. This drastically reduces the strategic TF download range from full Universe (~500 units) to ever-active (~100 units).

Pass 1: Entire Universe (~500 pieces) × 4h candles
        → 4h cache is pre-built in the background at startup
        → When running Sweep, only parquet is read in the manifest fresh section without API.
        → Dynamic Top N calculation based on 4h vol_data
        → ever_active = Set of symbols included in Top N in any one bucket

Pass 2: ever_active (~100) × Decision / Execute / Trailing TF
        → Configure market_data to be used for actual strategy simulation

※ If ever_active is empty (Pass 1 failure, etc.), "[WARN] Dynamic TopN empty; fallback to static TopN"
  Automatically switches to Static Top N with logs.

Behavior when changing Top N

If you change the Top N value from 50 to 100, the OHLCV data will be reused, and only the active stock list for each 4-hour bucket will be recalculated. Therefore, Historical Build can be reused if the Market, Period, and Timeframe are the same.

How the backtest engine works

The backtest engine operates in the following order: data preparation, indicator calculation, Dynamic Top N generation, signal search, virtual execution, position management, and result aggregation.

execution order

• 1
  Set period
  Determine the test period based on Recent Days or Date Range. An additional warm-up section ahead is secured to stabilize the surface.
• 2
  manifest preload
  Load manifest.json into memory. Afterwards, the freshness check for each symbol operates in O(1) and immediately decides whether to skip the API call.
• 3
  Pass 1 — 4h volume cache load
  Read the entire Universe (~500) × 4h candles. The 4h candle is pre-updated in the background at startup, and if the manifest is fresh, only the parquet is read without the API call. Only the missing sections are downloaded and the results are collected as vol_data.
• 4
  Dynamic Top N generation / ever-active calculation
  Based on vol_data, we build a Top N list for each 4h bucket and derive ever-active (a set of symbols included in Top N at least once during the entire period).
• 5
  Pass 2 — Download Strategy TF
  Only ever-active symbols (~100) read Decision / Execute / Trailing TF candles. Also, when the manifest is fresh, API is 0 times. Collect the results as market_data.
• 6
  Indicator calculation
  Calculate EMA, ADX, ATR, RSI, CI, etc. once per symbol. Sweep passes only OHLCV through the process boundary and calculates it independently when initializing each worker process (reduces pickle transmission). Walk-forward is calculated once in the parent process and then reused by the entire window.
• 7
  signal search
  Create entry candidates by checking the conditions: Regime, Strategy, ADX, Volume/RSI, Donchian/BB.
• 8
  Virtual execution and position management
  Simulate positions by reflecting Risk %, Max Position %, Max Long/Short, Leverage, commission, and slippage.
• 9
  Results Aggregation
  Calculate Net PnL, PF, Win Rate, MDD, Trades, Daily PnL, and performance by regime.

Sweep / Validation / Walk-forward difference

fastening model

Backtesting creates virtual positions without placing live orders. We calculate results close to live trading by reflecting fees and slippage.

Performance Optimization

Backtest speed is Download API → Read SSD (parquet) → Calculate indicator → Execute strategy combination They are divided in order. It is a structure that minimizes each step with cache and skip logic.

Speed ​​by execution situation

List of optimization techniques

Key log interpretation

[Pass 1/2] Download 4h Candles for Volume Ranking: N Symbols
  → Start reading the entire Universe × 4h candle
  zXQPH0000QXZ 0 times if → manifest fresh, only read parquet

[Pass 2/2] Download ever-active N symbol strategy TF
  Read only the symbols in the TopN → at least once Strategy TF

VOL N/M     → {sym} Pass 1 Status
STRAT N/M {sym}   → Pass 2 Progress Status

[WF-VOL N/M]/[WF-STRAT N/M]
  → Walk-forward 2-pass progress status