Ritual sotto il cofano: l’AI dentro lo smart contract

Ogni modello di intelligenza artificiale è, per chi lo interroga, una scatola nera: si invia una domanda, arriva una risposta, e bisogna fidarsi che dietro ci sia davvero il modello promesso e non una scorciatoia più economica. Una blockchain ragiona in modo opposto: ogni nodo riesegue la stessa operazione e deve ottenere lo stesso identico risultato, bit per bit, altrimenti la rete non raggiunge il consenso. Far entrare l’AI dentro uno smart contract significa tenere insieme due filosofie che a prima vista non si parlano, e Ritual è il progetto che ha deciso di provarci costruendo un’intera blockchain Layer 1 attorno a questo problema.

In questa guida non ci limitiamo a chiederci a cosa serva Ritual: apriamo il cofano. Cosa succede, passo dopo passo, quando un contratto chiede alla rete di eseguire un modello? Dove gira davvero l’inferenza, se una GPU non entra certo dentro un nodo di validazione? Come fa una catena deterministica a fidarsi di una risposta probabilistica? E perché, nonostante un testnet pubblico attivo e oltre 30 milioni di dollari raccolti, il token RITUAL continua a non esistere? Le risposte raccontano, meglio di qualsiasi slogan, che tipo di scommessa tecnica sia davvero Ritual, e dove stanno i suoi punti deboli.

Che cos’è Ritual: l’AI verificabile dentro lo smart contract

Ritual si definisce un’infrastruttura che rende l’inferenza dei modelli di AI verificabile e componibile all’interno degli smart contract. Tradotto: un contratto su una blockchain dovrebbe poter chiamare un modello linguistico o una rete neurale come se fosse una normale funzione, ricevere un risultato e avere una garanzia (crittografica o economica) che quel risultato sia stato calcolato correttamente, senza doversi fidare ciecamente di un server remoto. È la differenza fra «ti do la risposta» e «ti do la risposta più la prova che l’ho calcolata davvero così».

Il punto non è un vezzo da ingegneri. Oggi, se uno smart contract vuole usare l’output di un modello, deve affidarsi a un oracolo centralizzato o a un server fuori catena che dice «ecco il valore», senza che nessuno possa controllare se quel server ha usato il modello giusto, se lo ha eseguito davvero o se ha restituito un numero comodo. In finanza decentralizzata, dove un singolo valore (un prezzo, un punteggio di rischio, l’esito di un mercato predittivo) muove denaro reale, fidarsi sulla parola è un rischio sistemico. Ritual vuole trasformare quel «fidati» in un «verifica», e considera questa la precondizione perché l’AI possa gestire valore on-chain senza diventare l’anello debole.

La differenza con un semplice marketplace di GPU decentralizzate è netta. Reti come Akash affittano potenza di calcolo, altre coordinano modelli, ma non dimostrano l’onestà dell’esecuzione: ti danno il risultato, non la prova. Ritual mette la verificabilità al centro, e per ottenerla ha concluso che non bastava un protocollo applicativo in cima a Ethereum: serviva ripensare i tre strati più profondi di una catena, cioè la macchina virtuale che esegue il codice, il consenso che valida i blocchi e il mercato delle commissioni che prezza le risorse. Il resto di questo articolo smonta proprio questi tre strati.

Chi c’è dietro Ritual e quanto ha raccolto

Ritual nasce a New York nel 2023 dai fondatori Niraj Pant e Akilesh Potti, che avevano lavorato insieme per tre anni al fondo Polychain Capital. Pant arriva dal mondo degli investimenti Web3 (fra i suoi dossier EigenLayer e Solana), Potti è un ricercatore di machine learning con un passato da quant in Palantir. La combinazione (un investitore cripto e un ricercatore ML) spiega bene l’ambizione ibrida del progetto: non è né un puro protocollo DeFi né un puro laboratorio di AI, ma un tentativo di saldare le due culture a livello di infrastruttura.

