Prime Spot DCA Trading Bot - Case Studies

🎯 Practical Case Studies & Field Tactics

Real-world trade execution guides and field tactics to help you navigate extreme market volatility and manage open DCA positions safely.

1️⃣ Active Defense: Rescuing a Stuck DCA Position Without Stop Loss (-20% Dip)

The "Active Defense" Strategy

This tactic demonstrates how to manually intervene on the GUI to inject an additional, heavy Safety Order (SO) when the market has experienced a deep crash, pulling your average cost down near the local bottom to exit safely with only a minor rebound.

1. The Context (A Stuck Position)

Imagine running a spot DCA strategy with Stop Loss disabled (use_static_sl = False). The bot executed the initial Base Order (BO) and completed all 3 pre-configured Safety Orders (SO1, SO2, SO3). Suddenly, the market takes an unexpected -20% dive. The bot runs out of configured safety orders, sits idle, and holds floating negative PnL while waiting for price recovery.

2. The Problem

  • Waiting for a 20% natural rebound to break even can lock capital for weeks or months.
  • Executing Panic Sell immediately locks in a painful loss.

3. The Solution: Expanding Safety Orders in Real-Time

When technical analysis shows the price has reached an oversold area and formed signs of a local bottom, you can modify configuration on the GUI to inject a heavy SO4 order:

Step 1: Configuration on GUI
  1. Max SO orders: Increase from 3 to 4 (authorizing one more DCA order).
  2. SO order price step: Add the new threshold. If the previous steps were 2.0, 4.0, 6.0, update to 2.0, 4.0, 6.0, 15.0 (setting the trigger at -15%).
  3. SO capital multiplier: Increase this multiplier (e.g., 2.0 or higher) so that SO4 enters with double the Base Order capital, adding sufficient weight to pull down the position's average price.
  4. Click SAVE CHANGES TO THIS PAIR.
Step 2: How the Bot Executes the Rescue
  • Signal Recognition: Drop triggers remain anchored to the initial Base Order price (base_order_price). Because market price (-20%) has dropped beyond the new trigger (-15%), the buy condition is instantly validated.
  • Safe Ledger Memory: The bot tracks filled orders via internal state (buy_count). Completed SO1, SO2, and SO3 orders are preserved; the higher multiplier will only apply to SO4 and future orders without retroactively purchasing for past levels.
  • Optimal Taker Execution: Even though the trigger was set to -15%, the bot routes a LIMIT BUY at the current market price (-20%), immediately filling at the bottom rather than buying higher at -15%.
  • Aggressive Average Down: Sinking significant capital at -20% aggressively lowers the position's average buy price (buy_price).
  • Dynamic TP Recalculation: Take-profit target prices (TP1, TP2, TP3) dynamically recalculate from the newly reduced buy_price, moving the exit lines dramatically lower.

4. The Outcome

The market no longer needs to recover 20%. A realistic bounce of just 4% - 5% from the bottom will easily touch the newly lowered Take Profit targets, triggering liquidation to release 100% of the invested capital safely.

⚠️ Crucial Execution Notes

  • Post-Rescue Multiplier Reset: Once the rescue order fills, either restore SO capital multiplier back to standard or turn on an indicator filter (e.g., RSI). This prevents the bot from opening the next fresh cycle with an oversized multiplier on an unfiltered entry.
  • Available Balance: Ensure your wallet holds sufficient free USDT for SO4; otherwise the server logs an insufficient balance warning and skips execution.
  • Complete Liquidation: Set tp3_sell_percent to 100.0 if you are not running Trailing TP/Dynamic TP, ensuring no residual dust remains after exit.
  • RSI Bottom Safeguard: If use_rsi is active, ensure the current RSI value has not dipped below rsi_min, which pauses purchases during severe panics.
2️⃣ The "Falling Knife" Guard: Surviving Flash Crashes with RSI Limits

Avoiding the "Falling Knife" Trap

This case study explains how the bot's dual-layered RSI filtering mechanism prevents your account from blindly buying into a vertical market crash (catching a falling knife), ensuring your capital is deployed only when the panic subsides.

1. The Context

You are trading a volatile altcoin and want the bot to automatically accumulate positions during market dips. You set up a DCA strategy with price steps of -4%, -8%, and -15%.

2. The Problem (Blind DCA Risk)

