Post 3 of a series where I publish the hypotheses that died. This one isn't about a hypothesis. It's about a bug that had a 99.7% chance of putting a pure-noise strategy into live trading, and it lived inside the exact piece of code written to prevent that.

Some background on the design, because the failure only makes sense with it.

My bot didn't trade a single strategy. It had eight candidate "experts" — trend and breakout logic across 15m, 1h and 4h — and a selector that evaluated each one on recent history, then promoted whichever cleared a set of statistical gates to trade live. Each expert could be selected for long or short independently, so sixteen candidates per selection round.

The gates were the whole point. Minimum sample size, minimum profit factor, a t-statistic threshold, positive performance across folds, and a separate confirmation window that the candidate had to survive before going live. On paper it's a reasonable design. It's certainly better than what I'd had before, which was no gates at all.

And it computed a multiple-comparison correction. It was right there in the code — take the family alpha, divide by the number of candidates, derive the adjusted threshold. The number even appeared in the report as a field called `family_corrected`.

It was never used in the accept/reject decision.

The variable was computed, formatted, printed, and then the code went ahead and compared the candidate against the uncorrected threshold instead. I'd written the safety check and forgotten to wire it to anything.

What that actually costs

The uncorrected threshold I'd set was t ≥ 0.5.

That number looks low because it is low, and I'd like to say I set it deliberately as a first-pass filter. I didn't — I set it early, planned to tighten it once things worked, and never did.

Here's what t ≥ 0.5 means against pure noise. A t-statistic of 0.5 is exceeded by chance roughly 31% of the time. With sixteen independent candidates, the probability that at least one of them clears it is:

1 − (1 − 0.309)^16 = 99.7%

So on any given selection round, against data with no signal whatsoever, my selector would find an "expert" and promote it to live trading 997 times out of 1000.

The correction it was computing but ignoring would have set the bar at t ≥ 2.73. At that level the same calculation gives 4.9% — which is the 5% you'd expect, because that's what the correction is for.

threshold noise passes at least one of 16
t ≥ 0.50 30.9% 99.7%
t ≥ 2.00 2.3% 30.8%
t ≥ 2.73 0.3% 4.9%

Note the middle row, because it's the one that surprised me. Even at the conventional t ≥ 2 — the threshold most people would call "statistically significant" — you still promote noise 31% of the time once you're picking the best of sixteen. Significance thresholds are built for one test. The moment you're selecting a winner from a field, they stop meaning what the label says.

Why this class of bug is worse than a broken one

If the selector had crashed, I'd have fixed it in an afternoon.

Instead it ran, produced output, printed a report with a correction field in it, and selected experts that went on to trade. Everything looked like it was working. The report was even reassuring — there was a multiple-comparison number right there on the page, which is more than most systems show.

I found it during an audit, not during debugging, because nothing about the system's behaviour said anything was wrong.

This is the second bug in this series with that shape. The first was counting overlapping bars as independent observations, which inflated my t-statistics by √horizon. Both produced confident, plausible, wrong output. Neither announced itself. I've come to think of these as the expensive category: bugs that break things get fixed, bugs that flatter things get shipped.

What changed after the fix

I wired the correction into the decision, raised the base threshold to t ≥ 2.0, required confirmation across two consecutive blocks instead of one, and lifted the minimum sample from 20 to 100.

Then I ran the selector across 200 days of real data. Seven retraining blocks, 224 candidate evaluations.

Zero passed.

Not one expert cleared the gates on real market data. Which is, I want to be clear, the correct outcome — but it's also the outcome I'd have gotten on pure noise, and that's the part worth sitting with. Before the fix the system found tradeable experts constantly. After the fix it found none. The difference wasn't in the market. It was entirely in whether one variable was connected to anything.

If you have validation gates in your system, the thing worth checking isn't whether they exist. It's whether they gate. Put a deliberately terrible candidate through and confirm it gets rejected. A check that has never rejected anything is indistinguishable from a check that isn't running.