Il round seed da 25 milioni di dollari, annunciato l’8 novembre 2023, è stato guidato da Archetype con la partecipazione, fra gli altri, di Accomplice, Robot Ventures, Accel, Dialectic e Anagram, oltre ad angel investor come Balaji Srinivasan e Keone Hon di Monad (CoinDesk). The Block ha poi stimato il totale raccolto oltre i 30 milioni di dollari entro la fine del 2024. In un settore in cui molti progetti AI-crypto esistono solo come whitepaper e un logo, è un capitale che ha permesso a Ritual di costruire davvero, ed è anche il motivo per cui vale la pena prenderlo sul serio nonostante l’assenza di una mainnet.

La tesi dei fondatori è esplicita e politica. «La concentrazione dell’AI in un piccolo gruppo di aziende potenti rappresenta una minaccia significativa per il futuro della tecnologia» ha dichiarato Pant alla presentazione del round; «abbiamo fondato Ritual per porre fine alla dipendenza dell’ecosistema da pochi soggetti, per aprire l’accesso a questa infrastruttura critica e garantire un futuro in cui si costruisca un’AI migliore». È la cornice ideologica (open, anti-oligopolio) dentro cui vanno lette tutte le scelte architetturali che seguono: se credi che l’AI debba essere un bene comune verificabile e non un servizio da affittare a scatola chiusa, allora costruisci una catena che la esegue in chiaro. Resta da capire se il mercato condivida la stessa urgenza.

Infernet: il pezzo di Ritual che gira già oggi

Prima della blockchain c’è Infernet, il primo prodotto di Ritual e l’unico già in produzione. È una rete di oracoli decentralizzata (una DON, decentralized oracle network) accompagnata da un SDK leggero che permette a uno smart contract su Ethereum, Base o Arbitrum di richiedere un’inferenza AI senza spostarsi da nessuna parte. Il flusso è semplice da immaginare: il contratto emette una richiesta, i nodi Infernet eseguono il modello (on-chain se è piccolo, fuori catena se è pesante) e riconsegnano il risultato al contratto chiamante, che può usarlo per decidere qualcosa.

Nella documentazione Ritual descrive Infernet come «il primo mattone di una suite di protocolli e utility» che «espone interfacce potenti affinché gli smart contract accedano ai modelli di AI per l’inferenza» (ritual.net). È la parte pragmatica del progetto: non chiede a nessuno di abbandonare la propria catena, si innesta su quelle che esistono già. Viene usata per agenti autonomi, logiche DeFi che si adattano alle condizioni di mercato, risoluzione di mercati predittivi e tutti i casi in cui un contratto deve prendere una decisione che richiede un modello e non una semplice formula.

Infernet ha però un limite strutturale, ed è esattamente il limite che giustifica tutto il resto del progetto. Vive sopra catene che non sono state pensate per l’AI, quindi la verifica dell’esecuzione resta in gran parte un problema aperto, delegato alla reputazione dei nodi o a schemi di garanzia costruiti caso per caso. Un oracolo AI su Ethereum può dirti qual è la risposta del modello, ma Ethereum non ha alcun modo nativo di controllare che quel nodo abbia eseguito il modello giusto. Per spingere la verificabilità fino in fondo, Ritual ha concluso che serviva una catena propria, progettata attorno all’AI invece che adattata a posteriori. Da qui la Ritual Chain.

La Ritual Chain: una Layer 1 sovrana, ancora in testnet

La Ritual Chain è una blockchain Layer 1 sovrana, compatibile con l’ecosistema Ethereum ma estesa per eseguire l’AI in modo nativo. A oggi vive come testnet pubblico: non esiste una mainnet, non esiste una data ufficiale di lancio e il token RITUAL che paga il gas ha 18 decimali ma vale zero, perché è confinato al testnet e si ottiene gratuitamente da un faucet. I parametri sono consultabili sulla documentazione ufficiale (docs.ritualfoundation.org) e li riassumiamo nella tabella qui sotto, perché sono la base concreta su cui poggia tutto il discorso architetturale.

