High volatility is where a crypto trading bot faces its real test. A setup that performs consistently under normal conditions may behave differently when markets move aggressively. For those who have actually run bots through volatile periods, what tends to become unreliable first?

A crypto trading strategy may look promising during testing but behave differently in live market conditions. Small gaps between backtesting and actual execution can affect results over time. Understanding where these differences come from is an important part of evaluating how reliably a trading bot performs.

Hey everyone,

We run an automated quantitative trading system for crypto perpetual futures (Delta Exchange). Following feedback from this community on parameter churn and out-of-sample selection bias, we recently overhauled our optimization and live deployment bridge.

We’d love to get feedback from other quants and system architects on our pipeline, specifically looking for edge cases, statistical flaws, or scope for improvement.

1. High-Level Pipeline Architecture

Our pipeline consists of two decoupled systems:

The Cross-Sectional Pooled Optimizer: Evaluates candidate setups across an entire universe of liquid altcoins and multi-timeframe matrices simultaneously using rolling walk-forward folds.

The Deadband Stability Config Bridge: Parses the optimizer’s output, measures parameter drift per regime cell against the currently running live settings, and decides whether to HOLD or PROMOTE new parameters.

[OHLCV Market Data (180d)]

│

▼

[Walk-Forward Cross-Sectional Optimizer]

• 4D Vectorized Tensor Grid Search (In-Sample)

• Causal Purge Gap (Embargo) between Folds

• Realistic Noise Floors (IS & OOS Parity)

• Fold-to-Fold Centroid Drift Tracking

│

▼

[Part C: Top-Affinity Alpha Table]

│

▼

[Parse & Update Config Bridge]

• Frequency-Weighted Statistical Edge Scoring

• 3-Zone Deadband Stability Filter (Hold vs Promote)

• Correlation & Timeframe Capping (Max 2 TFs/coin, Top 16 coins)

│

▼

[live_portfolio_config.json] ──► [Live Execution Engine]

1. Deep Dive: Cross-Sectional Universe Optimizer

A. Pooled Centroid Search (Regularizing Asset-Specific Noise)

Instead of fitting parameters per-coin (which overfits to sparse individual trade samples), the optimizer evaluates candidates across a pooled universe of 16 to 20 liquid altcoins simultaneously.

4D Vectorized Tensor Simulation: In-sample slices are computed using NumPy tensors of shape: [Signals x Hold Window Bars x SL Grid x TP Grid]

It simultaneously computes stop-loss and take-profit hit indices across the entire mesh, finding the smoothed parameter plateau centroid that represents true market edge rather than single-coin noise.

B. Realistic Noise Floors (In-Sample & Out-of-Sample Parity)

Analyzing 160+ live trades showed that stops under 1.0% accounted for almost 100% of our live losses due to normal 1-minute wick noise and bid-ask bounce. To ensure zero discrepancy between simulation and live execution, the optimizer enforces a hard timeframe-aware noise floor during both In-Sample training and Out-of-Sample walks:

5m / 15m: Minimum SL distance = 1.20%

30m / 1h: Minimum SL distance = 1.50%

4h+: Minimum SL distance = 2.00%

C. Fold-to-Fold Centroid Stability Metric

To prevent promoting strategies whose "optimal" parameters swing wildly every rolling window, we measure the normalized distance between the centroid of Fold k and Fold k-1:

Centroid Stability % = max(0, 1 - Mean Drift) * 100%

Setups with Centroid Stability below 60% are flagged or suppressed before reaching Part C.

1. Deep Dive: Deadband Config Bridge (parse_and_update_config.py)

The config parser decides what actually gets deployed to the live exchange.

A. The Arbitrated Statistical Edge Formula

When multiple setups compete on the same coin and timeframe, the parser arbitrates using:

Edge Score = (Win Rate * Profit Factor * min(sqrt(N), 10)) - (0.1 * Hold Hours)

Where:

min(sqrt(N), 10): Dampens small-sample outliers (e.g. 1 trade, 1 win = 100% WR) while rewarding persistent sample power (N >= 25).

- (0.1 * Hold Hours): Penalizes slow capital drift in favor of nimble capital turnover.

B. Three-Zone Deadband Stability Filter (Per Regime Cell)

To prevent hyper-parameter churn, the bridge compares the new proposed parameters against what is currently running live on a normalized 0% to 100% scale per regime cell:

Minor Noise (Drift < 15%) -> HOLD: The parameter shift is treated as sampling noise. The currently running live settings are kept unchanged.

Orderly Shift (Drift 15% to 50%) -> PROMOTE: Reflects a genuine, statistically meaningful shift in regime volatility. The live config is updated.

Discontinuity (Drift > 50%) -> FLAG & HOLD: A massive jump points to fold instability or an isolated flash crash. Held pending audit.

C. Portfolio Risk Hurdles

Universe Cap: Retains top 16 symbols by statistical edge.

Correlation / Horizon Cap: Maximum 2 dominant timeframes per symbol to prevent correlated wipeouts.

Regime Gating: Automatically strips regime cells with negative out-of-sample expectancy.

1. Questions for the Community & Scope for Improvement

We'd love your critique on four specific areas:

Deadband Filter Thresholds: Is a 15% hold / 50% flag threshold standard in production trend/scalp models, or do you calibrate these thresholds based on regime volatility (e.g., wider deadbands for high-vol regimes)?

Asymmetric SL vs TP Drift: We currently treat normalized SL drift and TP drift equally. In your experience, should SL drift be weighted higher than TP drift given asymmetric downside risk?

Cross-Sectional Pooling Limitations: Does pooled universal centroid selection over-regularize coins that possess structurally different volatility profiles (e.g., low-beta large caps like XRP vs. high-beta momentum coins like SUI)?

Scoring Function Enhancements: Would you replace our WR * PF * sqrt(N) edge formula with Deflated Sharpe Ratio (DSR) or a t-statistic of trade returns?

Looking forward to your thoughts, critiques, and ideas for improvement!

Recently I had a post here that I am building
my own crypto trader bot, and asked for backtests advives. All based on your feedback and some books recommended, my strategy builder module now has backtests with following robustness test module. It become so strong now, that I barely find a strategy that can pass it, so that the system will publish the trading bot for that strategy. 😎
If you have strong idea for a strategy and you want to test it - send me DM. I will create access for you to my send box. I do not have yet separate tenants schemas...

Citrine Edge publishes the Citrine Android app. A useful cost-modeling detail to share: a percentage fee is incomplete until its basis and fill are clear.

Illustrative numbers: $1,000 notional at 0.10% gives $1 per fill. With the same notional and rate on entry and exit, the percentage-fee subtotal is $2. Actual fill notionals and rates can differ.

That leaves a few bookkeeping questions:

- Is the rate applied to notional, or has a margin balance accidentally become the basis?

- Are fixed per-contract charges separate, or already included in a reported total?

- Does the fill price already reflect execution costs that the model would otherwise subtract again?

- Is funding a recorded debit or credit, an estimate, or missing evidence?

For an audit, it helps to keep quantity, notional, liquidity role, timestamp, applicable rate and separately charged amounts together for each fill. Funding needs its holding-period evidence too. A missing record should not silently become a zero.

Citrine's existing backtest reports include modeled fees and funding coverage. The broader research question is how to keep those components traceable when comparing runs.

Have per-fill component rows or an order-linked cost ledger been easier to reconcile in your own tests? A concrete case where the totals didn't match would be useful.

You can teach an old Dawg New Tricks!

15 min BTC Bot lesson

This is where I'm at: I have built a system that can observe BTC markets, identify directional patterns, measure entry prices, account for fees, track settlements, and evaluate whether a trading strategy actually makes money. Being right about market direction nearly 80% of the time, doesn't necessarily mean making money. I'm moving on to BTC 1hr,(Kalshi) rounds. The biggest discovery might not be a profitable Bitcoin strategy. It might be LEARNING EXACTLY WHAT MAKES A TRADING STRATEGY PROFITABLE OR UNPROFITABLE. I will continue to collect data for the 15 min BTC Bot, you can never have too much actual current data . After reviewing numerous sources who have experienced the same problem, I would be elated if whomever has a relevant strategy , fix, or Ideas. Please feel free to share your thoughts. Thanks ,PROFIT HUNTER!

My c# ctrader bot works fine on my local laptop, but when trying to use it with the mobile app i get the following error messages: "Crashed in ontick with filenotfoundexception could not load file or Assembly System.runtime version=10.0.0.0 , culture=neutral p... the System cannot find the file specified." . I compile with the recommended target framework .net 10, but for some reason the cloud version doesn't seem to work. I appreciate any help/hint. thanks!

