Binance Liquidation Hunter
A liquidation-cascade trading system fanning entries across nine accounts on two exchanges — run from a live terminal cockpit.
Client engagement — source code stays private. Shown: architecture, flows and UI.
This system trades a signal most bots never see: forced liquidations. It listens to Binance's liquidation websocket streams and aggregates the volume per symbol, side and candle — when a burst lands inside a configured band, that's a potential cascade worth fading. The setup is then validated against RSI, historical volatility and SuperTrend filters before a single order goes out.
Execution is the headline: confirmed signals fan out simultaneously across up to nine accounts on Binance and Bybit — hedge-mode aware, balance-proportional sizing with a slot system capping concurrent exposure. Each account's API client is bound to its own source IP, so per-key IP whitelisting works on a multi-IP server. Exits run automated — trailing stop, safety stop, SuperTrend flip — with operator force-exit always one keystroke away.
The operator runs it from a terminal cockpit: a live matrix of symbols and sides with state glyphs and real-time ROE, a numbered command menu, a TOTP-protected Telegram remote for control from anywhere, and a chart service overlaying liquidations and trades.
Underneath, multiple processes coordinate through SQLite shared state with hot-reloaded configuration — symbols, levels and accounts are editable live, no restart. And the system is paranoid about positions: startup, shutdown and crash paths all sweep every account and hand any stragglers to trailing stops before continuing.
System architecture
The modules that make it up, and how data flows between them.
Forced-liq streams · level scanner
Candles via REST + WS · local DB
Multi-account entries + exit monitor
TOTP remote · balances · force-exit
Live console + liq / trade charts
Hover a module to trace what it feeds.
Trade flow
One liquidation cascade, end to end — from stream burst to multi-account exit.
- 1
Boot & safety sweep
All nine accounts are scanned for leftover positions; any stragglers get trailing stops, and the engine waits until every book is flat before trading.
- 2
Streams up
The liquidation websocket and candle service come online; symbol subscriptions re-sync with the hot-reloaded config every 20 seconds.
- 3
Liquidation burst
Every minute, per symbol, side and level: the candle's liquidation volume is summed — landing inside the configured min/max band arms a trigger.
- 4
Filter gauntlet
All filters passRSI threshold, historical-volatility band and SuperTrend direction (with optional confirmation dwell) all agree — the alert is armed and announced.
Any filter failsThe alert resets and the engine goes back to listening.
- 5
Slot check
A concurrent-trade divisor caps exposure; timeouts, missing data or an operator clear can still abort before entry.
- 6
Fan-out entry
Per enabled account: client bound to its own source IP, balance fetched, size computed from balance ÷ free slots × leverage, margin and leverage set, market order placed — average fill recorded across accounts.
- 7
Monitoring
Open trades are polled on randomized one-to-eight-second intervals against the local candle database — not the exchange — keeping rate limits untouched.
- 8
Exit paths
AutomatedTrailing stop ratchet, fixed safety stop, or a SuperTrend flip (instant or after a dwell time) closes all accounts together.
OperatorForce-exit from the terminal menu or the Telegram remote flattens the trade across every account immediately.
- 9
Books & reports
Trade and P&L databases updated, CSV journal appended, entry/exit messages posted — plus automatic daily, weekly and monthly P&L reports to Telegram.
- 10
Shutdown safety
Exit hooks close bot positions, sweep all accounts for anything left and hand stragglers to trailing stops — the system never leaves a naked position behind.
Engineering highlights
The details that keep it alive with real money on the line.
Per-account source-IP binding
Forked exchange SDKs route each account's HTTPS traffic from its own source IP — making strict per-key IP whitelisting work on one multi-IP server.
Liquidation-stream alpha
Per-candle liquidation volume aggregated by symbol, side and level — a data source that requires real stream-processing plumbing, not just an indicator call.
Never-naked guarantee
Startup, shutdown and crash paths all sweep every account and trail-stop any stray position — no code path ends with unmanaged exposure.
Self-healing streams
Websocket failures trigger connectivity wait-loops and resubscription, with candle gaps backfilled from the last stored close.
Hot-reloaded config
Symbols, levels and accounts live in config files re-read every cycle — the operator edits them while the system trades.
Operator-grade UX
A live terminal matrix, confirmation prompts on destructive actions, and a TOTP-gated Telegram remote — built to be run daily, not demoed once.
Under the hood
The stack, and the system in numbers.