Il blocco ogni 350 millisecondi non è un numero casuale: è una scelta che rivela a chi è destinata la catena. Gli utenti che Ritual immagina non sono persone che firmano una transazione ogni tanto, ma agenti software che reagiscono in tempi stretti, monitorano condizioni e si coordinano tra loro; per loro la latenza di un blocco da dodici secondi (quella di Ethereum) sarebbe un’eternità. Alla presentazione del testnet, Potti ha riassunto così la posta in gioco: «Il testnet della Ritual Chain abilita comportamenti utente completamente nuovi, prima impossibili in qualsiasi altro sistema, nell’interazione con l’AI. Non si tratta solo di AI: stiamo creando le fondamenta per la prossima generazione di piattaforme RaaS, reti di prover e marketplace di proprietà intellettuale» (The Block). È una dichiarazione che va oltre l’inferenza: descrive una piattaforma generale per costruirci sopra, non un singolo servizio.

EVM++: come Ritual allarga la macchina virtuale di Ethereum

Il cuore tecnico della Ritual Chain si chiama EVM++. L’idea è non buttare via la macchina virtuale di Ethereum (la EVM, dove girano gli smart contract scritti in Solidity) ma estenderla in modo retrocompatibile, così che il codice già pensato per Ethereum funzioni senza modifiche e in più si possano fare cose che su Ethereum sono impossibili. È la stessa strategia che rende la Ritual Chain appetibile a uno sviluppatore: non deve imparare un linguaggio nuovo, deve solo scoprire quattro nuove famiglie di capacità.

• Precompile per il calcolo pesante: istruzioni native per eseguire inferenza LLM, modelli ONNX, prove ZK, cifratura omomorfica e chiamate HTTP, senza doverle ricostruire a mano in Solidity.
• Scheduling nativo: transazioni programmate che si eseguono da sole a ogni blocco quando si verifica una condizione, senza bisogno di bot esterni (i cosiddetti keeper).
• Oracoli integrati (enshrined): l’accesso ai dati esterni è parte del protocollo, non un servizio appiccicato sopra.
• Account abstraction nativa: wallet programmabili e logiche di firma avanzate di serie, indispensabili per gli agenti che devono pagare e autenticarsi da soli.

Il concetto chiave da capire è il precompile. Nella EVM un precompile è un’operazione così comune o così costosa da essere «cablata» direttamente nel protocollo a un indirizzo fisso, invece di essere scritta come contratto in Solidity: Ethereum lo fa da anni per alcune primitive crittografiche, perché eseguirle come bytecode normale sarebbe proibitivo. Ritual porta questa logica all’estremo e la applica all’AI: chiamare un modello linguistico diventa, dal punto di vista dello sviluppatore, semplice come chiamare l’indirizzo 0x0802. La tabella seguente mappa i principali precompile confermati dalla documentazione, con i rispettivi indirizzi.

Sedici precompile in tutto, che la documentazione raggruppa in sette capacità: pensare, agire, ricordare, dimostrare, custodire segreti, pagare e autenticarsi. Non è marketing: ciascuna di queste parole corrisponde a uno o più indirizzi concreti che uno sviluppatore può chiamare. Un contratto che vuole classificare un’immagine chiama il precompile multimodale; uno che vuole una sintesi di un testo chiama l’LLM; uno che vuole leggere un dato dal web chiama l’HTTP. La complessità del calcolo è nascosta dietro un’interfaccia familiare.

Precompile e sidecar: dove gira davvero il modello

C’è un problema pratico che la tabella da sola non risolve: un modello linguistico da decine di miliardi di parametri non entra dentro il client di esecuzione di un nodo, e tantomeno dentro la EVM. Serve una GPU, serve memoria, serve tempo. Chiamare l’indirizzo 0x0802 è facile per lo sviluppatore, ma da qualche parte quel modello deve pur girare. Qui entrano i sidecar: ambienti di esecuzione affiancati al client principale che gestiscono il calcolo pesante fuori dal percorso critico del consenso. Quando un contratto invoca il precompile LLM, non è la EVM a far girare il modello, è un sidecar specializzato; il risultato poi rientra nel flusso della transazione come se fosse sempre stato lì.

