Il protocollo NeuPortal

Il contesto: chi siamo e da dove siamo partiti

Non abbiamo iniziato con l’intelligenza artificiale, ma con i dati di mercato grezzi. Piattaforme crypto, mercati predittivi, scommesse sportive: tre ambienti radicalmente diversi in cui per anni abbiamo fornito liquidità in proprio, fatto trading manuale e scritto il nostro software.

Era la classica era dei bot «stupidi»: algoritmi lineari rigidi, script di automazione e parser di dati. Avevano regole di ingresso e uscita inflessibili, soglie numeriche fisse per i segnali e un calendario rigido. Un codice del genere fa esattamente ciò che c’è scritto, e assolutamente nulla di più.

Il problema non era che quegli algoritmi non funzionassero. Davano risultati, ma solo fino al primo cambio di regime del mercato. Una strategia costruita e testata su una volatilità calma e ciclica andava in pezzi appena il movimento diventava nervoso e impulsivo. Il normale rumore di mercato continuava a sfondare le soglie statiche impostate a mano nei file di configurazione. E ogni cambiamento di questo tipo, macro o legato a un evento, per noi significava sempre la stessa cosa: fermare il software, mettersi sul codice e ritarare i parametri a mano. Ancora e ancora.

La svolta: un vicolo cieco tecnologico

Ci sono voluti sei mesi di test intensi e continui sulla microstruttura reale del mercato, su tre mercati diversi, per finire in un vicolo cieco tecnologico.

È stata la classica storia di un grande errore ingegneristico. Abbiamo cercato di costruire un algoritmo assolutamente universale: un unico insieme astratto di regole matematiche che doveva funzionare altrettanto bene su qualsiasi piattaforma. Sui dati storici disegnava una curva dell’equity impeccabile e liscia, senza drawdown profondi. Nel forward test live perdeva denaro con costanza. Il tempo di sviluppo del team e una parte significativa del capitale di test sono andati persi per sempre dentro l’order book. Lo slippage reale si è mangiato tutto il vantaggio calcolato, e la liquidità frammentata trasformava il prezzo di ingresso pianificato dal modello in uno ben diverso e sfavorevole.

La conclusione che ci sono costati quei mesi e quelle risorse è stata fondamentale: i mercati non differiscono per impostazioni cosmetiche dei parametri, ma per la loro struttura interna.

• Su Binance il prezzo nasce all’interno di un order book dinamico, dove tutto è deciso dalla profondità attuale, dalla velocità di esecuzione e dalla liquidità.
• Su Polymarket il prezzo di un contratto riflette solo una stima collettiva della probabilità, mentre l’esito finale e i pagamenti sono regolati da un oracolo decentralizzato immutabile.
• Su un exchange di scommesse sportive la meccanica si basa sul risultato netto di una partita e sul movimento ad alta frequenza della linea prima dell’inizio.

Non esiste un codice lineare universale per queste tre meccaniche opposte.

Cosa abbiamo costruito: un’IA con un cervello

Compreso il vicolo cieco, abbiamo abbandonato del tutto il codice algoritmico rigido e siamo passati a un’architettura flessibile basata su reti neurali.

La differenza chiave è ciò che il sistema fa nella frazione di secondo prima che un ordine arrivi sul mercato. Il vecchio bot lineare confrontava alla cieca il prezzo attuale con una soglia fissa. Il nostro agente IA svolge in millisecondi la mole di lavoro che prima richiedeva ore a un team di analisti: un’analisi multifattoriale end-to-end della struttura del mercato, dei pattern storici nascosti, degli indici esterni e della profondità dell’order book, su tutti gli strumenti e le coppie della sua piattaforma contemporaneamente.

Ma una rete neurale da sola non può fare trading in modo sicuro e sistematico. Così abbiamo unito il suo «cervello» di calcolo alle fondamenta che avevamo già: le nostre strategie matematiche e le formule rigorose di gestione del rischio, consolidate in anni di trading manuale. In questa combinazione l’IA è responsabile della lettura predittiva istantanea della situazione, mentre la matematica si occupa della dimensione delle posizioni, dei limiti di esposizione e dei confini rigidi del rischio. Insieme formano una macchina predittiva che decide l’ingresso all’istante e rigorosamente entro il perimetro di sicurezza.

Il problema: perché i report di trading si disegnano e non si dimostrano

L’idea della nostra verifica è nata da una normale discussione sul report di trading di qualcun altro. Una bella tabella, una curva dell’equity perfettamente liscia, un autore soddisfatto, e nemmeno una riga verificabile in modo indipendente.

