opML e il limite di velocità: AI verificabile per gli agenti

Nel 2026 l’intelligenza artificiale è entrata ovunque nella crypto: oracoli che interrogano un modello linguistico, agenti che firmano transazioni da soli, giochi on-chain che chiamano una rete neurale a ogni mossa. Resta però una domanda scomoda. Come fa una blockchain, che non può eseguire un modello da miliardi di parametri, a sapere che quel calcolo è stato svolto davvero e in modo corretto? L’opML (optimistic machine learning) è una delle risposte più pragmatiche a questo problema. Invece di dimostrare matematicamente ogni singola operazione, come tenta di fare lo zkML, l’opML parte da un presupposto ottimistico: pubblica il risultato, lo dà per buono e apre una finestra di tempo in cui chiunque può contestarlo.

Quella finestra è il cuore dell’opML ed è anche il suo tallone d’Achille. È ciò che rende il sistema economico e leggero, ma è pure ciò che lo mette in rotta di collisione con l’ambizione su cui Ora Protocol, il progetto che ha coniato l’opML, ha puntato di più: l’economia degli agenti autonomi, dove un ritardo di minuti o ore mal si concilia con transazioni che devono chiudersi in secondi. Questa guida spiega come funziona l’opML, da dove arriva, chi lo usa e perché nel 2026 la tensione tra sicurezza e velocità ne definisce il futuro.

opML in breve: la scommessa ottimistica sull’AI verificabile

Il problema di fondo è quello che gli sviluppatori chiamano calcolo verificabile: produrre un risultato accompagnato da una prova, poco costosa da controllare, che quel risultato sia stato calcolato correttamente. La posta in gioco è la fiducia. Se un contratto agisce sulla base di ciò che dice un modello, chi garantisce che l’operatore non abbia restituito una risposta a caso, o volutamente distorta, per risparmiare sul calcolo o per manipolare l’esito? Rieseguire il modello direttamente sulla blockchain sarebbe la garanzia perfetta, ma è impossibile: costerebbe una fortuna in gas e nessun validatore tiene pronta una GPU per far girare Llama a ogni blocco. Dimostrare tutto in anticipo con la crittografia, la strada dello zkML, è fattibile ma sui modelli grandi resta ancora lentissimo e caro.

L’opML sceglie una terza via. Un operatore esegue l’inferenza fuori dalla catena su hardware normale, pubblica il risultato insieme a un impegno crittografico (un Merkle commitment) sulla traccia del calcolo e apre una finestra di sfida. Se entro la scadenza nessuno contesta, il risultato è considerato definitivo; se qualcuno contesta, una prova di frode stabilisce chi ha ragione e punisce chi ha mentito. Il nome non è casuale: l’approccio è modellato sulle optimistic rollup, e il paper fondativo, firmato dal team di Hyper Oracle nel gennaio 2024, descrive esplicitamente il metodo come «reminiscent of the optimistic rollup systems» (arXiv 2401.17555). Ottimistico significa proprio questo: si presume l’onestà finché non si dimostra il contrario, spostando il costo dal verificare sempre al verificare solo quando serve.

Dalle optimistic rollup a Truebit: la genealogia dell’opML

Per capire perché l’opML funziona così conviene guardare alla sua genealogia. Le optimistic rollup come Arbitrum e OP Stack hanno reso popolare l’idea di dare per validi i risultati e affidarsi a una finestra di contestazione con prove di frode. Ma quel meccanismo è più antico: nasce da Truebit, il progetto di Jason Teutsch e Christian Reitwiessner che introdusse il gioco di verifica interattivo. Invece di rieseguire l’intero calcolo, i contendenti restringono la disputa a un singolo passo tramite bisezione, e solo quel passo minuscolo viene giudicato on-chain. È un’idea potente: rende economico arbitrare una disputa su una computazione enorme, perché la catena deve controllare una sola istruzione, non tutte.