Ritual raggruppa questi ambienti in quattro tipi: inferenza di machine learning e LLM, proving e verifica ZK, esecuzione dentro un TEE (trusted execution environment, un ambiente di esecuzione fidato) e astrazione di catena per parlare con altre reti. È un’architettura deliberatamente modulare: la stessa catena può ospitare un piccolo classificatore che gira replicato su tutti i nodi e, accanto, un LLM enorme che gira una volta sola dentro un enclave sicuro. La differenza fra questi due casi non è un dettaglio implementativo: è la risposta di Ritual alla domanda più difficile del progetto, cioè come una catena deterministica possa convivere con un calcolo che deterministico non è. Quella risposta ha un nome, Superposition, ed è il prossimo tassello.

Superposition: esecuzione replicata oppure delegata

Superposition è il nome che Ritual dà ai due modi in cui un calcolo può essere eseguito sopra lo stesso stato condiviso. Il primo è l’esecuzione replicata: ogni validatore riesegue l’operazione e tutti devono arrivare allo stesso risultato. È il modello classico della blockchain, perfetto quando il calcolo è deterministico e leggero (un modello ONNX piccolo, una funzione matematica, un controllo logico) ma impraticabile per un LLM, per due motivi distinti. Primo, il costo: far rieseguire un modello gigantesco a migliaia di nodi è uno spreco mostruoso. Secondo, e più sottile, la riproducibilità: l’inferenza su GPU raramente è identica bit per bit fra hardware diversi, per via dell’ordine delle operazioni in virgola mobile e del parallelismo, quindi i nodi rischierebbero di non concordare mai.

Il secondo modo è l’esecuzione delegata: il calcolo pesante (una chiamata a un LLM, una richiesta HTTP verso un’API esterna) avviene fuori catena, dentro un TEE, e la risposta viene legata crittograficamente alla richiesta tramite l’attestazione hardware. Il validatore non riesegue il modello: controlla l’attestazione, cioè la firma del chip che dice «questo risultato è uscito da questo codice, in un ambiente non manomesso». È il trucco che permette a una catena deterministica di inglobare un’operazione non deterministica senza rompere il consenso: non si replica il calcolo, si verifica una prova che il calcolo è avvenuto correttamente.

Attenzione però a non scambiare il TEE per una bacchetta magica. Un TEE non è una prova crittografica: è un’ipotesi di fiducia nel produttore del chip, e come ogni hardware può essere rotto. Lo ha ricordato in modo brutale l’attacco TEE.Fail, divulgato nell’ottobre 2025 da ricercatori accademici, che con attrezzatura da meno di mille dollari è riuscito a estrarre chiavi segrete e persino chiavi di attestazione da enclave Intel e AMD intercettando il bus di memoria (The Hacker News). Non è un cavillo accademico: chi progetta su Ritual deve sapere che l’esecuzione delegata sposta la fiducia dal server al chip, non la elimina. Abbiamo analizzato pregi e limiti di questo modello nel pezzo dedicato al calcolo riservato applicato all’AI verificabile, ed è una lettura utile per capire quanto sia fragile l’anello hardware di tutta la catena.

Symphony e l’integrità modulare: eseguire una volta, verificare molte

Rieseguire tutto su ogni nodo è sicuro ma costoso; delegare tutto a un TEE è efficiente ma sposta la fiducia su un produttore di chip. Symphony è il meccanismo di consenso con cui Ritual cerca una via di mezzo: un modello che la documentazione sintetizza come «esegui una volta, verifica molte volte» (Execute-Once-Verify-Many-Times). Alcuni nodi selezionati eseguono il calcolo ed emettono prove sintetiche (sub-proof) che gli altri possono controllare a costo ridotto, senza rifare l’intero lavoro. L’idea somiglia a quella dei rollup: pochi fanno il lavoro pesante, molti verificano a buon mercato.

La parte più interessante è che Ritual non impone un unico metodo di verifica. Parla di integrità computazionale modulare: a seconda del caso d’uso, la garanzia può arrivare da una prova ZK (zkML), da un TEE, da uno schema ottimistico con finestra di contestazione (opML) o da una garanzia probabilistica basata su campionamento. Ogni metodo ha un compromesso diverso fra solidità della garanzia, latenza e costo. Non esiste il metodo perfetto: esiste il metodo adatto al valore in gioco e alla reattività richiesta. La tabella li mette a confronto.

