Files

T

Adriano Dal Pastro 14522262e6 chore(reset): v2.0.0 — storico certificato Deribit mainnet, ripartenza pulita

Reset del progetto su fondamenta verificate dopo la scoperta che l'intera
libreria "validata OOS" era artefatto di feed contaminato (print fantasma del
feed Cerbero TESTNET + storico Binance/USDT).

- Storico ricostruito da Deribit MAINNET (ccxt pubblico, tokenless) e
  CERTIFICATO (certify_feed.py): BTC/ETH puliti su TUTTA la storia
  (mediana 2-6 bps vs Coinbase USD), integrita' OHLC + coerenza resample
  (maxΔ 0.00) + cross-venue OK. Alt esclusi (illiquidi/divergenti: LTC/DOGE
  50-82% barre flat; XRP/BNB non certificabili).
- Verdetto sul feed pulito: FADE / PAIRS / XS01 / TSM01 morti (ogni
  portafoglio Sharpe -2.3..-3.0, DD ~40%); solo SH01 e frammenti HONEST
  con segnale residuo, da ri-validare in isolamento.
- Cleanup "restart pulito": strategie, stack live (src/live, src/portfolio,
  runner/executor, yml, docker), ~100 script ricerca/gate, waste/games/
  portfolios, dati non certificati + cache e 60+ diari -> archiviati in Old/
  (preservati, non cancellati). Diario consolidato in un unico documento.
- Skeleton ricerca tenuto: Strategy ABC + indicatori + src/fractal +
  src/backtest/engine + load_data; tool dati certificati (rebuild_history,
  certify_feed, audit_feed, multi_source_check).
- Universo dati ATTIVO: solo BTC/ETH (5m/15m/1h); guardrail fisico
  (load_data su alt -> FileNotFoundError). Esecuzione DISABILITATA, conto flat.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-19 15:20:59 +00:00

2.5 KiB

Raw Blame History

2026-06-13 — Report ricorrente LEDGER REALE vs BACKTEST (il gate per scalare)

Perché

Domanda dell'utente: "come cresco il capitale a 12k". Risposta: il prerequisito prima di mettere soldi veri è che il ledger reale combaci col backtest — soprattutto lo slippage del 15m appena deployato. Questo report rende quel gate un dato osservabile, non un'opinione.

Insight chiave: per gli sleeve eseguiti (6 fade 15m, DIP01, 6 pairs, SH01) il sim del worker == backtest canonico PER COSTRUZIONE (validato). Quindi "reale vs backtest" = "reale vs sim" = la fuga di esecuzione: slippage + fee reali vs assunte + effetti netting/phantom/sim_fallback.

Cosa misura

scripts/analysis/ledger_vs_backtest.py (read-only: solo trades.jsonl + status.json, nessuna rete → affidabile in cron):

PnL realizzato sim vs reale (Σ e per-trade) → LEAKAGE € e per-trade (bottom line)
slippage ingressi (REAL_OPEN) e uscite-a-mercato (REAL_CLOSE; escluse le uscite da TP resting, fill maker al livello = no slippage)
fee reali vs assunte (0.10% RT)
trade sim_fallback (reale mai eseguito/fillato) = quota NON coperta dal reale
ledger per-sleeve: real_capital vs capital (sim)
verdetto 🟢/🟡/🔴: <10 trade = campione piccolo; leakage basso+slippage ≤15bps = verde (si può pensare a scalare); slippage >40bps = rosso (edge erode, NON scalare)

Clean-start (importante)

Una finestra mobile pura includerebbe l'incidente testnet pre-fix: a 7g il report dà sim +82 vs reale +5 (🔴) — ma è gonfiato dai +4% FANTASMA che il sim bookava e il reale no, prima di TP_PHANTOM (v1.1.23), netting (v1.1.25) e ribilancio-conservativo (v1.1.31). Lo scheduler usa --since 2026-06-13 → accumula SOLO dati post-fix, e diventa statisticamente significativo coi giorni. Finestra pulita oggi: 1 trade, leakage +0.07, slippage ingresso 12-29 bps.

Scheduling

Cron host (come reconcile/hourly_report), giornaliero 08:30 UTC: ledger_vs_backtest.py --since 2026-06-13 --telegram → Telegram + log in ~/port06_ledger_vs_backtest.log. Invio verificato.

Come usarlo

Quando il campione supera ~10-20 trade reali e il verdetto è 🟢 stabile per qualche giorno (leakage per-trade piccolo, slippage medio ≤15 bps), allora il 15m regge l'esecuzione e si può passare da testnet a piccolo reale → poi scalare. Se resta 🔴/🟡, l'edge si erode sui fill e NON va scalato: prima si capisce dove perde (slippage ingressi? uscite a mercato? sim_fallback frequenti?).

2.5 KiB Raw Blame History