O setup
Comecei com uma estratégia legada (EMA 9/21 crossover) refatorada pra arquitetura conservadora de 3 camadas: análise técnica, machine learning, e um juiz LLM no fim. Universo de 10 moedas (BTC, ETH, SOL, BNB, XRP, ADA, AVAX, DOGE, DOT, LINK). Gestão de risco apertada: 0,4% do capital por trade, cap diário de ±0,8%, no máximo 3 posições simultâneas, e 2 perdas consecutivas encerram o dia.
Stack: Python 3.11, ccxt pra Binance, indicadores na mão
(EMA, RSI, ATR, ADX, Bollinger). XGBoost na camada ML, anthropic SDK no juiz.
Sem ta-lib, sem pandas-ta: controle total da fórmula
e zero dependência nativa pesada.
O gate: walk-forward 70/30
Antes de promover qualquer hipótese pra dry-run, ela tinha que passar por walk-forward IS/OOS 70/30 com critérios fechados:
- Sharpe IS ≥ 0,8
- ≥ 85 trades no período
- Profit Factor ≥ 0,85
- Max Drawdown ≤ 15%
- Sharpe OOS ≥ 0,5
Sem isso, não rodava nem no testnet. Critério fechado antes do teste é o que separa validação de p-hacking.
Os 6 testes
H1: EMA 9/21 crossover (legada)
91 dias de backtest. Sharpe −12,6. Retorno −22,85% vs −7,52% do buy-and-hold. Win rate 13,4%. 0 dos 10 pares positivos. Refutada.
H2: Mesma estratégia, invertida (SHORT espelhado)
Hipótese: se a entrada LONG perde, a saída SHORT ganha. Não. O mercado não é simétrico em torno do sinal. Refutada.
H3: Mean reversion explícita
RSI overbought + bearish candle, sem trend filter. Mesma família estatística, mesmo destino. Refutada.
Resultado da família EMA + RSI + volume: refutada em 2026-05-01.
Hora de mudar de família.
H4: Funding rate extremo (>0,05% × 3 settlements)
Sinal raro: apenas 9 eventos em 91 dias × 10 pares, todos em DOT. Calibração relaxada (0,01% × 3) gerou 109 eventos com EV +0,122% líquido: edge marginal e mecanismo descaracterizado. Descartada antes de gastar slot de walk-forward.
H5: Cointegração formal Engle-Granger ETH/BTC (Z-score >|2σ|)
ADF p<0,10 em apenas 36% do período (vs critério ≥70%).
β oscila 0,67-1,37. Apenas 2 eventos válidos.
Descartada antes de walk-forward.
H6: Funding settlement timing (00/08/16 UTC)
Sinal direcional real existe: funding negativo → +0,083% pós-settlement; funding positivo → −0,113%. Mas a magnitude é 3-6× menor que round-trip cost de 0,30%. Sinal real mas economicamente irrelevante.
Total: 6 hipóteses em famílias estruturalmente diferentes (técnica simples + funding rate + cointegração + eventos calendar). 0 aprovadas.
A pergunta utilitária
Quando bateu a 6ª falha, parei e fiz uma pergunta básica: bot $500/mês com 0h de manutenção, ou SaaS de trading $2k/mês com 10h/mês?
A resposta foi clara: bot $500 com 0h. Renda passiva era o objetivo real, não ownership de produto. Os consultores que recomendavam pivot pra SaaS estavam respondendo à pergunta errada, porque eu nunca tinha explicitado qual era a minha.
A maioria das decisões "técnicas" é decisão de função-utilidade mal formulada. Quando você não sabe o que tá maximizando, qualquer recomendação serve.
O que ganhei
Sem edge, fica fácil dizer que perdi tempo. Não perdi.
-
Framework de validação de hipóteses (
phase1_runner.py): aceita qualquer hipótese nova com 1 comando, faz split IS/OOS e aplica critérios fechados. Reutilizável fora de cripto. - 5 bugs operacionais corrigidos: position sizing errado, TP/SL pós-fill, drawdown guard, sanitização de log. Pré-requisitos de qualquer deploy futuro.
- Convergência forte de 4 fontes independentes (Council interno + 3 especialistas externos): majors cripto retail está estéril no regime atual. Saber isso vale mais que continuar tentando.
- Uma função-utilidade explicitada que vou usar em decisões futuras.
Por que parei aqui
Não é desistência. É decisão consciente com evidência cumulativa. Continuar gastando slot de hipótese no mesmo regime é p-hacking de dimensionalidade: eventualmente eu acho algo que passa por sorte, não por edge real.
O dataset com 74.769 sinais labeled tá pronto pra Kaggle. A biblioteca standalone
cryptobacktest.py (~400 LoC, walk-forward built-in, MIT) tá pronta
pra GitHub. Esses entregam valor independente do edge. Mas não vou ativar agora:
o objetivo era renda passiva, não virar open-source maintainer.
O que isso ensina
- Defina a função-utilidade primeiro. Sem isso, conselho técnico fica ambíguo e qualquer rota parece razoável.
- Gate fechado antes do teste. Critérios numéricos definidos antes de olhar resultado evitam p-hacking.
- Hipótese morta cedo > produto vivo sem edge. Refutar uma ideia ruim no papel é mais barato que descobrir ela quebrada em produção.
- Falha sistemática é dado, não fracasso. 6/6 refutadas em famílias diferentes é informação forte sobre o regime, não sobre minha competência.
O bot tá pausado, esperando ou o regime mudar ou minha função-utilidade mudar. Os dois critérios estão documentados. Sem ambos, fica como está.