È lo stesso ventaglio di approcci che attraversa tutta l’AI verificabile. Chi vuole capire i limiti dello schema ottimistico, stretto fra la solidità (ma la lentezza) dello zkML e la praticità (ma la fragilità) dei TEE, trova un quadro dedicato nella nostra analisi su opML e le sue alternative. Vale la pena ricordare un dato tecnico: Vitalik Buterin, nel suo saggio sull’incrocio fra cripto e AI, ha avvertito che la componente non lineare di una rete neurale può imporre a una prova ZK un sovraccarico anche di due ordini di grandezza (vitalik.eth.limo). È il motivo per cui nel 2026 quasi nessuno usa un metodo solo: la tendenza del settore è combinarli in architetture ibride, e l’approccio modulare di Ritual è un modo per non legarsi le mani in anticipo.

Resonance: pagare hardware eterogeneo su una blockchain

Una blockchain normale ha un mercato delle commissioni a un lato solo: chi invia una transazione paga il gas, chi valida incassa, e tutto il lavoro è misurato con la stessa unità. Ma su Ritual il lavoro non è omogeneo: un nodo può dover far girare un LLM su GPU, un altro una prova ZK su CPU, un altro ancora una banale chiamata HTTP. Prezzare tutto con un’unica unità di gas sarebbe come far pagare allo stesso prezzo un caffè e un intervento chirurgico. Resonance è il mercato delle commissioni a due lati che Ritual propone per far incontrare domanda e offerta di risorse di calcolo eterogenee: abbina ogni richiesta al nodo con l’hardware adatto, al prezzo che quel tipo di lavoro merita, e permette ai nodi di specializzarsi (chi ha GPU potenti offre inferenza, chi ha CPU offre proving) invece di dover fare tutto.

È un pezzo spesso trascurato ma decisivo, perché è lì che si decide se una rete del genere può stare economicamente in piedi. Senza un mercato che prezzi correttamente la GPU rispetto alla CPU, o nessuno offrirebbe la risorsa scarsa, o la rete pagherebbe troppo per quella abbondante. Resonance è il tentativo di Ritual di risolvere a livello di protocollo un problema che le reti DePIN affrontano di solito con incentivi esterni e tornei di punti.

Allo stesso ordine di problemi appartiene lo scheduling nativo. Su Ethereum, se vuoi che qualcosa accada «ogni ora» oppure «quando il prezzo supera una soglia», devi pagare un bot esterno (un keeper) che invii la transazione al momento giusto; è un punto di fragilità e un costo ricorrente. Ritual integra la programmazione nel protocollo con un contratto di sistema Scheduler: una transazione può essere registrata una volta e poi eseguirsi da sola a ogni blocco quando la condizione è soddisfatta, senza alcun bot. Per un agente autonomo che deve ribilanciare un portafoglio, rinnovare una posizione o controllare un oracolo, è la differenza fra dipendere da un’infrastruttura esterna e vivere interamente dentro la catena.

Agenti sovrani e persistenti: il caso d’uso di punta

Tutta questa impalcatura (precompile, sidecar, Superposition, Resonance, Scheduler) serve a un fine che Ritual mette in primo piano: gli agenti AI che vivono sulla catena invece di girare su un server affittato. La documentazione distingue due tipi. Gli agenti persistenti (precompile 0x0820) hanno stato, memoria e riferimenti ai dati che sopravvivono fra una sessione e l’altra: non ripartono da zero ogni volta. Gli agenti sovrani (0x080C) sono più radicali: custodiscono le proprie chiavi, si auto-programmano tramite lo Scheduler, pagano dal proprio wallet e si fermano quando finiscono i fondi, eseguendo un harness in un ambiente TEE isolato. Non sono bot accesi ventiquattr’ore su ventiquattro su una macchina da qualche parte: sono processi che la catena stessa pianifica e finanzia.

In sintesi, un agente su Ritual dovrebbe poter fare sette cose senza appoggiarsi a un server esterno, ed è la lista delle sette capacità che la documentazione mette al centro.