L’opML applica esattamente questa idea al machine learning. Prima ancora del paper accademico, la proposta era comparsa nell’agosto 2023 sul forum di governance di Optimism, segno di quanto il metodo fosse imparentato con il mondo delle rollup. La stessa logica di verifica su nodi non fidati è al centro di altri progetti di AI decentralizzata: chi vuole capire come una disputa possa stabilire la correttezza di un calcolo eseguito da attori anonimi può leggere la nostra analisi su come Gensyn verifica l’AI su nodi non fidati. La differenza è nel dominio: Truebit puntava all’esecuzione generica, l’opML alla singola inferenza di una rete neurale, con tutte le complicazioni che i modelli AI portano con sé (dimensioni enormi, aritmetica in virgola mobile, non determinismo).

Come funziona: la finestra di sfida è tutto

Il ciclo di vita di una richiesta opML si può riassumere in cinque passaggi. Primo, un submitter (chi sottomette la richiesta) esegue il modello fuori catena su hardware normale. Secondo, pubblica on-chain il risultato e un impegno crittografico sulla traccia completa del calcolo, cioè su ogni stato intermedio della computazione. Terzo, si apre la finestra di sfida, un intervallo di tempo prefissato. Quarto, se nessun osservatore contesta entro la scadenza, il risultato diventa definitivo e viene restituito al contratto che lo aveva richiesto. Quinto, se un osservatore rileva un errore, avvia una prova di frode e il protocollo stabilisce chi dice il vero, punendo la parte disonesta.

Attorno a questo flusso ruotano tre attori con incentivi diversi: il richiedente, che paga per una risposta affidabile; il submitter, che di norma deposita una cauzione a garanzia della propria onestà; e uno o più osservatori, che rifanno i conti e possono guadagnare contestando un risultato falso, incassando in tutto o in parte la cauzione del bugiardo. È un sistema a incentivi, non una dimostrazione matematica: funziona finché contestare conviene e finché c’è qualcuno disposto a farlo.

Il modello di sicurezza si regge infatti su un presupposto preciso: basta almeno un osservatore onesto (una assunzione detta one-of-N) che rifaccia il calcolo e sia pronto a contestare. Finché esiste anche un solo watcher vigile e capace, un risultato falso viene smascherato. Ed è qui che la finestra di sfida rivela la sua doppia natura: è la fonte di tutta la sicurezza del sistema, ma è anche la sua latenza incorporata. Una finestra lunga dà più tempo agli osservatori e rende il sistema più sicuro; una finestra corta rende l’opML più veloce ma lascia meno margine per scoprire una frode. Ogni scelta sulla durata della finestra è un compromesso diretto tra fiducia e velocità, e questo compromesso, come vedremo, è il nodo dell’intera storia.

Dentro la macchina: FPVM, bisezione e prove di frode

Il motore tecnico dell’opML è la Fraud Proof Virtual Machine (FPVM), una macchina virtuale deterministica in cui il calcolo contestato può essere rieseguito passo per passo. Il paper originale descrive due modalità. Nella versione a fase singola, ogni operazione del modello viene rieseguita dentro la VM vincolata: semplice e robusta, ma lenta, perché rinuncia alla GPU. Nella versione multifase, la computazione non contestata gira in modo nativo e parallelo (GPU inclusa) e solo il micro-passo su cui verte la disputa, individuato tramite bisezione interattiva, finisce nella VM. Il team sostiene che questo riduca la complessità dell’albero di Merkle da O(mn) a O(m+n), con un’accelerazione «da decine a centinaia di volte» rispetto alla fase singola (github.com/ora-io/opml).

La bisezione merita un esempio. Immaginate che submitter e challenger siano d’accordo sullo stato iniziale del calcolo ma non su quello finale. Il protocollo chiede a entrambi lo stato a metà strada: se coincide, l’errore è nella seconda metà; se differisce, è nella prima. Ripetendo la domanda si dimezza ogni volta l’intervallo, finché resta un solo passo di calcolo su cui i due divergono. Quel singolo passo, e solo quello, viene eseguito on-chain nella FPVM per decretare chi ha ragione. È una ricerca binaria sulla computazione, ed è ciò che rende sostenibile arbitrare on-chain una disputa su un modello enorme.