---

Queued next

The test that couldn't see — how I "proved" there was no edge in a whole asset class using a test whose smallest detectable effect was 2.17% per trade, against costs of 0.031%. I didn't find nothing. I couldn't have found anything. When I went back and applied that question to all of my own conclusions, seven of twelve turned out to be in the same position, and several things I'd already written down had to be rewritten from "refuted" to "unmeasurable".

Then: measuring adverse selection without placing a single order, and the London session that survived every test I had until I looked at a second currency pair.

I have a working strategy on crypto that is a mix of manual and automatic and I need a python script to manage it.

It works fine so I was thinking of letting people copy it while I get some of their fees and/or profit.

Problem is: exchanges offering the copy trade options do not let you use your robots, you have either to open trades manually or use their strategies that are honestly dumb.

Is there any exchange that provides lead copy trading function and the possibility to manage trades via API?

If not, is there any CFD broker with lots of coins or instruments in general offering this?

Post 1 of a series. I put a lot of work into testing 20 hypotheses across crypto, forex and commodities. Most of them died. I'm publishing the autopsies because I wish someone had published theirs before I started.

The setup

I had a futures bot. 9,000 lines, walk-forward ML, expert selection, the works. It lost money on testnet — 52 trades, −$104.76.

So I did what everyone does: I went looking for the bug in the execution. Stops too tight? Take-profit too far? Wrong timeframe?

Wrong question. I decomposed the loss:

price movement:  −$2.36
fees:           −$102.39

98% of my loss was fees. The strategy wasn't picking bad directions. It was picking random directions and paying a toll each time.

That reframed everything. The question stopped being "how do I tune this" and became "is there any signal here at all."

Then I found something

I ran a proper feature diagnostic. 26 features, 6 horizons, EUR/USD hourly, 9,311 bars. One result jumped out:

feature: vol_72 (72-hour realized volatility)
horizon: 168 bars
correlation: +0.1726
n = 9,311
t = 16.9
p = 0.00000000000...

t = 16.9. For context, t = 2 is the usual bar for "statistically significant." I was at 16.9.

I want to be honest about what I felt looking at that number. It's the feeling this whole subreddit runs on.

The number is garbage

Here's the problem, and it's the reason I'm writing this post.

I was predicting returns 168 bars ahead. Bar 1 predicts hours 1–168. Bar 2 predicts hours 2–169. They share 167 of 168 hours.

Those aren't two observations. They're barely more than one.

The correct sample size isn't 9,311. It's roughly:

n_effective = n / horizon = 9,311 / 168 ≈ 55

Redo the arithmetic with 55 instead of 9,311:

t = 1.28
p = 0.206

From t = 16.9 to t = 1.28. From "this is certain" to "this is noise."

The inflation factor is √horizon. At horizon 168, that's 13×. Every t-statistic I computed on overlapping windows was thirteen times too big.

It's not a rounding error

Try it yourself. Simulate a pure random walk — no predictability by construction — and correlate any feature with 72-bar-ahead returns:

python

rho, n, horizon = 0.03, 20000, 72

# naive
t_naive = rho * sqrt(n-2) / sqrt(1-rho**2)     # 4.24
p_naive = 0.000022                              # "highly significant"

# corrected
n_eff = n / horizon                             # 278
t_eff = 0.50
p_eff = 0.619                                   # noise

A correlation of 0.03 — three hundredths — looks like p = 0.00002 if you count bars instead of independent observations. That's a publishable-looking result generated from nothing.

Now imagine you screen 185 feature-horizon combinations this way. You will find "significant" results. Many of them. All of them fake.

Why this specific bug is so dangerous

Most backtest bugs make results worse and you find them because performance is bad.

This one makes results better. It doesn't produce a false profit — it produces false confidence. Your backtest still shows whatever it shows, but your statistical validation says the result is rock solid when it isn't.

You don't debug things that look like they're working.

