HYDRA v6Documentazione progetto

Gli 8 servizi v6

Per ogni servizio: ruolo, status rilevato automaticamente, decisioni di design e task. Tutto editabile dal web.

1. DATA SOURCE

Sorgenti dati: Binance WS+REST, FRED, DefiLlama, Alternative.me, Coingecko. Nessuna persistenza propria.

pianificato (non implementato)

systemd hydra-v6-data-source: inactive · sorgente: assente

⚙️ LOGICA
INPUT
Binance WebSocket (kline/trade streams) + REST (klines, funding rate, open interest, long/short ratio). FRED (DXY, tassi). DefiLlama (stablecoin supply, TVL). Alternative.me (Fear & Greed). Coingecko (market cap, metadata token).
LOGIC
WebSocket persistente per i prezzi real-time; poller REST schedulati per i driver. Normalizza payload eterogenei in un formato canonico (symbol, timestamp_ms, value). Nessuna persistenza propria: inoltra i batch a SERVER LOG. Backfill storico via REST quando mancano candele.
OUTPUT
Via SERVER LOG -> candles_1m/15m/1h/4h/1d, driver_per_asset (funding/OI/long_short), driver_global (fear_greed/btc_dominance/stablecoin/macro), token_metadata.
PSEUDOCODE
async for msg in binance_ws.stream(klines_universe):     # real-time
    queue.put(normalize_kline(msg))

every 60s:                                               # REST pollers
    for src in [funding, open_interest, long_short]:
        for r in fetch(src): queue.put(normalize(r))
every 300s:
    for src in [fear_greed, dxy, stablecoin_supply]:
        for r in fetch(src): queue.put(normalize(r))

while batch := queue.drain(max=500):
    server_log.upsert(batch)        # delega la persistenza