I benchmark diffusi dal progetto sono su scala ridotta e vanno letti come dati interni, non verificati in modo indipendente: su una rete di test locale e su un modello di tipo MNIST si parla di circa due secondi per l’inferenza e circa due minuti per l’intero ciclo di sfida; viene inoltre rivendicata l’esecuzione di un modello LLaMA da 7 miliardi di parametri (circa 26 GB) su un PC standard senza GPU. Il dettaglio cruciale è un altro: la bisezione funziona solo se la riesecuzione è bit-identica. Se due esecuzioni oneste dello stesso modello producono output leggermente diversi, il gioco di verifica non sa più chi ha ragione. È il motivo per cui l’opML si appoggia a una VM deterministica e priva di GPU, e anticipa uno dei suoi problemi più sottili, il determinismo, su cui torneremo.

Ora Protocol: da Hyper Oracle all’oracolo AI on-chain

L’opML è indissolubilmente legato a Ora Protocol, il progetto che lo ha inventato. Nato nel settembre 2022 come Hyper Oracle, un oracolo basato su prove zero-knowledge (uno zkOracle), è stato fondato da Kartin Wong, con un passato nell’infrastruttura di Google e TikTok; tra le figure chiave c’è Cathie So, ricercatrice zkML proveniente dal gruppo PSE della Ethereum Foundation. Questa doppia anima, zkML e opML nella stessa squadra, spiega perché Ora oggi tratti i due approcci come strumenti complementari e non come rivali. Nel giugno 2024 la società ha raccolto 20 milioni di dollari da Polychain, HF0 e HashKey Capital.

In quell’occasione Wong ha dichiarato a CoinDesk di voler «unlock the design space for AI dapps», con fondi destinati a «tokenizing AI models and bringing decentralized AI to the Ethereum ecosystem». Il prodotto di punta è OAO (Onchain AI Oracle), un sistema di contratti protetti dall’opML e distribuiti con lo stesso indirizzo su oltre una dozzina di reti, da Ethereum a Optimism, Arbitrum, Base e Polygon. Il flusso è lineare: un contratto invia una richiesta, i nodi opML la eseguono, il risultato viene pubblicato con la sua finestra di sfida e infine restituito via callback al richiedente.

OAO supporta modelli a pesi aperti come Llama 3.3 da 70 miliardi di parametri, Qwen, Mistral e Gemma, generatori di immagini come Stable Diffusion e FLUX, oltre ad API proprietarie come GPT-4o, con tariffe comprese tra 0,01 e 1,00 ORA per chiamata (github.com/ora-io/OAO). Ora ha anche introdotto le Initial Model Offering (IMO), token che rappresentano una quota dei ricavi di un modello, con $OLM come primo esperimento; è un tema apparentemente marginale ma con implicazioni normative pesanti, su cui torneremo nell’ultima sezione.

opAgent e la scommessa sugli agenti perpetui

L’applicazione su cui Ora ha scommesso di più è opAgent, presentata dalla società come un framework per «Onchain Perpetual Agent» e attiva dal 31 gennaio 2025 (Decrypt). L’idea è ambiziosa: agenti che, secondo la società, «exist indefinitely through the blockchain», controllati dalla logica di uno smart contract e non da una chiave privata, capaci di «maintain permanent ownership of digital assets, operate through verifiable computations, and evolve through mathematical consensus». In questo disegno l’opML è il ponte che rende verificabile ogni singola azione dell’agente, dal trade su un DEX al trasferimento di token. opAgent è arrivato insieme a RMS (Resilient Model Services), e più di recente Ora ha aggiunto Pump.ai per la creazione permissionless di agenti, con deployment che si estendono anche a Solana e Hyperliquid.

Il fatto che un agente sia governato da uno smart contract e non da una chiave privata è, sulla carta, una promessa di sicurezza notevole: niente seed phrase da rubare, niente wallet compromesso che svuota il tesoro dell’agente. La società lo vende proprio così, come un modo per eliminare le vulnerabilità legate alle chiavi tradizionali. Ma sposta il problema, non lo cancella: se le azioni dell’agente derivano dall’output di un modello, la sicurezza dell’intero sistema dipende dalla verifica di quell’output, cioè dall’opML e dalla sua finestra.