If a "flash crash" occurs and the coin plummets vertically by -20% in just a few minutes, a bot without indicator filters (Blind Buy) will instantly trigger the Base Order and all subsequent Safety Orders on the way down. It burns through your entire DCA capital reserve before the coin even reaches the true bottom.

3. The Solution: The rsi_min Safeguard

By using the bot's advanced RSI configuration, you establish a strict "no-trade zone" during extreme market panic. On the GUI, you configure:

  • Enable RSI: Checked (use_rsi = True).
  • RSI Oversold (<): 30 (Start looking for buy opportunities when RSI drops below 30).
  • RSI Minimum (>): 20 (The absolute panic threshold).

4. How the Bot Executes the Defense

When the flash crash happens, the price drops violently and the RSI plummets directly to 12. Here is how the bot's logic protects your capital:

Shielding the Base Order (BO):

The bot's algorithm demands that the RSI must be strictly *between* rsi_min and rsi_oversold. Because the RSI (12) is below your rsi_min (20), the bot refuses to open a Base Order. It sits idle, letting the knife fall until the selling momentum exhausts and the RSI curls back up above 20.

Freezing the Safety Orders (SO):

What if the bot had already purchased the Base Order *before* the crash? As the price slices through your -4% and -8% DCA thresholds, the bot evaluates the conditions. Because the extreme selling pressure has forced the RSI below your rsi_min of 20, the bot completely freezes all DCA purchases. It ignores the price drops and protects your backup capital, refusing to average down on a free-falling asset until the RSI recovers above the 20 mark.

💡 Strategic Takeaway

The rsi_min parameter is your ultimate shield against market capitulation. If you trade highly volatile assets (like meme coins), setting a tighter rsi_min (e.g., 25) ensures the bot waits for structural stability before deploying your hard-earned DCA capital.

3️⃣ Riding the Pump: Maximizing Breakouts with Trailing Take Profit

Catching the Entire Wave on Volatile Assets

This case study illustrates how to abandon fixed profit targets and let the bot dynamically ride massive price pumps, only exiting when the momentum finally dies.

1. The Context

You are trading a low-cap altcoin or meme coin known for sudden, explosive upward movements. You want to capture as much of the pump as possible.

2. The Problem (Selling Too Early)

If you use standard Static Take Profit (e.g., selling at a fixed +3% or +5%), the bot executes perfectly, but you might watch in frustration as the coin continues to pump 20%, 50%, or 100% right after you sold. You missed the lion's share of the move.

3. The Solution: Trailing Take Profit