KEY PARAMETERS
ws_streams: kline_1m sull'universe (~200 simboli). rest_poll: 60s (funding/OI/LS), 300s (macro/F&G). batch_size: 500. universe: 200+ token (universe_test.yaml).
DEPENDENCIES
Nessuna a monte (e' la sorgente). Scrive esclusivamente tramite SERVER LOG.
RESOURCES
CPU bassa (~1 core). RAM ~300-500MB (buffer WS). Storage 0 (delegato a SERVER LOG). Banda di rete continua per gli stream WS.

Decisioni di design (1)

Sorgenti esterne, nessuna persistenza propria active

Binance WS+REST, FRED, DefiLlama, Alternative.me, Coingecko. Il servizio normalizza e inoltra; la persistenza e' delegata a SERVER LOG (PostgreSQL).

Motivazione: Separazione netta ingest/storage; evita duplicazione dati.

creata 28/06/2026 · modificata 28/06/2026 18:10

+ Aggiungi decisione

Cosa rimane da fare (1)

Collector v6 + dismissione servizi v4 pending P2

Implementare il collector v6 e poi fermare i servizi v4 (hydra-ws-collector, hydra-candle-aggregator, hydra-fingerprint).

+ Aggiungi task

2. SERVER LOG

PostgreSQL append-only, retention 180gg piena, audit trail. 17 tabelle create.

pianificato (non implementato)

systemd hydra-v6-server-log: inactive · sorgente: assente

⚙️ LOGICA
INPUT
Stream normalizzati da DATA SOURCE (candele, driver, metadata). Heartbeat ed eventi operativi da tutti i servizi v6.
LOGIC
PostgreSQL append-only come audit trail. UPSERT idempotente sulle PK (es. candele su (symbol, open_time)). Batch insert con execute_values/COPY per throughput. Job di retention a 180 giorni.
OUTPUT
Le 17 tabelle hydra_v6 (9 dati: candles_*, driver_*, token_*; + operative: live_events, analyz_signals, decisions, paper_positions, heartbeats, quality_reports, emergency_actions).
PSEUDOCODE
def upsert(batch):
    for table, rows in partition_by_table(batch).items():
        execute_values(
            f"INSERT INTO {table} (...) VALUES %s "
            "ON CONFLICT (pk) DO UPDATE SET ...", rows, page_size=1000)

daily 04:00:                              # retention 180gg
    for t in candle_tables:
        DELETE FROM t WHERE open_time < now_ms() - days(180)
KEY PARAMETERS
retention_days: 180. batch page_size: 1000. conflict policy: DO UPDATE (idempotente). append-only (no UPDATE distruttivi sui dati storici).
DEPENDENCIES
DATA SOURCE (produttore principale). Riceve scritture da tutti gli altri servizi (eventi/heartbeat).
RESOURCES
CPU media in burst di insert. RAM ~0.5-1GB (shared_buffers PostgreSQL). Storage grande: ~7GB la sola candles_1m, in crescita, con cap a 180gg.

Decisioni di design (1)

PostgreSQL append-only, retention 180gg active

DB hydra_v6 append-only come audit trail. 17 tabelle gia' create. Retention 180gg a regime.

Motivazione: Tracciabilita' completa e riproducibilita' delle decisioni.

creata 28/06/2026 · modificata 28/06/2026 18:10

+ Aggiungi decisione

Cosa rimane da fare (1)

Job retention 180gg pending P3

Definire e schedulare il job di retention append-only a 180 giorni.

+ Aggiungi task

3. LIVE SCANNER

5 detector (pump, dump, volume_spike, funding_extreme, liquidity_drop). Frequenza 1min su tutti i 200+ asset.

pianificato (non implementato)

systemd hydra-v6-live-scanner: inactive · sorgente: assente

⚙️ LOGICA
INPUT
candles_1m e candles_15m (da hydra_v6), driver_per_asset (funding, OI).
LOGIC
5 detector eseguiti ogni minuto su tutti i 200+ asset: pump (ritorno% breve oltre soglia), dump (ritorno negativo), volume_spike (z-score volume), funding_extreme (funding z21 oltre quantile), liquidity_drop (caduta quote_volume/liquidita').
OUTPUT
live_events (event_type, symbol, severity, payload, timestamp_ms).
PSEUDOCODE
every 60s:
    for sym in universe:                       # 200+ asset
        c = candles_1m.last_n(sym, 60)
        if ret(c, 5m) >  PUMP_PCT:     emit("pump", sym, sev="warning")
        if ret(c, 5m) < -DUMP_PCT:     emit("dump", sym, sev="warning")
        if zscore(c.volume, 60) > VOL_Z: emit("volume_spike", sym)
        if funding_z21(sym) >= FUND_Q:   emit("funding_extreme", sym)
        if liquidity_drop(sym) > LIQ_PCT: emit("liquidity_drop", sym)
KEY PARAMETERS
freq: 60s. pump/dump: +/- soglia% su 5m (da affinare). volume z-score: ~3.0. funding quantile: Q90. liquidity_drop: % su finestra. universe: 200+ (da filtrare).
DEPENDENCIES
DATA SOURCE / SERVER LOG (candele e driver).
RESOURCES
CPU media (200 asset x 5 detector al minuto). RAM ~200MB. Storage modesto (solo eventi).

Decisioni di design (2)

5 detector @1min su 200+ asset active

Detector: pump, dump, volume_spike, funding_extreme, liquidity_drop. Frequenza 1 minuto su tutti i 200+ asset. Output in live_events.

Motivazione: Copertura ampia e reattiva su eventi di mercato.

creata 28/06/2026 · modificata 28/06/2026 18:10

Asset universe filtrato pending

Definire il sottoinsieme di asset su cui far girare i detector.

creata 28/06/2026 · modificata 28/06/2026 18:10

+ Aggiungi decisione

Cosa rimane da fare (1)

Definire asset universe detector pending P2

Filtrare lo universe di asset su cui far girare i 5 detector del LIVE SCANNER.

+ Aggiungi task

4. SERVER STAT

30 indicatori Tier 1+2+3 (RSI, EMA, Returns, ATR, Vol, Volume, Momentum, Bollinger, VWAP, Beta, Funding+z21, Funding slope, OI). TF 1h/4h/1d.

pianificato (non implementato)

systemd hydra-v6-server-stat: inactive · sorgente: assente

⚙️ LOGICA
INPUT
candles_1h, candles_4h, candles_1d. driver_per_asset (funding, OI) per gli indicatori Tier 3.
LOGIC
Calcola 30 indicatori per asset e timeframe. Tier1: RSI, EMA 9/21/50/200, Returns, ATR. Tier2: Vol, Volume, Momentum, Bollinger, VWAP. Tier3: Beta, Funding+z21, Funding slope, OI. Esclude MACD/Stochastic/Ichimoku/Fibonacci (ridondanti o ritardati).
OUTPUT
Feature store di indicatori per (symbol, timeframe), consumato da SERVER ANALYZ (payload JSONB).
PSEUDOCODE
every 1h:
    for sym in universe:
        for tf in [1h, 4h, 1d]:
            c = candles[tf].last_n(sym, 250)
            feats = {
              "rsi14": rsi(c,14), "ema": ema(c,[9,21,50,200]),
              "atr14": atr(c,14), "ret": returns(c),
              "boll": bollinger(c,20,2), "vwap": vwap(c),
              "beta": beta(c, btc), "funding_z21": z(funding(sym),21),
              "funding_slope": slope(funding(sym)), "oi": oi(sym),
            }
            feature_store.put(sym, tf, feats)
KEY PARAMETERS
freq: 1h. timeframes: 1h/4h/1d. EMA: 9/21/50/200. RSI: 14. ATR: 14. Bollinger: 20/2. z-window: 21. lookback: 250 candele.
DEPENDENCIES
SERVER LOG (candele), DATA SOURCE (funding/OI).
RESOURCES
CPU media-alta ogni ora (200 asset x 3 tf x 30 indicatori). RAM ~500MB (numpy/pandas). Storage feature store modesto.

Decisioni di design (1)

30 indicatori Tier 1+2+3 active

RSI, EMA 9/21/50/200, Returns, ATR, Vol, Volume, Momentum, Bollinger, VWAP, Beta, Funding+z21, Funding slope, OI. Timeframes 1h/4h/1d. Skip MACD/Stochastic/Ichimoku/Fibonacci.

Motivazione: Indicatori con edge potenziale; esclusi quelli ridondanti/ritardati.

creata 28/06/2026 · modificata 28/06/2026 18:10

+ Aggiungi decisione

Cosa rimane da fare (1)

Implementare i 30 indicatori (Fase 2) pending P1

Implementare SERVER STAT: 30 indicatori Tier 1+2+3 su 1h/4h/1d.

+ Aggiungi task

5. SERVER ANALYZ

15 moduli (Cat A-E). Score 0-1 continuo. Frequenza 1h. Auto-validazione pesi mensile.

pianificato (non implementato)

systemd hydra-v6-server-analyz: inactive · sorgente: assente

⚙️ LOGICA
INPUT
Feature store di SERVER STAT, candele, driver_per_asset/global, output dei modelli ML (Cat E).
LOGIC
15 moduli (Cat A-E) producono ciascuno uno score 0-1; combinati in uno score aggregato pesato per categoria. Frequenza 1h. Auto-validazione mensile dei pesi via walk-forward.
MODULES
CatModuloPesoLogicaFinding
AFunding Q90 Defensive3.0Funding z21 >= Q90 -> posizione defensive/short ~7gg#11: ret medio -4.59% a 7gg, walk-forward 10/10
BFunding x Regime1.0Funding condizionato al regime di mercatocandidato (da validare)
BDXY in Bear1.0Forza del DXY come filtro nei regimi bearcandidato (da validare)
BVolatility filtering1.0Filtra/scala i segnali per regime di volatilita'candidato (da validare)
CMomentum 30d0.3Momentum classico a 30 giorniclassico, edge debole
CMean reversion RSI0.3RSI < 35 -> reversione attesaclassico, edge debole
CTrend EMA0.3Cross / pendenza delle EMAclassico, edge debole
DRegime detectorcontestoClassifica bull / bear / rangefeature di contesto
DVolatility regimecontestoClassifica volatilita' alta / bassafeature di contesto
DDrawdown currentcontestoDrawdown corrente dell'assetfeature di contesto
ETimesFM0.5-1.5Foundation model di forecasting time-seriesML
EChronos0.5-1.5Foundation model di forecasting time-seriesML
EHMM0.5-1.5Hidden Markov Model per regimeML
EHurst0.5-1.5Esponente di Hurst (persistenza/mean-reversion)ML
ELSTM0.5-1.5Rete ricorrente per forecastingML
OUTPUT
analyz_signals (symbol, signal_type, direction long/short, score 0-1, payload con i sotto-score).
PSEUDOCODE
every 1h:
    for sym in universe:
        scores = {m.name: m.evaluate(sym, features[sym]) for m in MODULES}  # 15 moduli
        agg = sum(scores[m.name]*WEIGHT[m.cat] for m in MODULES) / sum_weights
        direction = "short" if defensive_edge(sym) else "long"   # edge Funding Q90
        analyz_signals.insert(sym, signal_type=top(scores),
                              direction=direction, score=agg, payload=scores)

monthly:
    WEIGHT = walk_forward_revalidate(history)   # auto-validazione pesi
KEY PARAMETERS
freq: 1h. pesi: A=3.0, B=1.0, C=0.3, D=contesto, E=0.5-1.5. score: 0-1 continuo. revalidation: mensile (walk-forward).
DEPENDENCIES
SERVER STAT (feature), SERVER LOG (candele/driver), modelli ML per la Cat E.
RESOURCES
CPU alta (ML: TimesFM/Chronos/LSTM). RAM 2-4GB (modelli in memoria). Storage modelli ~1GB.

Decisioni di design (2)

15 moduli, score 0-1, auto-validazione pesi mensile active

Cat A Edge (peso 3.0): Funding Q90 Defensive. Cat B Candidati (1.0): Funding x Regime, DXY in Bear, Volatility filtering. Cat C Classici (0.3): Momentum 30d, Mean reversion RSI, Trend EMA. Cat D Contesto: Regime detector, Vol regime, Drawdown. Cat E ML (0.5-1.5): TimesFM, Chronos, HMM, Hurst, LSTM. Freq 1h.

Motivazione: Pesi proporzionali alla forza dell'edge; auto-validazione mensile.

creata 28/06/2026 · modificata 28/06/2026 18:10

Edge validato — Finding #11 (Funding Rate z21 >= Q90) active

Funding Rate z21 >= Q90 -> return medio -4.59% a 7 giorni. Walk-forward 10/10 asset robusti. Unico driver sopravvissuto su 4 candidati.

Motivazione: Edge statisticamente robusto, base della Cat A peso 3.0.

creata 28/06/2026 · modificata 28/06/2026 18:10

+ Aggiungi decisione

Cosa rimane da fare (1)

Modulo 1 Funding Q90 (Fase 3) pending P1

Implementare il primo modulo analyzer (edge Cat A), poi i moduli 2-15 (Fase 4).

+ Aggiungi task

6. AGENT AI

Decisore Pure Rule-Based (no Claude API). Execution interno separato. Universe 200+ token v5.

pianificato (non implementato)

systemd hydra-v6-agent-ai: inactive · sorgente: assente

⚙️ LOGICA
INPUT
analyz_signals (segnali), paper_positions (stato posizioni), token_metadata (filtri), prezzi correnti.
LOGIC
Decisore Pure Rule-Based deterministico (NO Claude API). Filtra l'universe; applica regole di entry/exit sugli score di ANALYZ (da definire); execution interno separato. Genera decisioni e gestisce le posizioni paper.
OUTPUT
decisions (action buy/sell/hold/close, confidence, reason, signal_id) e paper_positions (open/close, exit_reason esplicito).
PSEUDOCODE
on new analyz_signals:
    for sig in analyz_signals.fresh():
        if not passes_filters(sig.symbol): continue   # universe filter
        if sig.score >= ENTRY_TH and not open(sig.symbol):
            size = position_size(equity, RISK_PCT)
            decisions.insert("buy", sig); paper_open(sig.symbol, size)

    for pos in paper_positions.open():
        if exit_rule(pos):              # TP / SL / holding max / decay score
            decisions.insert("close", pos, reason=exit_reason(pos))
            paper_close(pos)
KEY PARAMETERS
entry_threshold: DA DEFINIRE. holding_period_max: DA DEFINIRE. position_sizing: DA DEFINIRE (risk per trade). filtri: vol_24h>1M, eta'>30gg, storia>60gg, spread<0.5%. blacklist: RNDR, FET.
DEPENDENCIES
SERVER ANALYZ (segnali), SERVER LOG (stato), DATA SOURCE (prezzi).
RESOURCES
CPU bassa. RAM ~200MB. Storage modesto (decisioni e posizioni).

Decisioni di design (2)

Pure Rule-Based (no Claude API) active

Decisore deterministico rule-based. Execution interno separato. Universe 200+ token v5. Filtri: vol_24h>1M, eta'>30gg, storia>60gg, spread<0.5%, blacklist RNDR/FET.

Motivazione: Determinismo e zero costi API ricorrenti (lezione ORACLE v5).

creata 28/06/2026 · modificata 28/06/2026 18:10

Regole entry/exit, holding period, position sizing pending

Da definire: condizioni precise di entry/exit, holding period massimo, logica di position sizing.

creata 28/06/2026 · modificata 28/06/2026 18:10

+ Aggiungi decisione

Cosa rimane da fare (1)

Regole AGENT AI + paper mode (Fase 6) pending P2

Definire entry/exit, holding period, position sizing; portare in paper mode.

+ Aggiungi task

7. SERVER QUALITY

Auditor investigativo. Health 5min. Analisi perdite per-trade. Opportunita' giornaliera. Nessuna notifica.

pianificato (non implementato)

systemd hydra-v6-server-quality: inactive · sorgente: assente

⚙️ LOGICA
INPUT
paper_positions, decisions, analyz_signals, heartbeats, candele (per benchmark).
LOGIC
Auditor investigativo. Health check ogni 5 minuti. Analisi perdite per-trade (attribuzione: timing di entry, exit_reason, slippage). Scansione opportunita' giornaliera (cosa si e' perso). Nessuna notifica: solo report.
OUTPUT
quality_reports (report_type: health/loss_analysis/opportunity, scope, status, details JSONB).
PSEUDOCODE
every 5min:                              # health
    h = collect_heartbeats()
    if stale(h): quality_reports.insert("health", status="critical", details=h)

daily:
    for trade in closed_trades(yesterday):
        attr = attribute_pnl(trade)          # perche' ha perso/guadagnato
        quality_reports.insert("loss_analysis", scope=trade.id, details=attr)
    missed = scan_missed_opportunities()
    quality_reports.insert("opportunity", details=missed)
KEY PARAMETERS
health_interval: 5min. loss analysis: per-trade giornaliera. benchmark: DA DEFINIRE. notifiche: NESSUNA (solo report).
DEPENDENCIES
AGENT AI (trade/decisioni), SERVER LOG, SERVER ANALYZ.
RESOURCES
CPU bassa. RAM ~200MB. Storage report modesto.

Decisioni di design (2)

Auditor investigativo, nessuna notifica active

Health check 5min. Analisi perdite per-trade. Opportunita' giornaliera. Feedback solo via report, NESSUNA notifica push.

Motivazione: Strumento di analisi, non di alerting; evita rumore operativo.

creata 28/06/2026 · modificata 28/06/2026 18:10

Benchmark di confronto pending

Da definire il benchmark contro cui valutare le performance.

creata 28/06/2026 · modificata 28/06/2026 18:10

+ Aggiungi decisione

Cosa rimane da fare (1)

Definire benchmark QUALITY pending P3

Scegliere il benchmark di confronto per valutare le performance.

+ Aggiungi task

8. EMERGENCY

Container Docker isolato. 8 trigger. Market sell. Restart manuale.

pianificato (non implementato)

systemd hydra-v6-emergency: inactive · sorgente: assente

⚙️ LOGICA
INPUT
heartbeats, paper_positions (equity/drawdown), prezzo BTC, stato exchange, quality_reports (critical).
LOGIC
Container Docker isolato, indipendente dal core. Monitora 8 trigger; al primo che scatta esegue market sell di tutte le posizioni. NON si riavvia da solo: restart manuale.
OUTPUT
emergency_actions (action_type, reason, triggered_by, details JSONB).
PSEUDOCODE
loop:                                  # container isolato
    if now - last_heartbeat > 5min:    trip("heartbeat")
    if drawdown()       >= 0.20:       trip("drawdown_20")
    if daily_loss()     >= 0.07:       trip("daily_loss_7")
    if max_position_pct() >= 0.10:     trip("position_10")
    if orders_per_min() >  LIMIT:      trip("order_rate")
    if btc_move_10min() <= -0.05:      trip("flash_crash_btc")
    if exchange_error():               trip("exchange_error")
    if quality_critical():             trip("quality_critical")

def trip(reason):
    market_sell_all(); emergency_actions.insert(reason); halt()  # restart MANUALE
KEY PARAMETERS
heartbeat_timeout: 5min. drawdown_max: 20%. daily_loss_max: 7%. position_max: 10%. flash_crash_btc: -5% in 10min. order rate limit. restart: MANUALE.
DEPENDENCIES
SERVER LOG (stato), SERVER QUALITY (segnale critical), AGENT AI (posizioni da liquidare).
RESOURCES
CPU minima. RAM ~128MB (container isolato). Storage minimo.

Decisioni di design (2)

Container Docker isolato, 8 trigger, market sell active

Container Docker isolato. 8 trigger: heartbeat 5min, drawdown 20%, daily loss 7%, position max 10%, orders/min, flash crash BTC -5%/10min, exchange error, QUALITY critical. Azione: market sell. Restart manuale.

Motivazione: Isolamento per resilienza; kill-switch indipendente dal core.

creata 28/06/2026 · modificata 28/06/2026 18:10

Affinamento soglie esatte pending

Le 8 soglie trigger vanno affinate con dati reali.

creata 28/06/2026 · modificata 28/06/2026 18:10

+ Aggiungi decisione

Cosa rimane da fare (1)

Containerizzare EMERGENCY (Fase 7) pending P2

Docker isolato + affinamento delle 8 soglie trigger.

+ Aggiungi task