• Pensare: eseguire un modello tramite i precompile.
• Agire: inviare transazioni on-chain.
• Ricordare: mantenere stato e memoria fra le sessioni.
• Dimostrare: allegare una prova di come è stato prodotto un output.
• Custodire segreti: gestire chiavi e dati cifrati dentro l’enclave.
• Pagare: spendere dal proprio wallet con un tetto di budget.
• Autenticarsi: firmare con passkey e schemi crittografici nativi.

È una visione che si sovrappone in parte a quella dei framework per agenti come ElizaOS, ma con una differenza di fondo. Nei framework l’agente è un software che gira altrove e usa la catena come semplice portafoglio e registro; su Ritual l’agente è un cittadino di prima classe del protocollo, con capacità garantite dalla catena stessa. Sul confronto fra le due filosofie, e sui limiti pratici dei framework (dalla gestione delle chiavi alla sicurezza), rimandiamo all’analisi sul framework Eliza e gli agenti on-chain. La domanda che resta aperta, e a cui torneremo, è se per avere questi agenti serva davvero una catena nuova o se basti un buon framework sopra una catena esistente.

Il token RITUAL non esiste (e perché è importante saperlo)

Qui serve chiarezza assoluta, perché è il punto su cui circola più disinformazione. Al momento non esiste alcun token RITUAL negoziabile, non c’è stata alcuna TGE (token generation event) e non è stato confermato alcun airdrop ufficiale. Il «RITUAL» di cui si parla è soltanto il token del gas del testnet: 18 decimali, nessun valore economico, si ottiene gratis da un faucet per pagare le transazioni di prova. Chiunque oggi offra di vendervi RITUAL vi sta vendendo qualcosa che non esiste, punto.

Questo non ha impedito la nascita di un’intera economia di aspettativa. Decine di guide agli airdrop invitano a «farmare» un’allocazione futura unendosi al Discord, accumulando ruoli e completando quest. Alcune arrivano a stampare cifre precise (si leggono numeri come «10 miliardi di token totali» e «50 milioni destinati all’airdrop») e persino intervalli di prezzo. Vanno trattate per quello che sono: speculazione di terze parti su un token inesistente. Le stesse guide, lette con attenzione, ammettono che Ritual non ha annunciato alcun airdrop ufficiale, nessuna data di lancio e nessun listino, e che i parametri di tokenomics riportati sono «segnaposto». Il rischio pratico è doppio: da un lato si perde tempo a inseguire un fantasma, dall’altro, più serio, ci si espone a truffe che sfruttano l’attesa, come finti portali di claim, siti di phishing e falsi token con lo stesso nome lanciati su altre catene. La regola di sopravvivenza è semplice: finché l’annuncio non arriva dai canali ufficiali di Ritual Foundation, qualsiasi RITUAL in vendita è falso.

Perché Ritual non lancia un token, visto l’appetito evidente del mercato? Le ragioni plausibili sono due e si rafforzano a vicenda. Una è tecnica: la mainnet non c’è ancora, e un token che gira attorno a una rete di sola prova sarebbe pura speculazione senza nulla da catturare. L’altra è legale, e merita una sezione a parte, perché è lì che si capisce quanto l’assenza di token sia anche una scelta difensiva.

Regolamentazione: fra AI Act europeo, MiCA e Consob

Finché non c’è un token, Ritual sfugge in buona parte alla regolamentazione cripto. In Europa il regolamento MiCA disciplina gli emittenti di cripto-attività e i fornitori di servizi (i CASP), non i protocolli in sé: senza un token negoziabile e senza un servizio offerto al pubblico, non c’è nulla che Consob (l’autorità italiana per la condotta di mercato e la tutela degli investitori, affiancata da Banca d’Italia per gli aspetti prudenziali e sulle stablecoin) possa classificare o autorizzare. Il decreto italiano di attuazione è il D.lgs. 129/2024 e il periodo transitorio MiCA per l’Italia si è chiuso il 1 luglio 2026, uno dei più brevi dell’Unione.