Uno screenshot, una tabella, una frase del tipo «il mio risultato del mese»: sono dichiarazioni che non si reggono su nient’altro che sulla parola dell’autore.

Abbiamo impostato il problema ingegneristico al contrario: costruire un sistema in cui non resti nulla da dichiarare. In cui il risultato finale non venga dichiarato, ma calcolato automaticamente dai dati grezzi della piattaforma e scritto subito in un registro che non si può riscrivere a posteriori. Se funziona, la fiducia smette di basarsi sulle promesse del marketing e inizia a basarsi su come è costruita la piattaforma.

Lo sviluppo finora, in cifre

Messa in produzione e lezioni pratiche

Crypto: dove abbiamo dovuto fare marcia indietro

Le crypto sono state la prima direzione che abbiamo messo in produzione. Lì c’è un’enorme e fitta mole di dati storici, quindi le ipotesi si potevano testare più in fretta. Il risultato di quel lavoro è il modulo B-Scalper: scalping ad alta frequenza su Binance, con ingresso quando coincidono più fattori di mercato indipendenti e take profit e stop loss calcolati dinamicamente in base alla volatilità corrente.

Ciò che abbiamo dovuto eliminare è il trading sulle coppie illiquide. Sui dati storici disegnavano rendimenti eccellenti. Nell’esecuzione live tutto il potenziale vantaggio se ne andava in slippage e costi di funding. La strategia guadagnava con regolarità sulla carta e perdeva denaro reale dentro l’order book.

Mercati predittivi: il problema si è rivelato un altro

Il compito dell’algoritmo non è prevedere l’esito, ma trovare l’inefficienza del momento. Un mercato predittivo aggrega ciò che sanno migliaia di partecipanti informati, e cercare di batterlo frontalmente nell’indovinare il futuro è una posizione perdente per definizione. Il prezzo di un contratto binario è la stima attuale della probabilità da parte del mercato. Quando resta indietro rispetto al mercato di riferimento sottostante, si apre uno spread, e quella divergenza strutturale è il trigger.

Un mercato predittivo non è un unico ambiente, ma cinque aree tematiche indipendenti, ognuna delle quali richiede una propria infrastruttura e propri dati grezzi:

• Contratti crypto — CPM Terminal. Il modulo opera sui contratti Up/Down di Polymarket su sei asset sottostanti, contemporaneamente su orizzonti da 5 minuti a 4 ore. Il riferimento è il feed spot di Binance: l’order book di Polymarket è sincronizzato di continuo con lo spot, e il ritardo nel riprezzare la probabilità forma il segnale.
• Meteo e macro — CPM Terminal. Sui mercati meteo il modulo confronta un insieme di modelli di previsione indipendenti con il consenso di mercato attuale. Sui contratti macro lavora secondo il calendario pubblicato delle statistiche ufficiali (CPI, Non-Farm Payrolls e altre) e gestisce la reazione immediata della liquidità a una sorpresa rispetto alle attese.
• Esport — Cyber P-Term. Il modulo copre Dota 2, LoL, CS2 e altre discipline: analisi end-to-end dei rating delle squadre, monitoraggio automatico delle notizie sui cambi di formazione, combinati con i segnali dell’order book e il movimento delle quote live.
• Politica — integrata in Max K-Term. Non abbiamo costruito un terminale separato per gli esiti politici. Su Kalshi la politica è strettamente legata ai contratti sugli eventi macro. L’algoritmo elabora i feed dei modelli elettorali, i dati degli exit poll e i trigger legislativi, riprezzando i candidati più velocemente di quanto il retail riesca a spostare i propri ordini.
• Contratti su eventi — Max K-Term (Kalshi). Qui il problema ingegneristico cambia completamente: non si tratta di cercare divergenze, ma di puro market making. La particolarità di Kalshi sono i contratti intorno ai 50 centesimi, dove la commissione taker standard si mangia l’intero margine. Il modulo lavora solo con ordini limite (solo maker), come fornitore passivo di liquidità, guadagnando lo spread e i rebate.

L’exchange di scommesse sportive: il modulo SXB Pro

SX non è un bookmaker classico, ma un exchange peer-to-peer decentralizzato: i partecipanti si quotano a vicenda con ordini limite e il nucleo della piattaforma li abbina. La nostra infrastruttura legge l’order book della mainnet direttamente tramite protocolli aperti, senza autorizzazione e senza firma: ogni quotazione in streaming è pubblica.

Il modulo copre 18 sport, con calcio, tennis e basket come tris operativo. Sul calcio l’algoritmo opera su tre famiglie di mercati:

• Esito finale (MATCH_ODDS)
• Over/Under (OVER_UNDER)
• Draw no bet (DRAW_NO_BET)