Qui si annida la tensione centrale di questa guida. Un agente autonomo che gestisce capitale ha senso solo se le sue azioni sono affidabili, e l’opML promette proprio quell’affidabilità. Ma un agente utile deve anche agire in fretta, reagire al mercato, concatenare operazioni. E ogni azione verificata dall’opML deve attraversare la finestra di sfida prima di essere davvero definitiva. La stessa proprietà che rende l’agente credibile lo rallenta. Per un confronto con l’altro grande filone di software per agenti, quello dei framework general purpose, si veda la nostra analisi di Eliza come sistema operativo per agenti e gaming.

L’economia degli agenti nel 2026: più infrastruttura che adozione

Prima di valutare la collisione conviene guardare quanto è reale, oggi, l’economia degli agenti. Il protocollo di pagamento più citato è x402 di Coinbase, che resuscita il vecchio codice HTTP 402 (Payment Required) per far pagare gli agenti a ogni richiesta, in USDC e senza approvazione umana. È l’idraulica perfetta per un mondo di macchine che comprano servizi da altre macchine. I numeri, però, raccontano una storia più sobria. Un’analisi di TRM Labs ripresa da PYMNTS ha esaminato 52,7 milioni di dollari di valore su 198,9 milioni di transazioni di regolamento x402 tra Base, Solana e Polygon da maggio 2025: dopo aver filtrato l’attività non commerciale, «just 0.6% to 7.5% of the remaining payment value appeared to be agentic». Il resto è automazione ordinaria, script che avrebbero potuto girare senza alcuna AI.

Due dati di quell’analisi contano per l’opML. Il primo è che l’economia degli agenti, oggi, è più infrastruttura che adozione: si costruiscono le tubature prima che arrivi l’acqua. È lo stesso scarto tra promessa e utilizzo che, come vedremo, colpisce anche l’opML. Il secondo è che il 99,6% del valore regolato viaggiava in USDC su reti scelte proprio per commissioni basse e finalità rapida.

In altre parole, il caso d’uso che dovrebbe trainare l’opML premia la velocità di regolamento, esattamente la proprietà che una finestra di sfida non può offrire. È un contrasto che vale la pena tenere a mente: la domanda a cui l’opML vuole rispondere pretende una cosa che l’opML, per costruzione, fatica a dare. Se gli agenti si moltiplicheranno davvero, lo faranno su binari che chiedono conferme in millisecondi, non finestre di contestazione da minuti.

La collisione: la finestra di sfida contro il tempo reale

Arriviamo al punto. La sicurezza dell’opML, cioè la finestra di sfida, è strutturalmente in contrasto con le esigenze di tempo reale e componibilità dell’economia degli agenti. Non è una critica di parte: è la tesi centrale del paper «Optimistic TEE-Rollups» (arXiv 2512.20176), che scrive senza mezzi termini che gli approcci ottimistici «impose prohibitive dispute windows, preventing real-time interactivity». Gli stessi autori inquadrano il problema in un trilemma della verificabilità: un sistema di inferenza decentralizzata «cannot simultaneously achieve» integrità computazionale alta, latenza bassa e costo basso. Si possono avere due proprietà su tre; l’opML sceglie integrità e costo, e paga in latenza.

Il problema si aggrava in due modi. Il primo è la distinzione tra finalità debole e finalità forte: subito dopo la pubblicazione un risultato opML è provvisorio, e diventa davvero irreversibile solo alla chiusura della finestra. Un agente che agisce sulla finalità debole si espone a un ribaltamento; uno che aspetta la finalità forte è lento. Il secondo è la componibilità: se l’agente B dipende dall’output dell’agente A, deve attendere la finestra di A prima di poter chiudere la propria, e una catena di dipendenze moltiplica l’attesa. In un ecosistema in cui i protocolli si chiamano a vicenda di continuo, questo effetto a cascata è tutt’altro che teorico.