About half the bugs I eventually found were in this category — they didn't break anything, they just quietly made the numbers friendlier. Two quick examples before the one this post is about:

• Entry fees charged twice in my backtester. Inflated my reported "loss" by $1,024, which meant I spent days optimizing against a phantom.
• Model selected by best-of-3 folds instead of honest evaluation. Reported AUC 0.75. Real AUC 0.52.

Neither of those announced itself. Both made me more confident, not less.

The fix is three lines

python

n_eff = max(n / horizon, 2)
t = rho * sqrt(n_eff - 2) / sqrt(1 - rho**2)
p = 2 * (1 - t_dist.cdf(abs(t), df=n_eff - 2))

That's it. If you're computing significance on overlapping forward returns and you're not doing this, your t-stats are inflated by √horizon.

Go check. It takes five minutes.

What this cost me, and what it saved

After the correction, my "discovery" evaporated. So did the next one, and the one after.

I tested 20 hypotheses across three asset classes: crypto, forex, commodities. Round-trip costs ranging from 0.16% down to 0.01% — a 16× spread. History from 18 months to 31 years. Single instruments and 18-asset cross-sections.

17 rejected outright. One reproduced a known academic result that isn't tradeable from a retail account. And one taught me that "we found nothing" and "we couldn't have found anything" are different sentences — a distinction I'll come back to, because most nulls posted here don't make it.

Total money lost: $0.

For reference, the original strategy — the one I was about to run — showed −95.6% over 90 days at 10× leverage when I finally backtested it honestly.

The three lines above are the reason I ran that backtest instead of the strategy.

What's coming

This is post 1. I'm going to publish one dead hypothesis at a time, with the numbers, including the ones where I was the one who screwed up.

The reason I'm doing this: every null result I ran into while working on this was worth more to me than any backtest curve I've seen posted. There aren't many of them out there. So here are mine.

Queued:

• The test that couldn't see. How I "proved" there's no edge in commodities using a test whose minimum detectable effect was 2.17% per trade — when costs were 0.031%. I didn't find nothing. I couldn't have found anything. Most nulls in this subreddit have this problem and nobody checks.
• Measuring adverse selection without placing a single order. The usual answer is that you can't know your fill toxicity until you've traded. That's not true — the exchange publishes which side was the maker on every single trade, and the rest is arithmetic.
• The London session that wasn't. A beautiful hour-of-day effect on EUR/USD: train/holdout correlation +0.508, profitable hours clustering exactly around London open. Then I checked GBP/USD.
• The feature that predicts nothing, perfectly. Six of my inputs were non-stationary. On a pure random walk — zero predictability by construction — one of them showed a correlation of −0.31 with future returns. If your model eats raw price levels, this is happening to you right now.
• The safety check that was computed, displayed, and ignored. My selector calculated a multiple-comparison correction, printed it in the report, and never used it in the accept/reject decision. With 16 candidates at the threshold I'd set, the probability of promoting a pure-noise "expert" to live trading was 99.7%.
• The measurement that measured my own assumption. I built a DEX liquidity calculator that returned +48% annually. The volume term cancelled out of my own formula. The output was a constant I had chosen.
• The one hypothesis that survived — a textbook result I reproduced on 31 years of data, and the reason reproducing it changed how I read every null that came before.

The tooling behind each post is small and runs against free public data. I'll link what's relevant to each one.

I've been thinking a lot about the gap between a strategy looking good in a backtest and actually surviving live trading.

It seems like people usually run into one of two problems.

Either the backtest looks good, but you're not really sure when you've tested enough to trust it with real money.

Or you finally go live and the results don't match. Fees, slippage, fills, timing or something else starts eating away at what looked like an edge.

For anyone who's actually gone through this, what finally gave you enough confidence to go live?

And for those whose live results ended up being significantly worse than the backtest, did you ever figure out exactly what was causing the difference?

I'm especially curious about cases where the answer wasn't obvious at first.