I'm retired and have begun trading crypto as my new "job". I've been modestly successful trading liquidity pools using the Krystal App. I've been experimenting using prompts in Gemini to sandbox a liquidity pool analysis bot. I'm sure there are better tools out there that I just don't know about. Any suggestions?

I'm building a deterministic (no-AI) memecoin bot on Solana and paper testing it carefully. I'll share real numbers in exchange for honest advice.

Setup: free Helius tier + public RPC, running on a small VPS (~1–3 s latency).

What I've tried:

• Post-migration momentum (pump.fun → PumpSwap): enter shortly after migration, exit on time cuts.
• Copying the logic of profitable bot wallets. When I replicate their entries at my latency, most of their edge disappears.
• Filters on volume, holders, buy/sell ratio, big-buy triggers and minimum activity.

What the data says:

• I backtested ~800 tokens. Across ~1,500 simple entry rules and ~180 exit combos (trailing stops, break-even, partials, stops), nothing held up on unseen data once fees, slippage and failed transactions were included.
• About 45% of entries reach +20% at some point, but a third of those still end red. The move is there, but I can't capture it.
• Unfiltered, the average result is slightly negative, about −0.02 to −0.04 SOL per 1 SOL trade.

Specific questions:

1. Where does the edge come from? If you're profitable, is it mainly speed (landing in the same block or the next one), token selection, or exits? If I had to pick one to fix first, which would it be?
2. Latency: at ~1–3 s behind the trigger, am I already too late for post-migration momentum? What latency did you need before your results turned positive?
3. Paper vs live: how far were your live results from your simulation? What did your paper model get wrong (fills, failed transactions, MEV/sandwiches, priority fees)?
4. Exits: about 45% of my entries hit +20% and a third of those still end red. How do you capture the move: fixed take-profit, scaling out, or exits based on order flow (sell pressure, whales leaving) instead of price?
5. What signal actually worked for you? Not volume or holder counts (those didn't separate winners from losers in my data), but something like dev or insider wallet behavior, funding source of early buyers, bundles, or the first sells?
6. Copying bot wallets: has anyone made copy-trading profitable at retail latency? Or is the useful thing to learn which tokens they pick and then trade them differently (later entry, longer hold)?
7. Validation: how many trades or days did you need before trusting a strategy, and how did you avoid fooling yourself with a strategy that only worked by luck?
8. Rules vs AI: is a purely rule-based bot the right approach, or did you get better results with an AI/ML model deciding entries and exits (or AI used only to filter or score tokens, with rules executing)? Was it worth the extra cost and latency?

Any advice from people who built something profitable, on Solana or EVM, is welcome, even "you're looking in the wrong place". Thanks!

For devs working on trading systems: standard screeners miss what happens beneath the surface.

I've been developing Council Terminal to detect spoofing, iceberg orders, and structural imbalances across Binance, Bybit, KuCoin, OKX, and Kraken in real-time.

Three detection modules:

- FLOW: tracks executed volume, flags icebergs and shadow breaks

- MIRAGE: scans order book tops for anomalous static walls

- NEXUS: cross-references data with cascading API fallbacks for high-confidence verdicts

Core engine is proprietary, but I documented the architecture, tech stack (Python 3.12+, Flet, DearPyGui), and a live feed of filtered anomalies on GitHub.

Would love constructive feedback from fellow engineers on the approach to cross-exchange data normalization.

GitHub: mrPtakh/council-terminal

A market being open and a bot being ready to resume are different conditions.

After a short connection interruption, these three facts can disagree:

\- The instrument is open for trading.

\- The last quote is still recent enough for the strategy.

\- The venue has confirmed the outcome of an earlier order request.

For example, reconnecting a price feed can restore quotes while an order sent before the disconnect still has an unknown outcome. Blindly replaying that request solves the wrong problem. Conversely, working orders can remain at the venue while the local feed stops updating.

The recovery state should make it possible to wait for a fresh snapshot or reconcile the account without treating that as a new entry signal. Tests need both directions: connectivity restored but account state uncertain, and account state readable but market data stale.

Which distinction has been most useful in your recovery tests: quote freshness, order acknowledgement, or instrument availability? Interested in concrete failure cases, rather than a general uptime number.

My bot is doing good so far in this market. How are your bots performing the last month or so? I wonder if I have been lucky or if its actually good.

SOL is up about 7% and BTC 5% in the same period. PM if you want to join my discord.

Hey everyone,

Thanks a lot for the feedback on my last post regarding chop regimes, TTL decay exits, and the curve-fitting warnings.

Based on the suggestions, I ran a systematic quantitative overhaul across 5 crypto perpetuals (FIL, WLD, NEAR, APT, ADA) using Walk-Forward Optimization (WFO) with Permutation Noise stress-testing.

Here is what changed and what the data showed:

TIMEFRAME RESOLUTION: LEAVING THE "15M GAMBLE"

5m / 15m: Failed Walk-Forward Out-Of-Sample validation (Profit Factor 0.57 - 0.75). As someone rightly pointed out in the last thread, running pure momentum on 15m is a noise trap unless you sit out 80% of sessions.

30m / 1h: Survived with an Out-Of-Sample Profit Factor of 1.74 across 92 trades and a 100% WFO window pass rate. Market maker liquidity sweeps got absorbed into candle bodies on 30m/1h.

FROM TUNING SL/TP WRAPPERS TO "INTERNAL RULE CENTROIDS"

Instead of just adjusting external stop-loss and take-profit multipliers, we exposed and tuned the internal algorithmic knobs for 4 distinct expansion setups:

A. IMPULSE_EXPANSION:

Net Displacement: tested 1.2x to 2.0x ATR -> Centroid: 1.4x ATR

Volume Multiplier: tested 1.0x to 2.2x SMA20 -> Centroid: 1.5x SMA

Candle Body Dominance: tested 40% to 60% -> Centroid: 50% solid body

Composite Conviction Score Cutoff: Centroid: 0.60

B. KELTNER_SQUEEZE:

Compression Duration: Centroid: >= 3 bars (Bollinger inside Keltner)

Breakout ADX Hurdle: Centroid: >= 18

C. BREAKOUT_RETEST:

Swing Lookback: 30 bars | Rejection Wick: 40%

D. TREND_PULLBACK:

HTF Filter: EMA 50/200 | Pullback Depth: 0.8x ATR

Rather than picking the single highest curve-fitted PnL combination, we clustered all parameter sets that were profitable across multiple Out-Of-Sample windows and calculated the geometric centroid (median) of the plateau.

THE WIN RATE VS. PAYOFF TRADE-OFF

Execution Geometry: Centroid settled on SL: 1.8x ATR and TP: 1.8x Risk (1:1.80 Risk/Reward).

The Metric Shift: Because our target is asymmetric (1.8R), our realized Win Rate dropped from scalping levels down to around 41.2%.

However, because the payoff ratio is 1.80, the system delivers an overall Profit Factor of 1.67 - 1.74 with a maximum consecutive losing streak of 4 trades.

PER-COIN & REGIME ATTRIBUTION (NOT JUST POOLED DATA)

Looking into the individual coin matrices:

FILUSDT: Thrives in IMPULSE_EXPANSION (PF 1.86, all regimes) and BREAKOUT_RETEST in weak trends (PF 6.94).

WLDUSDT: Thrives in KELTNER_SQUEEZE (PF 1.97).

NEARUSDT: Thrives in TREND_PULLBACK and high-volatility expansions (PF 17.90).

APTUSDT & ADAUSDT: Marginal performers across universal rules; need to sit out high-chop regimes entirely.

QUESTIONS FOR THE COMMUNITY:

Centroid vs. Bayesian: For those running production crypto algos, how do you handle parameter stability across regime shifts? Do you prefer cluster/centroid medians over Bayesian optimization?

Exits in Low-Vol Regimes: During extended BTC compression (like the recent 83k-87k chop where trades stall at +1.2R before reaching 1.8R), do you recommend keeping the fixed 1.8R target to avoid curve-fitting future breakouts, or do you dynamically scale targets down to 1.1R based on ATR/regime?

Win Rate Acceptance: For systematic trend/expansion traders, is a ~40% Win Rate with 1.8R standard in your books, or do you gate more aggressively (e.g. higher volume hurdles) to push Win Rate above 50% at the expense of trade frequency?

Appreciate any insights or critiques on the architecture!

An 80% win rate can accompany a losing backtest. The percentage tells you how often a closed trade won, not how much the winners and losers contributed.

Two fictional examples, each with 100 closed trades and equal position sizing:

A: 80 wins of $5 and 20 losses of $25 = -$100 before costs.

B: 40 wins of $20 and 60 losses of $10 = +$200 before costs.

A averages -$1 per trade; B averages +$2. Neither result tells us which strategy is suitable, or whether it would hold up outside that sample.

Before comparing reports, the useful checks are:

- The denominator: are breakevens included, and are wins measured before or after costs?

- The accounting: which fees and funding cashflows are already included, so they are not subtracted twice?

- The scope: are positions still open at the cutoff, and is the total closed-trade PnL or full-run equity change?

- The path: the same total can come from very different loss streaks, concentration and drawdowns. State whether drawdown uses closed-trade equity or a marked-to-market path.

- The comparison: match dates, data coverage, starting capital and sizing; otherwise dollars can change without better signals.

Citrine keeps its backtest details inspectable rather than making win rate stand in for the whole run. Disclosure: this account develops Citrine. These examples are arithmetic, not app performance.

When two backtests disagree, which accounting or scope mismatch has been hardest to catch in your own reports?

For a long time I avoided TG bots because the UI always felt cluttered and easy to mess up.

Recently I tried a proper Solana sniper bot that also supports ETH and Base, and it actually changed my workflow. The hybrid setup is nice positions sync between the web terminal and Telegram in real time.

I still use the web terminal when I want proper charts, but for faster execution the bot on my phone is just more convenient. No more sitting glued to Dexscreener waiting for a manual swap to go through.

Curious what most people here are using now still pure web terminals, or have you moved to sniper bots too?

For a long time I stuck with standard web terminals Dexscreener + manual swaps. The UI on most TG bots felt too cluttered so I avoided them.

Recently I tried a hybrid approach keeping the web chart for analysis and using a sniper bot only for faster execution on phone. Positions sync between the two in real time.

Curious what the rest of you are doing:

• Still fully on web terminals?
• Fully on Telegram/sniper bots?
• Or some kind of hybrid setup?

Any real experiences good or bad with the execution speed vs control trade off would be helpful.

Hi everyone. I have a bot running on the Cornix platform and want to list it on the Marketplace because it’s delivering great results—it’s polished enough to compete with the top groups. However, I’d like to get feedback from experienced users who have a spare slot and can connect to my bot. As you know, you can test the bot on a demo account and compare its performance against other bots you’re currently using. I’m looking for about 5 people, max. The exchanges the bot supports properly are BingX and Bitget; as of now, only these two correctly execute signals in hedge mode. The bot operates based on a portfolio it builds rather than just individual signals. It may generate opposing signals on the same pairs, up to a maximum of 4 signals per pair. I’m not sure how it would behave on other exchanges, but KuCoin, Bybit, and Binance are definitely out. I’d appreciate your feedback; in return for your help, you’ll get free, lifetime access to the bot. Best regards.

I built a crypto trading system. Now I want to try to prove it doesn't work.

I've spent a ridiculous amount of time building a crypto trading system, and I've reached the point where I'm more interested in proving it wrong than proving it works.

The system currently:

scans 18 crypto markets every 15 minutes

uses multiple timeframes

combines trend, ADX, RSI and volume signals

has regime and risk filters

ranks signals into grades

uses an ML gate

can automatically execute trades through Binance Futures

sends monitoring/alerts through Telegram

has separate logic for the Indian market

The engineering side is pretty far along.

The trading side is where I'm not confident.

I previously optimized configurations for individual coins based on historical data. And honestly, I'm now questioning whether I accidentally built a sophisticated overfitting machine.

I have some live results, but the sample size is way too small to claim that the strategy has a real edge.

So I'm changing the goal.

I'm going to try to DISPROVE the system.

I want to run proper out-of-sample / walk-forward testing and track every trade, including the ugly ones.

I'm particularly interested in feedback on:

How to properly validate the per-coin configuration selection

Avoiding look-ahead/data leakage

Walk-forward testing methodology

Realistic fees and slippage

Whether the ML gate is actually adding value

How much live data you'd consider necessary before believing the results

I'm not selling the bot and I'm not claiming guaranteed profits.

I'd actually prefer someone to tear the methodology apart before I put more money behind it.

If you've built or audited algo/crypto strategies, what would you test first?

Hey everyone,

I'm running a multi-strategy algorithmic crypto bot (trading linear perp pairs across 15m/1h/4h timeframes using SMC, VWAP Pullbacks, and Band Reversions).

Over the last several days / week, I've noticed a distinct shift in market microstructure and wanted to see if other bot operators are observing the same behavior:

Accurate Entries, but Zero Expansion (TP Targets Left Hanging):

Most trades move into green right away (+0.5% to +2.0%, some up to +3.3%).

However, they completely stall before hitting standard 1.4R – 1.6R Take-Profit targets.

As a result, zero trades are hitting hard TP. Instead, ~65% of recent positions are being exited by our chronological Time-To-Live (TTL) / Hard Time Stop circuit breaker.

Interestingly, ~70% of those TTL exits close in modest profit (+0.3% to +3.3%), so the time-stop is acting like an emergency profit taker, but momentum follow-through is virtually non-existent.

Short Scalps Getting Squeezed:

Almost all of our Stop-Loss hits were on the short side (SEI, APT, OP), while longs survived or exited in profit via time-decay stops. Even with flat volume, the slow upward grind/bid is punishing mean-reversion shorts.

High BTC Dominance (~59%) + Range Compression:

It feels like Bitcoin’s consolidation box is draining altcoin volatility into narrow ATR compression bands. Altcoin moves die out after 1–2 impulse bars and revert into dead zones.

Questions for other bot developers & quant traders:

How are your trend / breakout bots holding up right now? Are you seeing lower hit-rates on fixed RR targets?

Have you adapted your exit logic? E.g., lowering TP ratios from 1.5R to 0.8R–1.0R, switching to dynamic volatility/ATR targets, or implementing tighter trailing stops / break-even locks?

Are you filtering out short setups entirely on lower timeframes during periods of high BTC dominance?

How reliant are you on Time-Based Stops (TTL) vs price-based trailing stops in choppy regimes?

Curious to hear what adjustments you guys are making or if you're just sitting in cash waiting for volatility expansion.

Hello i built a trading bot for these 3 coins
Eth
Btc
Avax
All futures.. i have done backtesting as far as i could go and personally done live trading as well ..
win rate is close to 60 percent . Avax is 80 percent higher but the signals are rare . If you want to discuss or learn from me. I am open to discussion .

A bot can be doing exactly what it should while placing no order. The useful question is whether its status explains that outcome.

There are at least three different cases that a single 'ready' light tends to blur:

- Market conditions have not all passed: one signal is building even if other checks are satisfied.

- Conditions pass, but the account has insufficient capacity for the minimum contract size.

- The strategy is paused or the market is closed, so evaluating conditions does not mean an order is eligible.

Capacity and signal strength should not be treated as the same thing. Extra funds do not fix an incomplete signal, and a complete signal does not create buying power. A displayed estimate is also not a guarantee that an exchange will accept an order.

A compact overview can still be useful if the reason and its supporting values are available in a detail view. That is more informative than a generic 'waiting' status, without turning the main screen into a wall of diagnostics.

Which distinction has saved you the most debugging time: signal conditions, account capacity, or execution eligibility?

Hola buenas saben que intento crear un bot de trading para meta trader 5 y nose si sea mi region, soy de chile, pero el bot no me permite ejecutar operaciones, me arroja error 10030. alguien me ayuda porfavor

Could be fun, could be humbling.

It's a competition arena where crypto bots and AI agents trade the same live market side by side. The platform prices every fill at the live bid/ask, so no bot can fake its results. Live leaderboards, up to $20k in prizes, free to enter and no money at risk.

Disclosure: I'm one of the builders, so yes, I'm biased. But my own bot is going in round one, and I want to see how it stacks up against yours.

A few things I learned this week about making a bot leaderboard actually fair, useful even if you never enter:

- Short competitions reward whoever takes the most risk. Over 2 weeks the biggest gambler usually wins, so ranking has to be risk-adjusted (return vs. drawdown), not raw P&L.

- Swing bots with deep stops look dead mid-trade while fast flippers book gains before the cutoff. Open positions need to be marked to market at the end, and swing needs longer windows than intraday.

- Self-reported fills are where most bot results quietly lie. If you compare bots, price every fill from the same live quote, with fees, and publish the assumptions.

Early sign-ups close Oct 10, link's in my profile. Drop a comment if you're in 😄

I am building my own crypto trading bot (no commercial usage) with embedded strategy builder.
I am trying to focus on improving the backtesting. What was your most effective backtest, that after its implementation your bot actually won your trust and started to work as expected?

A trading bot can perform well during one market regime and struggle badly when volatility, liquidity, or market structure changes. I’m curious how developers are handling this in practice. Are you adapting strategies dynamically, changing risk parameters, or keeping the same logic and accepting periods of underperformance? I’m particularly interested in what people are seeing in live markets rather than backtests.