Un esempio concreto rende l’idea. Un agente legge un modello per decidere un trade: la risposta del modello arriva in pochi secondi, ma il trade non può considerarsi sicuro finché la finestra (da minuti a ore) non si chiude. L’agente ha due scelte, entrambe scomode: agire subito rischiando che quel risultato venga poi contestato e rovesciato, oppure aspettare e rinunciare all’opportunità che voleva cogliere. Non a caso l’architettura ibrida proposta dagli autori dell’OTR rivendica una finalità provvisoria sub-secondo, il 99% del throughput di un sistema centralizzato e un costo di circa 0,07 dollari per query, con un’accelerazione fino a 1.400 volte rispetto allo zkML puro: tutto il senso di quel lavoro è aggirare proprio il collo di bottiglia della finestra opML. Quando la soluzione a un problema è progettata per eliminarne il tratto distintivo, è un segnale che quel tratto è diventato un costo.

Chi controlla davvero? Il dilemma del verificatore

C’è una seconda crepa, più silenziosa. L’opML è sicuro finché esiste almeno un osservatore onesto che rifà i conti. Ma chi paga quell’osservatore per vigilare? Rieseguire un’inferenza costa tempo e potenza di calcolo, mentre la ricompensa (scoprire una frode rara) è incerta e sporadica. È il classico dilemma del verificatore: se ognuno confida che qualcun altro stia controllando, alla fine non controlla nessuno, perché per il singolo attore razionale il costo del controllo supera il beneficio atteso. Truebit aveva affrontato il problema con un meccanismo di errori forzati e un jackpot che teneva desti i verificatori; l’opML, allo stato, non ha una soluzione altrettanto rodata e distribuita.

Ne discende una domanda che nessuno ha ancora chiuso pubblicamente: una prova di frode è mai scattata davvero su OAO? Le richieste al sistema sono pubbliche e tracciabili, ma non risulta divulgato alcun episodio di contestazione andata a buon fine, né numeri di utilizzo che facciano pensare a un mercato di osservatori vivo e competitivo. In assenza di quei dati, è ragionevole sospettare che, nella pratica, la garanzia poggi più sulla buona fede dei nodi gestiti da Ora che su una platea di watcher indipendenti in perenne allerta. È esattamente quando la pressione sulla velocità spinge ad accorciare le finestre che questa fragilità diventa più preoccupante: meno tempo per contestare significa che l’ipotesi one-of-N deve reggere in una manciata di secondi, con incentivi ancora tutti da costruire.

I limiti strutturali: modelli chiusi, privacy e determinismo

Tre limiti strutturali completano il quadro. Il primo è il buco dei modelli chiusi. La prova di frode dell’opML ha senso solo se un contestatore può rieseguire in modo indipendente il calcolo, e questo richiede pesi aperti come Llama o Stable Diffusion. Le API proprietarie come GPT-4o possono essere inoltrate e attestate, ma non verificate dall’opML nello stesso senso: nessun osservatore ha i pesi per rifare il conto. È un problema serio per gli agenti, perché i modelli migliori sono spesso chiusi, e così proprio dove servirebbe più garanzia l’opML non riesce a darla.

Il secondo limite è la privacy: per essere contestabile, la traccia del calcolo deve essere pubblica, il che rende l’opML incompatibile con input o pesi riservati, a meno di combinarlo con prove zero-knowledge. Il terzo, forse il più insidioso, è il determinismo. La prova di frode funziona rieseguendo il calcolo e confrontando i risultati byte per byte, ma l’inferenza LLM su GPU è notoriamente non deterministica, per la non associatività dell’aritmetica in virgola mobile e per il modo in cui variano i batch a seconda del carico. Se due esecuzioni oneste divergono, il gioco di verifica non sa più chi punire. Non a caso i numeri in virgola mobile a 32 bit sono ostici da rappresentare nei circuiti delle prove crittografiche senza costi enormi, ed è la stessa ragione per cui questi sistemi ricorrono alla quantizzazione. Abbiamo dedicato un approfondimento al perché l’AI verificabile ha bisogno del determinismo.

opML a confronto: zkML, TEE e crypto-economico

