Un solo basket sizato a rischio aveva impegnato il 100 % del margine del conto
(16/9). Ora strategy.json ha la sezione risk (12 % dell'equity per basket, 40 %
in totale, disponibile con buffer del 25 %), la size è il minimo fra rischio e
margine e il ledger scrive quale vincolo ha deciso; il conto viene riletto
prima della gamba B e, se non copre, A viene richiusa; i segnali della stessa
barra vanno per |z| decrescente con rilettura del conto; sotto equity/margine
1,5 niente entrate, sotto 1,2 si chiude il basket peggiore. Il backtest applica
gli stessi limiti. Test (y), (z).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Perché: l'utente ha chiesto un bot che operi cinque basket di coppie forex
correlate su eToro, autonomo, con ledger, feed gratuiti e apprendimento
costruito da zero, e ha deciso di eliminare tutto ciò che restava delle
gestioni precedenti (Binance, cTrader/proba, ricerca con SQLite, GBDT, RL,
TA-Lib) e di non avere approvazioni manuali sui singoli ordini.
Cosa cambia:
- nuovo Core dei basket (cross sintetici, decisore, cost gate, sizing,
esecutore leg-risk, backtest con PSR/DSR/PBO, livelli 0-3 di apprendimento),
adattatore eToro Public API, motore autonomo con equity stop, kill-switch,
riconciliazione, ledger append-only, calendario e notizie con sentiment;
- modalità Paper / Demo / Live (Live con flag e frase CONFERMO LIVE);
- interfaccia rifatta: barra in alto con tre schede, dashboard con i soli
numeri principali, fuso orario selezionabile, test di rendering in PNG;
- corretto il parser dei costi eToro (campo "value"): markup e overnight
non venivano letti;
- strumento di ricerca ridotto a ticks / baskets / falsify con due scenari di
costo; risultati in results/ e reports/: nessuna configurazione è
profittevole al netto dei costi (docs/STRATEGY.md lo dice con i numeri);
- documentazione completa (STRATEGY, ML_AND_LEARNING, RUNBOOK, GLOSSARY,
KNOWN_ISSUES, ADR-0004, ADR-0005) e catena di rilascio aggiornata.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Il bot ora ha un secondo parere prima di ogni ingresso: un classificatore GBDT
(scritto in C#, senza dipendenze native) addestrato sugli esiti dei segnali passati
con triple-barrier e meta-labeling, validato con CPCV, PBO e Sharpe deflazionato
contando tutte le configurazioni provate. Il modello non propone mai operazioni:
può solo rifiutarne una sotto la probabilità minima o ridurne la size, e si
sospende da solo quando le feature dal vivo derivano da quelle di addestramento.
Senza un campione promosso il bot opera come prima.
Perché tutto questo serve, e nell'ordine in cui è stato fatto:
- I log del giro reale sul testnet mostravano zero barre chiuse in tre giorni: il
decodificatore saltava l'oggetto annidato dei kline. Corretto con test di
regressione. Lo stesso giro restava a 1499/1500 barre di riscaldamento perché
Binance ne serve al massimo 1500 per richiesta: il client ora pagina e il motore
chiede quante ne servono davvero.
- Il log è diventato una tabella `;` con data, livello, sorgente, evento ed
eccezione (grep `;ERR;` trova ogni errore), con rotazione a dimensione impostabile
dalla finestra. Anche decisions.csv/executions.csv/trades.csv hanno intestazione
stabile, id monotoni e colonna `motivazione`, e vengono scritti anche in SQLite.
- La configurazione vive in Documenti\Encelado (con migrazione dal file accanto
all'eseguibile), le credenziali restano in LocalAppData, il database in
%ProgramData%\Encelado: tre cartelle per tre ruoli diversi.
- In modalità demo gli ordini partono davvero sul testnet (dryRun spento di
fabbrica): è l'unico modo di provare il percorso di esecuzione come in produzione.
- Lo strumento di backtest copre le fasi 0-4 della guida: qualità dei dati,
baseline buy&hold/SMA con PSR e DSR, Engle-Granger + Johansen + Kalman con costo
di break-even, dataset e addestramento del meta-modello, DQN su molti seed.
Ogni tabella è CSV `;` con motivazione, e la promozione a campione avviene solo
se il modello supera i criteri della Fase 3.
Sui dati disponibili nessuna coppia supera quei criteri, quindi nessun campione è
stato promosso: il bot resta sulla sola regola statistica, che a sua volta non
regge fuori campione. Il risultato è documentato, non nascosto.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Il bot smette di operare direzionalmente su un singolo asset e passa a coppie
delta-neutral: long una gamba, short l'altra nel rapporto che il test di
cointegrazione produce, scommettendo solo sul fatto che la distanza fra le due
si richiuda. È questo che gli permette di girare da una connessione domestica,
perché su barre da 15 minuti la latenza smette di contare.
Cosa cambia
- Encelado.Alpaca sostituito da Encelado.Binance: REST firmato in HMAC-SHA256
con correzione dello scarto d'orologio, uno stream combinato per kline, book
e mark price, e lo stream ordini autenticato con listen key rinnovata.
- Nuovo livello statistico in Core: OLS, test di Dickey-Fuller aumentato con
scelta del ritardo per AIC, ed Engle-Granger con i valori critici di MacKinnon
per la cointegrazione.
- Il rischio ragiona per coppia: divide il controvalore fra le gambe secondo β,
così le due si annullano invece di lasciare un residuo direzionale, e corregge
la dimensione con il funding netto atteso.
- Interfaccia da sette pagine a quattro. I grafici a candele sono spariti: su una
coppia coperta la candela di una gamba non dice niente, lo z-score sì.
- Ripristino dei valori predefiniti da Impostazioni, con copia datata del file
precedente. Ripristina il documento, commenti compresi, non solo i numeri.
L'ordine che non partiva
Il segnale diceva di entrare e non succedeva niente perché il router registrava
quasi tutti i rifiuti a livello debug: alla verbosità predefinita il bot
annunciava l'ingresso, rinunciava per un motivo che nessuno poteva vedere, e
sembrava aver ignorato la propria decisione. Adesso ogni intento produce una
riga a info o warn con il nome della coppia e il motivo esatto, la frase che
l'operatore legge e la decisione che il motore prende vengono dallo stesso
stato, e una barra che lo stream non consegna viene recuperata via REST.
Che cosa dice il backtest
Il banco di prova rigioca le coppie attraverso la STESSA classe che gira in
produzione, con la calibrazione che cammina in avanti. Su 6,6 anni di ETHUSDT,
BTCUSDT, SOLUSDT e AVAXUSDT: a 5 minuti nessuna combinazione di soglie supera
i filtri di taratura; a 15 minuti e a un'ora la griglia trova combinazioni che
rendono in taratura e in verifica, ma nessuna delle prime dieci resta positiva
sulla terza fetta. La finestra dello z-score va molte volte oltre l'emivita del
rientro — le 100 barre della guida sono le peggiori misurate — e il filtro di
cointegrazione è ciò che tiene in piedi tutto: senza, ogni combinazione passa
da leggermente positiva a −73%/−87%.
Per questo dryRun parte attivo. I valori consegnati sono i meglio supportati
fra quelli provati, non una strategia dimostrata, e il file lo dice.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Alby96andClaude Fable 5.1