Configure the bot to ignore fixed exit lines and instead follow the price upwards:

  • Use Static TP: Uncheck this box (use_static_tp = False).
  • Use Trailing TP: Check this box (use_trailing_tp = True).
  • Min Profit Percent: Set to 2.0 (The bot won't activate trailing until you are at least 2% in profit).
  • Trailing TP Percent: Set to 1.0 (The bot will sell if the price drops 1% from its absolute peak).

4. How the Bot Executes the Trade

  • Activation: When the price pumps and crosses the +2% threshold, the bot does not sell. Instead, it activates the trailing mechanism.
  • Tracking the Peak: As the price surges to +10%, +20%, and +30%, the bot constantly updates the highest_price in its memory. The exit trigger line automatically drags itself up, staying exactly 1.0% below the new peak.
  • The Exit (Market Sell): The moment the pump exhausts and the price drops 1.0% from the highest recorded peak, the bot instantly fires a MARKET SELL order. By using a Market order instead of a Limit order, the bot guarantees the exit even if the price is crashing fast, successfully locking in a massive profit.
4️⃣ Quarantining Toxic Assets: Risk Management with Isolate Manager

Stopping the Bleeding on Doomed Coins

This tactic shows how to disconnect a specific coin from the DCA engine when extreme bad news hits, protecting your capital from being dragged down by a dying asset.

1. The Context

The bot is running standard DCA on a pair. Suddenly, the project gets hit with severe FUD (e.g., developers dumping, threat of delisting, or a major hack), and the chart is collapsing.

2. The Problem (The DCA Trap)

The bot's discipline becomes a liability here. As the price crashes, the bot will obediently buy SO1, SO2, and SO3, throwing good money after bad into a coin that might never recover. If you hit Panic Sell, you take a devastating realized loss immediately.

3. The Solution: The Isolate Manager

You can freeze the asset without immediately realizing the loss:

  1. Look at the Real-Time Status table on the GUI.
  2. Right-click the collapsing pair and select "Isolate this pair".
  3. Enter a target recovery price (e.g., hoping for a "dead-cat bounce" to exit with a minor loss or at break-even).

4. How the Server Handles the Quarantine

  • DCA Freeze: The Server immediately strips the coin from the active SYMBOL_STATES configuration. The bot is completely forbidden from buying any more Safety Orders for this pair, securing your USDT balance for other, healthier coins.
  • Background Monitoring: The coin's data is transferred to a dedicated ISOLATED_ORDERS ledger. A separate background loop continuously monitors its price without interfering with your main trading activities.
  • Automatic Sweep: If the market gifts you a sudden relief rally and hits your target price, the bot executes a full MARKET SELL, clears the bag, and logs the success—all completely hands-off.
5️⃣ Surviving the Whipsaw: Avoiding Stop-Loss Hunts with Dynamic SL (ATR)

Adapting to Market Volatility Automatically

This case demonstrates how to use the Average True Range (ATR) indicator to make your Stop Loss flexible, preventing "whales" from hunting your stop-loss during choppy market conditions.

1. The Context

The market is in a sideways, choppy phase. Price action is erratic, featuring long wicks (whipsaws) designed to liquidate high-leverage traders and trigger stop-losses.

2. The Problem (Rigid Stop Losses)

If you use a fixed Static SL of 5%, a random market wick can easily drop 5.1%, trigger your Stop Loss, and then immediately shoot back up into profit territory. You took an unnecessary loss because your stop was rigid.

3. The Solution: Dynamic Stop Loss via ATR

Let the bot measure the market's "heartbeat" (volatility) and adjust the stop distance accordingly:

  • Use Static SL: Uncheck (use_static_sl = False).
  • Use Dynamic SL: Check (use_dynamic_sl = True).
  • ATR Period: 14.
  • Dynamic SL Multiplier: 2.0.

4. The Technical Execution

  • Volatility Tracking: Every time a candle closes, the bot calculates the ATR (Average True Range) to determine how wildly the price is swinging.
  • Elastic Defense: During high volatility (wild swings), the ATR value expands. The bot dynamically calculates the stop price as buy_price - (multiplier * ATR). This pushes your Stop Loss further away, safely out of reach of malicious wicks.
  • Tightening the Net: When the market calms down and volatility shrinks, the ATR value decreases, automatically pulling your Stop Loss tighter to protect your capital strictly.
6️⃣ The "Dust" Sweeper: Auto-Merging Small Orders (Min Notional Limit)

Flawless Execution on Micro-Budgets

This case explains the bot's built-in intelligence that prevents your trading cycles from crashing due to exchange-imposed minimum trade limits.

1. The Context

You are testing a strategy with a very small budget, allocating only 10 USDT for your Base Order, and using a 3-tier Static Take Profit (e.g., TP1 sells 40%, TP2 sells 60%).

2. The Problem (The Exchange Reject)

Binance enforces a strict "Min Notional" rule: every single buy or sell order must be worth at least 5 USDT. If you instruct the bot to sell 40% of a 10 USDT position at TP1, the order value is only 4 USDT. Normally, the exchange would reject this, causing the bot to crash and leaving your position stuck forever.

3. The Solution: The Server's Auto-Merge Engine

You do not need to do any manual math. The Server handles this completely automatically in the background:

  • Proactive Evaluation: Before placing any partial sell order (like TP1), the Server calculates the USD value of that specific slice (e.g., 4 USDT).
  • Intelligent Roll-Over: Since 4 USDT is below the 5.5 USDT safety threshold, the Server intentionally skips the API call to Binance, avoiding the error. It marks TP1 as "triggered" internally but rolls the 4 USDT volume forward into the TP2 allocation.
  • Successful Exit: When the price hits the TP2 level, the bot combines both slices (40% + 60% = 100%, worth 10 USDT) and places a single, valid order that clears the exchange's minimum limit.
  • Dust Evaporation: If a leftover piece of a position somehow drops below 5 USDT and no further TP levels exist, the bot detects this "dust" and resets the cycle automatically to prevent the bot from being permanently paralyzed.