La cornice più pertinente, oggi, è semmai l’AI Act europeo, i cui obblighi sui modelli di uso generale (GPAI) sono in vigore dall’agosto 2025 e le cui facoltà di enforcement della Commissione sono operative dall’agosto 2026 (Commissione europea). Per un progetto come Ritual è un’arma a doppio taglio. Da un lato gli obblighi di tracciabilità, trasparenza e auditabilità dei sistemi di AI creano domanda proprio per l’inferenza verificabile, che è il mestiere di Ritual: una prova on-chain di come è stato prodotto un output è esattamente ciò che un regolatore potrebbe voler vedere. Dall’altro, un’infrastruttura che rendesse i modelli più opachi o più difficili da controllare finirebbe nel mirino. Ritual ha interesse a presentarsi come parte della soluzione, non del problema.

Se e quando un token arriverà, lo scenario cambia radicalmente. Negli Stati Uniti la SEC guidata da Paul Atkins ha proposto ad agosto 2026 una «Regulation Crypto Assets» (comunicato 2026-76) con un safe harbor condizionato: un token esce dalla definizione di «contratto di investimento» una volta che l’emittente «ha completato o cessato in modo permanente tutti gli sforzi manageriali essenziali» che aveva promesso (SEC). Tenere il token in sospeso finché la rete non è sufficientemente decentralizzata è, da questo punto di vista, anche una tattica difensiva: si evita di lanciare qualcosa che la SEC potrebbe trattare come un titolo non registrato. Il clima regolatorio statunitense resta però incerto: il CLARITY Act ha fallito il voto di procedura al Senato nel settembre 2026 e la stessa SEC si è ridotta a due commissari dopo l’uscita di Hester Peirce, un assetto che, come abbiamo raccontato, irrigidisce la postura dell’autorità sulle regole cripto proprio mentre il settore chiederebbe chiarezza.

Il panorama competitivo: serve davvero una catena dedicata?

La scommessa più grande di Ritual non è tecnica ma strategica: chiedere agli sviluppatori di migrare su una catena nuova. I concorrenti, quasi tutti, offrono l’AI verificabile come componente aggiuntivo sopra l’infrastruttura esistente, e con token già quotati. Chainlink, per esempio, ha lanciato in mainnet il Chainlink Runtime Environment (CRE), un livello di orchestrazione per il calcolo verificabile fuori catena, presentato esplicitamente come un livello di coordinamento e non come una blockchain indipendente. Il suo chief architect Uri Sarid lo descrive così: «Il Chainlink Runtime Environment mette insieme tutte le capacità eseguendo i workflow quando i loro trigger scattano e usando la comunicazione da DON a DON per collegare le varie capability DON» (Chainlink). Chainlink ha anche una propria definizione di inferenza verificabile che vale la pena leggere come contraltare, perché arriva allo stesso obiettivo senza chiedere a nessuno di cambiare catena.

Sul fronte dell’AI decentralizzata in senso ampio ci sono poi Bittensor, che coordina reti di modelli (subnet) attorno al token TAO, ed EigenCloud (ex EigenLayer), che punta sull’ETH in restaking come garanzia economica per servizi verificabili. Nessuno dei due fa esattamente ciò che fa Ritual, ma tutti competono per la stessa attenzione di sviluppatori e di capitali. La tabella mette a fuoco posizionamento e valore di mercato ai prezzi correnti; serve a ricordare un fatto scomodo per Ritual, cioè che i rivali hanno già una moneta su cui poggiare incentivi e liquidità, mentre Ritual gioca ancora a mani nude.

I prezzi sono rilevati da CoinGecko il 4 ottobre 2026 (TAO, LINK, EIGEN) e vanno presi come fotografia volatile, non come giudizio di valore. Il punto strategico resta: se il CRE di Chainlink o il restaking di EigenCloud offrono l’AI verificabile senza costringere nessuno a trasferirsi, perché uno sviluppatore dovrebbe adottare una catena intera con la sua liquidità da ricostruire da zero? La risposta di Ritual è che solo controllando macchina virtuale, consenso e mercato delle commissioni si può rendere l’AI un cittadino di prima classe invece di un servizio appiccicato sopra. È una tesi coerente, ma deve ancora vincere la prova del mercato. Sul perché i ricavi, e non la sola narrativa, stiano diventando il metro con cui si misurano queste reti, è utile il quadro su Bittensor e l’era dei ricavi.

Rischi, segnali da seguire e prospettive