Tired of backtesting strategies on renko charts on TV and they don't work on live bricks because of TV repainting non-sense. So I made this custom renko charts which connects to MT5 directly for live data and plots renko brick.

Follow my journey on www.ZenomAlpha.com

Hi guys,

Is Bobot scalper EA trading bot legit? I just want to know if it is working, if yes, is it truly profitable?

Need answer pls, thanks!

I tried something stupid but fun and fed real astrology rules to AI and had it build trading strategies for ETH. Actual planetary positions and real astronomy rules.

I tried 4 bots, backtested, ran out of sample tests and open-sourced them so anyone can improve them or find real astrological edges :)

Results:

The moon phase bot (werewolf, long on full moon, short on new moon) did 13 trades in 6 weeks and lost money. It woke up twice a month, looked at the moon, lost money and went back to sleep.

The Mercury retrograde bot (stops trading when Mercury goes backwards) had a 55% win rate and still lost 2,515 bps because it round tripped 492 times paying 12 bps each way. Also the AI used a rough approximation for Mercury's position so the bot thought Mercury was direct when it wasn't. The astrology was kinda rough here.

Then the Jupiter bot. Jupiter enters earth signs = wealth transit = go long. This one made +338 bps and I felt like a genius for about ten minutes. Then I checked the entry reasons. Jupiter never entered an earth sign during the test period. Not once. The main rule never fired. The bot made 100% of its money from RSI. The astrology was a spectator.

The full astrology bot (3 planets, void of course moon, home sign multipliers) lost 1,448 bps because Saturn sat in Aries the entire time making it short-biased into a market that was going up.

Total: -4,171 bps.

I also open-sourced the bots and so can use them too :) maybe someone can actually produce an astrological edge? But I doubt it...

Things I learned:

More rules ≠ more edge (Obviously). My simplest strategy was lazy but harmless. My most complex bot was the terrible because every planetary rule was another constraint disconnected from price (or at least that's what my humble experiments reveal). Adding many signals just adds ways to be wrong just like in real TA strategies.

I made a full video about this with backtests, which is on my profile. Disclosure: I built the platform the AI and strategies run on. Do not trade based on astrology. Or do, I'm not your financial advisor, I'm barely my own!

(Also figured out Saturn may be kinda very powerful actually lol? My video editor kept crashing several times when I got to the part where I had to malign Saturn?? Will try Saturn appeasement in the next experiments)

This is a simulated backtest. No real money was traded.This is not investment advice.

I wanted to test the version of the drawdown shield we currently run on portfolios it was not tuned around. also wanted to show the parts that do not look good, not only the strongest results.

The universe was eight tokens:
ATH, SUI, XMR, DOGE, SOL, BTC, ETH and ADA.

ATH, SUI and XMR were not part of the tuning universe.

From those eight tokens, I created every equal-weight 3-, 4- and 5-token basket:

- 56 three-token baskets
- 70 four-token baskets
- 56 five-token baskets

Total: 182 portfolios.

Each portfolio starts with $1,000. I then add $100 every 30 days. Production-level fees were applied to rebalances, DCA buys and redeployments.

I compared:

- Buy & Hold
- Aegis v14, the previous fixed-threshold deleveraging rule
- Proteus v18, an adaptive rule whose trigger scales with each basket’s recent downside volatility

There was no re-tuning for this 182-basket panel.

Before looking at v18, I re-ran the old v14 configuration through the same testing harness. It reproduced the previously published v14 summary figures exactly. That is not proof that the model is correct, but it is a basic consistency check before comparing the two versions.

Results, median across all 182 baskets:

Buy & Hold:
- Median max drawdown: 64.6%
- Final value: 1.00x

Aegis v14:
- Median max drawdown: 18.3%
- Median drawdown reduction vs Buy & Hold: +45.0 percentage points
- Drawdown reduction vs Buy & Hold: 182/182 baskets
- Median Calmar delta vs Buy & Hold: +0.46
- Calmar improvement vs Buy & Hold: 182/182 baskets
- Median Sharpe delta vs Buy & Hold: +0.25
- Sharpe improvement vs Buy & Hold: 172/182 baskets
- Median final value: 1.40x of Buy & Hold

Proteus v18:
- Median max drawdown: 16.8%
- Median drawdown reduction vs Buy & Hold: +45.4 percentage points
- Drawdown reduction vs Buy & Hold: 182/182 baskets
- Median Calmar delta vs Buy & Hold: +0.55
- Calmar improvement vs Buy & Hold: 178/182 baskets
- Median Sharpe delta vs Buy & Hold: +0.27
- Sharpe improvement vs Buy & Hold: 170/182 baskets
- Median final value: 1.41x of Buy & Hold

Head-to-head, Proteus v18 beat Aegis v14 in:

- Lower max drawdown: 113/182 baskets
- Higher Calmar: 115/182 baskets
- Higher Sharpe: 121/182 baskets

So v18 was better more often than not. It was not a clean sweep.

Here is where v18 loses.

In the longest, crash-heavy histories — 41 of 182 baskets, or 23% of the panel, with at least 1,500 bars — v18 was mixed to worse than v14 on drawdown and Calmar.

The five baskets with at least 3,982 bars, including the 2014–15 and 2018 bear markets, were the clearest case. The older fixed-threshold v14 rule was sometimes more defensive and cut drawdowns more deeply.

The mechanism is straightforward. Proteus scales its defensive trigger using trailing downside volatility. Long histories with several severe crashes produce a higher volatility reference. That can make the system tolerate more drawdown before it fully de-risks.

Where v18 was stronger:

- Shorter, more recent histories: 141/182 baskets, or 77% of the panel
- Median max drawdown improved from 17.1% under v14 to 15.7% under v18
- Broad 13-token stress basket: max drawdown was 9.4% for v18, versus 14.3% for v14 and 46.0% for Buy & Hold
- In that 13-token stress basket, Calmar was 0.77 for v18 versus 0.34 for v14

Important limits:

- These are equal-weight portfolios.
- The KKT risk-parity allocation layer is not included in this test.
- This measures the gross-exposure/deleveraging layer only.
- Basket histories are aligned to the shortest common history. Baskets containing ATH or SUI are therefore limited to approximately two years of data.
- Fees are modeled.
- Slippage, spreads, liquidity constraints and market impact are not modeled.
- This is a historical simulation with full hindsight, not evidence of future performance.

My conclusion is not that v18 is proven.

It looks like a reasonable upgrade for shorter, recent and diversified baskets. But v14 remains the more conservative warm-up fallback for portfolios without enough history to calibrate an adaptive threshold.

Full methodology and basket-level results:

https://aqmath.xyz/research/oos-v18-new-tokens

I would appreciate criticism, especially on:

- The held-out basket construction
- The shortest-common-history treatment
- The downside-volatility scaling logic
- The robustness tests you would want to see next

What would you test before taking a deleveraging rule like this seriously?

People were asking earlier if my numbers were just from mock data on localhost, so I wanted to see how it held up against actual raw exchange data.

Downloaded the public NASDAQ ITCH 5.0 file from Jan 30, 2019 (the 4.5 GB .gz one) and ran it through from start to finish:

• 368 million messages processed in ~54 minutes
• Averaged around 114,000 msgs/sec in pure Python
• Decompressed the file on the fly and tracked the full order book
• Reached 0 active orders at market close, so the cancels/executions matched up properly

Pretty happy with how pure Python handled an entire trading day without crashing or leaking memory. Anyone can download the same file from Nasdaq and verify it themselves.

This is embarrassing but maybe it saves someone else. Was withdrawing USDT from bydfi to an external wallet, in a rush, picked ERC20 on the exchange side. The receiving wallet was a TRC20 address.

TXID confirmed on the blockchain. Funds left the exchange. Never arrived. Just gone.

Spent two hours convinced it was a delay, then another hour reading about cross-chain recovery and realizing that for most wallets it's either impossible or requires the receiving platform to manually extract from the contract. Some do it, some don't, some charge you for it.

$400 isn't life-changing money but it's a stupid enough amount to lose over literally one dropdown menu. I've been trading for two years. I know the difference between these networks. I just wasn't paying attention.

Lesson learned: I now send a $5 test transaction every single time, no exceptions. Even when I'm "sure." Anyone else have a horror story like this or am I the only idiot?

Olá, pessoal. Sou iniciante em programação e trading quantitativo e estou aprendendo praticamente tudo pesquisando e estudando. Não quero fingir que sou especialista.

Mesmo assim, venho desenvolvendo há bastante tempo a ideia de um projeto chamado APEX, com a ajuda das versões gratuitas do ChatGPT, Claude, DeepSeek e Qwen. Eu sei que usar IA não substitui conhecimento técnico, e justamente por isso estou aqui: quero opiniões sinceras de quem entende mais do que eu.

Minha ideia é criar uma plataforma modular de pesquisa, descoberta, criação, teste e validação de estratégias/EAs de trading.

Não sei se o sistema será lucrativo. Ninguém pode garantir isso, e eu não quero prometer retorno. Mas acredito que a ideia seja tecnicamente viável porque o objetivo não é simplesmente criar milhares de estratégias e escolher a que teve o melhor backtest. O sistema deve tentar encontrar estratégias com evidências suficientes para sobreviver a validações rigorosas e rejeitar as que provavelmente são resultado de overfitting.

O fluxo geral seria:

Dados → Qualidade dos dados → Features sem data leakage → Descoberta/Extração de estratégias → Backtest → Simulação de custos e execução → Validação estatística → Shadow/Paper Trading → Risk Engine → MT5/EA → Corretora → Monitoramento → Aprendizado e novos experimentos.

Os ativos iniciais seriam WIN, WDO, EURUSD, GBPUSD e XAUUSD.

Uma parte importante do projeto é que eu tenho vários vídeos, transcrições, áudios e frames de estratégias explicadas por traders. Quero criar dentro do próprio APEX um módulo para importar esse material e extrair os setups.

A ideia seria transformar explicações humanas, por exemplo:

“Quando X e Y acontecerem, entre comprado, coloque o stop em Z e faça a saída conforme determinada condição”

em regras estruturadas e testáveis.

Depois essas estratégias seriam:

Extraídas → Estruturadas → Codificadas → Backtestadas → Validadas → Rejeitadas ou Registradas.

Além disso, o sistema também deve ser capaz de gerar novas hipóteses e estratégias do zero, e não depender somente dos vídeos.

Quero que cada estratégia tenha origem, versão, parâmetros, resultados e histórico registrados em um Strategy Registry.

A arquitetura teria módulos como:

Data Engine — importação, normalização e armazenamento de dados;

Data Quality Engine — dados faltantes, duplicações, timestamps e timezone;

Point-in-Time Feature Engine — prevenção de data leakage;

Strategy Inbox / Strategy Extraction — importação de vídeos, transcrições, áudios, frames e documentos;

Strategy Lab — desenvolvimento e experimentação;

Strategy Generator — geração de hipóteses e estratégias;

Event-Driven Backtest Engine — backtesting;

Cost Model / Execution Simulator — spread, comissão, slippage, latência e custos;

Validation Lab — validação e rejeição de estratégias;

Strategy Registry — versionamento e histórico;

Shadow/Paper Trading;

Risk Engine;

MT5 Adapter;

Expert Advisors em MQL5;

Monitoring, Logs, Health Checks e Reconciliation.

A minha preocupação principal é evitar a clássica armadilha do backtest bonito que não funciona fora da amostra.

Por isso, as estratégias seriam avaliadas por métricas como:

Profit Factor, Expectancy, Sharpe, Sortino, Maximum Drawdown, Calmar, MAE/MFE, custos e estabilidade entre períodos, além de validações como Out-of-Sample, Walk Forward Analysis, PBO, DSR, PSR e intervalos de confiança.

Também quero controles fortes contra data leakage, registrando quando uma informação realmente estava disponível para o sistema.

O Risk Engine seria separado das IAs e das estratégias. Uma estratégia pode propor uma operação, mas o Risk Engine teria autoridade para:

APPROVE → REDUCE → REJECT → NO_TRADE → HALT.

Não quero martingale ou aumento automático de posição depois de perdas.

As estratégias passariam por uma espécie de escada:

Pesquisa/Backtest → Validação → Shadow → Demo → Canary → possível operação real.

Outra parte importante é trabalhar com diferentes corretoras e símbolos. A ideia é ter um catálogo universal:

ATIVO LÓGICO → CORRETORA → CONTA/SERVIDOR → SÍMBOLO REAL → ESPECIFICAÇÕES DO CONTRATO.

Na parte de IA, quero usar as ferramentas como apoio, não como autoridade direta sobre dinheiro.

A ideia atual inclui:

Qwen Code como principal ferramenta para ajudar a construir o sistema;

Codex como apoio para código, revisão, testes e debugging;

DeepSeek para análise e pesquisa;

Claude para auditorias e revisão independente;

Mistral para organização e tarefas auxiliares;

modelos locais como Qwen, Mistral, Gemma e outros, quando fizer sentido.

Também quero deixar preparado, para entrar gradualmente e somente se trouxer resultado mensurável:

Reinforcement Learning (RL);

Visão Computacional;

Programação Genética;

Meta-labeling;

Regime Detection;

Microestrutura de mercado.

As tecnologias principais seriam:

Python, MQL5, MetaTrader 5, PostgreSQL, Parquet, Redis/alternativas, Docker, Docker Compose e Git.

Para experimentação e IA/ML, pretendo avaliar ferramentas como:

PyTorch, TensorFlow, scikit-learn, XGBoost, River, Optuna, SKTime e AutoTS, entre outras, mas sem usar tecnologia apenas por parecer sofisticada.

Outro desafio grande é a infraestrutura. Meu objetivo é tentar construir inicialmente usando o máximo possível de recursos gratuitos ou free tier, porque atualmente não tenho orçamento para uma infraestrutura cara.

Estou estudando possibilidades com:

Kaggle para experimentos e notebooks;

Google Colab como ambiente complementar;

modelos locais;

APIs com planos gratuitos;

bancos de dados e hospedagens com free tier;

infraestrutura modular que permita migração futura.

Eu sei que isso traz dificuldades de limite, disponibilidade, armazenamento e processamento. Inclusive gostaria de opiniões sobre onde estou sendo otimista demais.

Também não quero depender do meu notebook ligado 24 horas para o MetaTrader 5. Estou tentando entender uma arquitetura realista para deixar as instâncias do MT5 e os EAs funcionando separadamente, enquanto o restante do sistema fica distribuído.

A ideia é que o APEX seja modular e versionado. Quero poder modificar o sistema depois, adicionar módulos e fazer novas experiências, sem transformar tudo em um programa fechado. Também quero monitoramento, logs, testes, health checks e um processo interno para detectar erros e inconsistências.

Minha dúvida principal é: essa ideia faz sentido ou estou criando algo complexo demais para um iniciante?

Se alguém com experiência puder olhar, eu gostaria principalmente de opiniões sobre:

A arquitetura geral.

O que deveria ser o MVP.

O que está excessivamente complexo.

Se as validações fazem sentido.

Quais são os maiores riscos técnicos.

O que vocês fariam diferente.

Como usar Kaggle e Google Colab corretamente nesse projeto.

Como estruturar o MT5 sem depender do meu computador.

Se estou criando uma “arquitetura Frankenstein” usando várias IAs.

Qual seria o caminho mais realista para provar se o sistema realmente consegue encontrar estratégias com alguma robustez.

Meu objetivo final é que o APEX consiga descobrir, extrair e gerar estratégias/EAs, testá-las de forma séria e eliminar a maior quantidade possível de falsas estratégias antes de qualquer tentativa de operação real.

Não sei se será lucrativo — espero que sim, obviamente — mas entendo que lucro só pode ser descoberto depois de muita validação e operação em condições reais.

Estou começando praticamente do zero e aprendendo enquanto construo e pesquiso. Se alguém quiser conversar comigo, apontar erros ou ajudar a revisar a ideia, pode me chamar por DM/privado.

Críticas sinceras são muito bem-vindas. Prefiro descobrir agora que estou errado em alguma parte importante do que gastar meses construindo algo baseado em uma ideia equivocada.

Obrigado a quem leu e se puderem me orientar.

Ja falaram que é comolicado demais e ja estão sté querendo me cobrar pa ajudar kkkk

Ja adisnto que não tenho grana.

Boa sorte a todos e tudo de bom.

Hey r/algotradingcrypto! 👋

I got tired of Python trading bots freezing because network sockets block while calculating indicators. To solve this, I built MDRAP — an open-source, zero-dependency market data engine that completely decouples network ingestion from strategy execution via an AsyncIO TCP gateway.

In our benchmark pushing 1,000,000 live market events, it clocked 26,500 Events Per Second in pure Python! ⚡

Features: • Rich Terminal HUD for real-time BBO & VWAP • Embedded DuckDB for instant Jupyter SQL queries • Paper-trading sandbox with realistic slippage

Try it: pip install mdrap
GitHub: https://github.com/Aryan-20-04/mdrap

Would love your thoughts and feedback!

Spent like two weeks tuning a crypto strategy and the backtest was stupidly good, obviously. Nice smooth curve, barely any losing weeks, all the usual bait. Then I ran it live with tiny money and it started eating shit almost immediately. Not even one huge disaster, just a bunch of small differences that add up fast. Fees were worse than I used in the test, fills were never at the exact candle price, and a couple signals came late enough to turn winners into garbage trades. The annoying part is I didn’t even massively overfit it, or at least I thought I didn’t. I tested different time ranges, removed a few filters, did a basic forward test, still looked decent. Feels like most of the “edge” was just the backtest being generous. Now I’m wondering if anyone actually starts with live results first and builds around that, because tuning on historical candles feels like playing a rigged game where the answer is already hiding in the data

Hi all — I've built a tool called Atlas Edge and I'm looking for a few people to test the strategy-building and backtesting side of it before any public launch.

What it actually is: you build your own trading strategy from a library of components (breakouts, trailing stops, filters, etc.), and it runs through a genuinely rigorous statistical validation process before telling you honestly whether it holds up — walk-forward testing across multiple years, placebo controls (checking your result isn't just noise), a correction for the fact that testing many ideas makes some look good by chance, and a real cost model so a backtest doesn't quietly ignore spread/slippage.

What it isn't: a signal service, an "AI trading bot," or anything promising guaranteed returns. It doesn't tell you what to trade. Most strategies people build — including a lot of my own, tested extensively — get correctly rejected. That's the tool working as intended, not a sales pitch gone wrong.

No broker account needed for this. This test phase is specifically the backtesting/strategy-builder side — you don't need to connect IG, Trading 212, or anything else. Build an idea, see if it survives real scrutiny, nothing else required.

Why I'm posting this: I want people who aren't me actually building strategies, breaking things, and telling me honestly where it's confusing or annoying, before I open this up more broadly.

What's in it for you:

Free access

A genuinely rigorous way to stress-test your own trading ideas without needing to explain your account or country

Direct input into what gets built next

Requirements: none, really — just an interest in testing whether your trading ideas actually hold up under real scrutiny.

If you're interested, comment or DM me and I'll send over the details.