Nel tennis e nel basket la liquidità si concentra solo sul testa a testa (moneyline). Gli algoritmi calcolano di continuo in entrambe le fasi: la linea pre-partita e il gioco live.

Il problema ingegneristico cambia di nuovo radicalmente. Non si tratta di prevedere il risultato finale né di cercare una divergenza rispetto a un mercato di riferimento esterno: un evento sportivo unico non ha un feed spot univoco. Il modulo trova errori matematici nel prezzo di selezioni adiacenti all’interno di un unico order book. Su una piattaforma peer-to-peer i prezzi degli esiti opposti dello stesso evento sono quotati da controparti indipendenti, il che crea un’incoerenza strutturale delle quote nel book, fisicamente impossibile con un market maker centralizzato.

Per monetizzare queste anomalie sono attive in parallelo due strategie indipendenti:

1. La ricerca dello scostamento tra il prezzo equo calcolato e la quotazione di mercato attuale.
2. Un modulo di scalping che lavora sul ritorno del prezzo alla sua media matematica.

Lo stack è calibrato sulla microstruttura peer-to-peer: la profondità del book viene interrogata ogni 5 secondi, e il pool dei mercati disponibili si aggiorna ogni 30.

Filtraggio rigoroso della liquidità: perché la maggior parte dei mercati viene scartata

La piattaforma ignora deliberatamente la maggior parte delle quotazioni disponibili in base a quattro filtri di sistema:

• Ampiezza dello spread. Sulle piattaforme peer-to-peer lo spread è sempre stato più ampio che sugli exchange spot tradizionali, perciò le soglie sono calibrate sulla liquidità peer-to-peer.
• Profondità minima. Una quotazione sostenuta dal volume di un singolo wallet isolato non viene considerata: non rappresenta il mercato.
• Convalida delle anomalie. Gli ordini limite isolati a quote implausibili e chiaramente sbagliate (ordini fat-finger) vengono scartati prima di qualsiasi calcolo.
• Solo tempi regolamentari. Supplementari e rigori non vengono trattati per principio. L’agente opera rigorosamente entro i tempi regolamentari: oltre, il prezzo smette di riflettere una probabilità pulita, quindi ogni esposizione aperta viene chiusa forzatamente prima della fine dei tempi regolamentari.

La dimensione degli ordini viene calcolata dinamicamente durante la sessione e dipende dalla profondità attuale del book e dall’ampiezza dello spread osservato. Il limite rigido sul capitale è fisso e comune a tutto il motore: al raggiungimento di un limite di perdita locale del 20%, il trading sulla piattaforma si blocca immediatamente.

Infrastruttura di esecuzione: come i modelli vengono messi in produzione nei terminali di trading

Un modello matematico isolato che produce segnali non è ancora un agente di trading. Lo diventa solo dopo essere stato integrato in un ambiente di produzione tollerante ai guasti, che fornisce una connessione a bassa latenza con la piattaforma, l’esecuzione degli ordini, la contabilità end-to-end delle posizioni e una piena osservabilità.

La sicurezza del capitale è assicurata a livello di architettura: ogni agente comunica con il nucleo dell’exchange tramite una chiave API dedicata con permessi separati. Sono consentite solo le operazioni di trading; qualsiasi diritto di prelievo è completamente bloccato. Se la verifica della chiave rileva l’accesso ai prelievi, il livello di sicurezza annulla la sessione e rifiuta la connessione. Gli algoritmi di trading non hanno accesso fisico ai wallet o ai saldi degli utenti in nessuno scenario.

Abbiamo anche portato la latenza dei dati al centro dell’interfaccia di monitoraggio. Questa decisione è seguita a un incidente in cui un ritardo su un ticker era stato scoperto solo a posteriori, analizzando operazioni anomale. Ora il monitoraggio intercetta il minimo ritardo prima che possa manifestarsi negli ordini eseguiti.

Convalida degli algoritmi: come ci verifichiamo e dove perdiamo contro il mercato

Per escludere il fattore soggettivo e qualsiasi dichiarazione di rendimento a parole, teniamo un registro delle previsioni aperto e verificabile pubblicamente. Nel momento in cui il nucleo IA calcola la propria stima della probabilità di un esito, il sistema la pubblica. Nello stesso millisecondo il log registra la quotazione corrente del mercato, cioè il consenso di mercato. Entrambi vengono congelati in attesa della risoluzione dell’evento.

La qualità delle previsioni si misura con una metrica accademica rigorosa, il punteggio di Brier. Più il valore è basso, migliore è la calibrazione delle probabilità del modello: più piccolo è l’errore quadratico medio.

Cosa significa per te