L’architettura di Ritual è ambiziosa e internamente coerente, ma fra testnet e realtà c’è un salto che non è ancora stato fatto, ed è giusto tenerne conto. Il rischio principale è di esecuzione: non c’è una data di mainnet, e più a lungo la rete resta in prova, più aumenta la probabilità che i concorrenti bolt-on si prendano il mercato della verifica prima che Ritual arrivi a regime. C’è poi il rischio del modello di fiducia, già visto: l’esecuzione delegata poggia sui TEE, che non sono infallibili, e lo zkML sui modelli grandi resta costoso. Infine c’è il rischio di adozione: una catena nuova deve attrarre sviluppatori e liquidità, e la storia delle Layer 1 è un cimitero di tecnologie elegantissime che nessuno ha usato.

Dal lato opposto, i segnali da tenere d’occhio sono chiari e misurabili: una data di mainnet credibile; la prima dApp di produzione con volumi reali (non una demo da conferenza); un modello di token che chiarisca come la rete cattura valore e remunera chi la protegge; e l’ingresso di sviluppatori che costruiscono davvero sull’EVM++ invece di limitarsi a usare Infernet sopra Ethereum. Finché questi tasselli non si incastrano, Ritual resta la cosa più completa e insieme più rischiosa dell’AI-crypto: un’infrastruttura progettata con cura per un futuro che deve ancora dimostrare di essere necessario. Vale la pena seguirla da vicino, ma con gli occhi aperti e senza inseguire token che non esistono.

Domande frequenti

Che cos’è Ritual in parole semplici?

Ritual è un’infrastruttura AI-crypto che vuole far eseguire modelli di intelligenza artificiale dentro gli smart contract in modo verificabile. Ha due parti: Infernet, una rete di oracoli già attiva che collega catene come Ethereum, Base e Arbitrum ai modelli AI, e la Ritual Chain, una blockchain Layer 1 ancora in testnet che estende la EVM per eseguire l’AI in modo nativo.

Il token RITUAL esiste e si può comprare?

No. A oggi non esiste alcun token RITUAL negoziabile, non c’è stata alcuna TGE e non è stato confermato alcun airdrop ufficiale. Il RITUAL del testnet è solo il token del gas, senza valore economico, e si ottiene gratis da un faucet. Le cifre su «10 miliardi di supply» o «50 milioni per l’airdrop» che circolano online sono speculazione di terze parti, e chiunque offra di vendere RITUAL sta vendendo qualcosa che non c’è.

Che cosa significa EVM++?

EVM++ è l’estensione retrocompatibile della macchina virtuale di Ethereum su cui si basa la Ritual Chain. Aggiunge precompile per il calcolo pesante (inferenza LLM, modelli ONNX, prove ZK, cifratura), scheduling nativo senza bot esterni, oracoli integrati nel protocollo e account abstraction nativa. Il codice Solidity esistente continua a funzionare, con in più le capacità specifiche per l’AI.

Come fa una blockchain a verificare un’inferenza AI?

Ritual usa più metodi a seconda del caso. Per i modelli piccoli l’esecuzione è replicata: tutti i nodi rifanno il calcolo. Per i modelli grandi l’esecuzione è delegata a un TEE fuori catena e il risultato è legato alla richiesta tramite attestazione hardware. In più la rete può ricorrere a prove ZK (zkML) o a schemi ottimistici con finestra di contestazione (opML). Questo ventaglio è ciò che Ritual chiama integrità computazionale modulare.

Ritual è regolamentato in Italia?

No, perché non c’è un token né un servizio al pubblico da autorizzare. MiCA, applicato in Italia da Consob e Banca d’Italia, disciplina emittenti e fornitori di servizi, non i protocolli. La cornice più rilevante oggi è l’AI Act europeo, che impone obblighi di trasparenza e auditabilità ai sistemi di AI. Se in futuro arrivasse un token, allora entrerebbero in gioco la classificazione MiCA e, per il mercato statunitense, le proposte della SEC.

Di Marcus Okafor, redazione HOGE Wire. Questo articolo ha finalità puramente informative e non costituisce consulenza finanziaria o di investimento.