L’opML è solo uno dei quattro grandi approcci al calcolo AI verificabile, e si capisce meglio confrontandolo con gli altri tre. Lo zkML dimostra tutto in anticipo con la crittografia (fiducia nella matematica, zero fiducia nell’operatore) al prezzo di un overhead enorme. I TEE (Trusted Execution Environment) si affidano all’attestazione dell’hardware: veloci e a basso overhead, ma bisogna fidarsi del produttore del chip e sperare che non esistano canali laterali. L’approccio crypto-economico (stake e slashing, come in EigenCloud) offre una garanzia economica, non crittografica: attaccare conviene solo se il bottino supera lo stake a rischio. L’opML sta nel mezzo: poco overhead di calcolo, nessuna fiducia nella matematica, ma latenza alta per via della finestra. La regola generale, come nota chi studia il settore, è che il calcolo a buon mercato tende a essere non verificabile e quello verificabile tende a costare; ogni approccio è un modo diverso di pagare quel conto.

Gli hybrid del 2026: l’opML prende in prestito dai rivali

La tendenza più chiara del 2026 è che quasi nessuno punta più sull’opML puro: i progetti più avanzati lo ibridano per accorciare la finestra o tappare i suoi buchi. La stessa Ora ha pubblicato opp/ai (arXiv 2402.15006), che a suo dire «integrates Zero-Knowledge Machine Learning (zkML) for privacy with Optimistic Machine Learning (opML) for efficiency»: lo zk copre il buco della privacy, l’opML tiene bassi i costi. Sul fronte della ricerca, proposte come lo zk-OPML usano prove zero-knowledge per ridurre la durata della disputa, mentre l’architettura Optimistic TEE-Rollups aggiunge un TEE per la finalità provvisoria rapida, prove di frode ottimistiche e controlli ZK a campione.

Il segnale è inequivocabile: la frontiera consiste nel prendere in prestito la solidità dello zkML e la velocità dei TEE. L’opML, da solo, resta una soluzione elegante per un sottoinsieme di problemi (calcolo non urgente, modelli aperti, costi contenuti), ma non è la risposta universale che il marketing dell’AI on-chain lascia talvolta intendere. Vale anche l’avvertimento di Vitalik Buterin, che nel suo saggio sull’incrocio tra crypto e AI invita a trattare con estrema cautela l’idea di usare l’AI come regola del gioco (vitalik.eth.limo): quando i soldi dipendono dall’output di un modello, ogni scorciatoia sulla verifica diventa una superficie di attacco.

Tecnologia viva, token illiquido: il caso ORA

C’è infine un divario che accomuna quasi tutti i token del calcolo verificabile: la tecnologia è viva, il token no. ORA ne è l’esempio più estremo. Secondo CoinGecko, il 26 settembre 2026 ORA valeva circa 0,0023 euro, con una capitalizzazione di appena 386.000 euro, un volume giornaliero attorno ai 160 euro (tanto sottile da rendere privi di significato gli scatti di prezzo a breve) e un calo di oltre il 99,9% dal massimo storico di 5,08 euro toccato nel novembre 2024. Non è un consiglio d’investimento e non c’è un evento specifico documentato dietro l’illiquidità: è semplicemente un mercato che ha smesso di scommettere sull’adozione, misurata in commissioni e utilizzo reale.

Il quadro è coerente in tutto il settore: ogni token dell’AI verificabile è tra l’85% e il 99,9% sotto il proprio massimo, pur poggiando su infrastruttura funzionante e tecnicamente credibile. È lo stesso scollamento tra domanda reale e valore del token che si osserva nel calcolo GPU decentralizzato, come abbiamo raccontato analizzando il rally di AKT e la domanda di GPU su Akash. Cosa potrebbe cambiare la storia di ORA? Dati di utilizzo reali e divulgati: milioni di inferenze pagate, un numero credibile di agenti attivi, una prova di frode scattata davvero. Finché quei numeri restano riservati, il token resta un’opzione su un’adozione che non si vede. La lezione per chi legge in ottica di investimento è prudenziale: un’infrastruttura può funzionare benissimo e il suo token restare marginale e illiquido.

Regole in Italia: Consob, MiCA e la zona grigia dei token AI

Sul piano normativo, il protocollo opML in sé non è regolato: non è un emittente né un fornitore di servizi. A rientrare nel perimetro sono semmai i token che lo pagano e i servizi costruiti sopra, soprattutto un agente che maneggia denaro dei clienti. In Italia il quadro è definito da MiCA, con Consob competente per condotta di mercato e tutela degli investitori e Banca d’Italia per gli aspetti prudenziali e sugli stablecoin (il decreto attuativo è il D.lgs. 129/2024); il periodo transitorio, nella versione abbreviata scelta dall’Italia, si è chiuso il 1 luglio 2026. Attenzione a una distinzione che pesa: i derivati crypto, come futures e perpetual, non ricadono sotto MiCA ma sotto MiFID II, sempre vigilata da Consob.

Il nodo più delicato riguarda proprio le Initial Model Offering. Un token di utilità come ORA vive in una zona grigia, da valutare caso per caso. Ma un token IMO che distribuisce i ricavi di un modello si avvicina molto di più a uno strumento finanziario: lo standard ERC-7641 su cui si basa (eips.ethereum.org) afferma testualmente che il token «in essence, embodies shares», con il diritto di riscattare una quota proporzionale dei ricavi. Un titolo che rappresenta una quota di ricavi assomiglia molto a un valore mobiliare, e finirebbe con ogni probabilità sotto MiFID II e la vigilanza Consob, non sotto il più leggero cappello di MiCA.

Oltre oceano la fotografia è simile: l’interpretazione congiunta SEC-CFTC del marzo 2026 ha qualificato come digital commodity token come Bitcoin, Ethereum e Solana, ma tace sull’infrastruttura di AI verificabile, lasciandola in un limbo (Ballard Spahr). Il contesto è quello che abbiamo descritto raccontando come, dopo lo stop alla legge CLARITY, SEC e CFTC abbiano ripreso a scrivere da sole le regole. Per un investitore italiano il messaggio è doppio: tecnologia interessante, ma token illiquido e status giuridico ancora incerto, da maneggiare con la prudenza che si riserva agli asset ad alto rischio.

Domande frequenti

Che cosa significa opML?

opML sta per optimistic machine learning. Un operatore esegue un modello di AI fuori dalla blockchain, pubblica on-chain il risultato con un impegno crittografico e apre una finestra di sfida: il risultato è considerato valido salvo che qualcuno lo contesti con una prova di frode entro la scadenza. L’idea è modellata sulle optimistic rollup.

Qual è la differenza tra opML e zkML?

Lo zkML dimostra la correttezza del calcolo in anticipo con una prova crittografica: è trustless e può preservare la privacy, ma su modelli grandi resta lento e costoso. L’opML presume la correttezza e si affida a una prova di frode entro una finestra di sfida: è molto più economico, ma introduce latenza, richiede almeno un osservatore onesto e funziona solo con modelli a pesi aperti.

Chi ha inventato l’opML?

L’opML è stato formalizzato dal team di Hyper Oracle, oggi Ora Protocol, nel paper arXiv 2401.17555 del gennaio 2024. Il meccanismo di verifica interattiva con bisezione deriva però da Truebit, il progetto di Jason Teutsch e Christian Reitwiessner, che lo aveva introdotto anni prima per l’esecuzione generica on-chain.

Perché la finestra di sfida è un problema per gli agenti AI?

Perché un risultato opML diventa davvero definitivo solo quando la finestra si chiude, da minuti a ore dopo. Gli agenti autonomi, invece, devono agire e concatenare operazioni in tempo reale. Il paper Optimistic TEE-Rollups descrive queste finestre come «prohibitive» per l’interattività in tempo reale, ed è il motivo per cui nel 2026 sono nate architetture ibride che le accorciano.

Il token ORA è un buon investimento?

Questo articolo non fornisce consigli d’investimento. Vale però ricordare che a fine settembre 2026 ORA aveva una capitalizzazione inferiore a 400.000 euro, un volume giornaliero di poche centinaia di euro e un calo di oltre il 99,9% dal massimo storico, con uno status normativo ancora incerto. È un caso da manuale di scollamento tra un’infrastruttura funzionante e un token marginale.

Marcus Okafor è redattore senior di HOGE Wire e segue l’intersezione tra intelligenza artificiale e crypto.