Eliza framework 2026: sistema operativo per agenti e gaming

Per qualche mese, tra la fine del 2024 e l’inizio del 2025, Eliza è stata il volto della corsa agli agenti AI on-chain. Il token che ne portava il nome valeva miliardi, un fondo gestito almeno sulla carta da un’intelligenza artificiale prometteva di battere il mercato e il repository su GitHub scalava le classifiche dei progetti open source più seguiti al mondo. Poi il token è morto, alla lettera: il 4 agosto 2026 il fondatore Shaw Walters ha dichiarato che era «finito, completamente». Eppure il codice viene aggiornato ancora oggi, ogni giorno. Questa guida spiega che cos’è nel 2026 il framework Eliza, come si è trasformato in quello che i suoi stessi autori chiamano un «sistema operativo per agenti» e perché la sua prossima scommessa non passa dalla finanza ma dai videogiochi.

Che cos’è il framework Eliza (e perché non va confuso con il token)

Eliza è un framework open source per costruire agenti AI autonomi: software che unisce un modello linguistico (il cervello che pianifica e interpreta), un wallet proprio, una memoria persistente e una serie di strumenti con cui agire, sia on-chain sia sui social. A differenza di un normale bot di trading a regole, un agente Eliza decide da sé quali azioni intraprendere e firma le proprie transazioni. Il progetto nasce da Eliza Labs, la società fondata da Shaw Walters, ed è scritto in TypeScript con licenza MIT: chiunque può leggerlo, copiarlo e modificarlo.

Il punto da chiarire subito è la differenza tra il framework e il token. Il framework è il codice, un insieme di librerie e strumenti che gira sul computer o sul server di chi lo usa. Il token ELIZAOS era invece un asset speculativo, nato dal fondo ai16z e poi migrato con il rebrand del progetto. I due hanno storie diverse e, come vedremo, destini opposti. Il paper accademico che descrive il sistema, «Eliza: A Web3 friendly AI Agent Operating System», lo definisce il primo framework agentico open source pensato per il web3 e insiste su un principio preciso: ogni aspetto di Eliza è un normale programma TypeScript sotto il pieno controllo del suo utente. Non una scatola nera, quindi, ma codice ispezionabile.

Questa impostazione spiega perché il framework sia sopravvissuto al crollo del token: chi lo adotta non compra una promessa finanziaria, ma un pezzo di infrastruttura software che può far girare da sé, senza chiedere permesso a nessuno.

Dal fondo ai16z al codice: una breve storia

La storia di Eliza è inseparabile da quella di ai16z, il fondo che l’ha resa famosa. Nell’ottobre 2024 Walters lancia ai16z sulla piattaforma daos.fun, su Solana, con un obiettivo di raccolta modesto, intorno ai 66 mila euro. Il progetto esplode quando il vero Marc Andreessen scrive su X «GAUNTLET THROWN», guanto di sfida lanciato: in poche ore la capitalizzazione supera i 90 milioni di dollari. All’inizio di gennaio 2025 arriva il picco, circa 2,39 miliardi di dollari (oltre due miliardi di euro), stando alle cronache di CoinDesk.

Da lì, la parabola discendente. A fine gennaio 2025 arriva il rebrand in ElizaOS, anche perché la vera a16z chiede di prendere le distanze dal nome. Nel novembre 2025 parte la migrazione dal vecchio ticker AI16Z al nuovo ELIZAOS. Nell’aprile 2026 una class action depositata a New York (Pikabea contro Walters e altri) accusa il progetto di aver gonfiato l’autonomia dell’agente, in realtà spesso guidato da mani umane, e di aver sfruttato in modo indebito il richiamo al marchio Andreessen. Ad agosto 2026 l’accordo che chiude la causa: la fondazione trasferisce agli holder quel che resta del tesoro e avvia la propria chiusura. Il token, di fatto, muore.

Il token è morto, il repository no: i numeri del 2026

Oggi i due mondi raccontano storie opposte. Sul fronte del token, i dati di CoinGecko fotografano un asset ridotto ai minimi: ELIZAOS vale circa 0,00016 dollari (poco più di 0,00014 euro), con una capitalizzazione intorno a 1,2 milioni di dollari (circa 1,06 milioni di euro), in posizione numero 2.895 per valore e un volume giornaliero di appena 323 mila dollari. È oltre il 98% sotto il massimo storico di 0,01078 dollari toccato il 7 novembre 2025, e a un soffio dal minimo storico. Il vecchio sogno da oltre due miliardi è archiviato.

Sul fronte del codice, invece, il repository elizaOS/eliza continua a crescere: circa 19.500 stelle, 5.800 fork, oltre trecento pull request aperte e commit quotidiani, con una descrizione che recita «sistema operativo agentico open source». La qualità del software, insomma, non ha seguito il prezzo del token verso il basso.

Walters ha tirato le somme senza giri di parole. «Il token è morto. Completamente.», ha scritto su X, aggiungendo che non ci sarebbero stati ulteriori interventi della fondazione, né riacquisti né misure sull’offerta. Aveva detenuto token per circa 25 milioni di dollari, ormai ridotti quasi a zero. Il fondatore ha spiegato di voler ripartire da capo: possiede la proprietà intellettuale del framework e non intende più legare un token a Eliza. È la sintesi più netta della lezione di questo ciclo: la qualità di un progetto open source e il prezzo del suo token possono divergere del tutto, e spesso lo fanno.

Sotto il cofano: runtime, character file e i quattro primitivi

Per capire perché tante squadre continuino a costruirci sopra, conviene aprire il cofano. Al centro di Eliza c’è l’AgentRuntime, il motore che coordina tutto: riceve i messaggi, decide le azioni, gestisce la memoria e chiama il modello linguistico. La personalità e le competenze dell’agente sono definite in un file di configurazione, il character file, che descrive tono, conoscenze, piattaforme collegate e comportamenti. Cambiando quel file si ottiene un agente diverso senza toccare il resto del codice.

Tutto il resto passa attraverso un’unica interfaccia a plugin, e quasi ogni funzione si riduce a quattro primitivi. Le Actions sono ciò che l’agente può fare (inviare una transazione, pubblicare un post, chiamare un’API). I Providers iniettano il contesto: dati di mercato, saldo del wallet, ora corrente, cronologia. Gli Evaluators lavorano dopo la risposta, per estrarre fatti, aggiornare la memoria o valutare l’esito di un’azione. I Services gestiscono le integrazioni di lunga durata, come la connessione a Discord o a una blockchain.

Sopra questi mattoni sta il modello dei messaggi, organizzato in Worlds (lo spazio, per esempio un server), Rooms (i canali o le chat) ed Entities (utenti e agenti). La memoria si appoggia a un archivio con ricerca semantica (RAG), così l’agente può richiamare ciò che ha imparato. Infine, i model provider sono intercambiabili: si può usare un servizio cloud oppure, ed è una scelta sempre più consigliata per motivi di sicurezza, un modello eseguito in locale.

Da framework a «sistema operativo per agenti»

Il cambio di descrizione del repository, da semplice framework a «sistema operativo agentico», non è solo marketing. L’idea è che un agente autonomo non abbia bisogno soltanto di una libreria per parlare con un modello, ma di uno strato che gli gestisca identità, memoria, wallet, permessi e strumenti nel tempo, esattamente come un sistema operativo fa con i processi di un computer. Il paper di Eliza Labs va in questa direzione, presentando il progetto come l’ambiente in cui un agente vive e opera dentro il web3.

Su questa base Walters rivendica dimensioni ragguardevoli. In un’intervista a BlockchainGamer.biz ha parlato di «oltre 250 plugin», del supporto al protocollo MCP (lo standard con cui i modelli si collegano a strumenti esterni) e di quello che definisce «il framework end-to-end più completo». Ha anche annunciato che Eliza sta arrivando «in Rust e Python», oltre al TypeScript originario, per allargare la platea di sviluppatori. Attenzione, però, a non correre: le versioni Rust e Python sono state annunciate ma non ancora rilasciate in forma stabile, e vanno prese come una direzione di sviluppo, non come un prodotto pronto.

C’è poi un tema di potenza di calcolo. Un agente che ragiona in continuazione consuma inferenza, e l’inferenza costa GPU. È la stessa domanda che sostiene le reti di calcolo decentralizzato come Akash, dove il prezzo del token dipende proprio dalla richiesta di schede grafiche. Più gli agenti diventano numerosi e attivi, più questo strato infrastrutturale conta.

La scommessa sul gaming: Hyperia e il «RuneScape per agenti»

La parte più sorprendente della seconda vita di Eliza non riguarda la finanza ma i videogiochi. La tesi di Walters è che i giochi siano il banco di prova ideale per addestrare agenti capaci di agire davvero: «giocare ai videogiochi è la strada per arrivare ad agenti che fanno un lavoro vero», ha detto a BlockchainGamer.biz. In un gioco un agente deve fissare obiettivi, pianificare, usare strumenti, cooperare o competere: esattamente le abilità che servirebbero fuori dal gioco, ma in un ambiente sicuro dove un errore non svuota un wallet.

Il progetto concreto si chiama Hyperia. Il suo repository, HyperscapeAI/hyperscape, lo descrive come «il primo MMORPG AI-native in cui agenti autonomi giocano accanto agli umani». È costruito su una versione modificata di Hyperfy, un motore 3D multiplayer open source, con combattimento a tick, un sistema di abilità (taglialegna, estrazione mineraria, pesca) e un’economia interna. Gli agenti, integrati proprio via ElizaOS, non sono NPC scriptati: usano modelli linguistici per decidere cosa fare, e c’è persino una modalità spettatore per guardarli giocare. Con appena 97 stelle su GitHub e la scritta «in sviluppo» ripetuta più volte, resta un cantiere aperto, non un titolo giocabile.

L’aspetto che interessa a chi guarda ai costi è l’economia della produzione. Secondo Walters la scommessa è realizzare un gioco in stile RuneScape spendendo circa 80 mila dollari, contro i sei milioni di un titolo tradizionale, e farlo in quattro mesi, usando proprio gli agenti come forza lavoro creativa. È una proiezione dell’autore, non un dato consuntivo, ma spiega perché per Eliza il gaming non sia un diversivo: è il modo per dimostrare che un esercito di agenti può costruire e popolare interi mondi. Per un lettore di HOGE Wire è anche il punto in cui il filone crypto e quello gaming si toccano più da vicino.

L’ecosistema dei plugin: chi ci costruisce davvero

Un framework vale quanto l’ecosistema che gli cresce attorno, e qui Eliza ha un segnale interessante: non sono solo hobbisti a prenderlo sul serio. Oltre al registro ufficiale dei plugin esistono fork mantenuti da squadre di infrastruttura note. Automata Network, specializzata in attestazione on-chain, gestisce un proprio registro e un plugin che usa l’attestazione remota Intel DCAP per provare che un agente giri davvero dentro un ambiente protetto. Anche Nethermind, tra i principali team di client per Ethereum, mantiene un fork del registro. Sono presenze che dicono molto: chi costruisce le fondamenta della rete considera Eliza uno standard con cui vale la pena confrontarsi.

Sul piano commerciale il modello è quello tipico dell’open source senza token: si vendono prodotti e servizi costruiti sopra il framework, non l’accesso al framework. Alcune società hanno siglato accordi per offrire automazione chiavi in mano a piccole e medie imprese usando elizaOS come motore. Il supporto al protocollo MCP amplifica ulteriormente la portata: qualsiasi strumento compatibile con lo standard diventa collegabile a un agente Eliza senza scrivere un plugin da zero.

Il risultato è un ecosistema che assomiglia più a Linux che a una startup: nessuno possiede il codice, molti ci costruiscono sopra prodotti proprietari e il valore economico si sposta dai token alle applicazioni. È una struttura meno spettacolare di un lancio da due miliardi, ma anche molto più difficile da uccidere.

Eliza contro gli altri: il confronto tra framework

Eliza non è sola. Il campo degli strumenti per costruire agenti si è affollato, e vale la pena collocarla rispetto ai principali rivali. Virtuals Protocol punta su un lancio no-code degli agenti, con un forte legame tra agente e token; Olas (Autonolas) si concentra su servizi autonomi coordinati e su un marketplace tra agenti; LangChain e CrewAI, nati fuori dal mondo crypto, dominano l’orchestrazione di agenti in ambito enterprise ma non hanno un’anima on-chain nativa. Eliza si distingue per la combinazione tra apertura totale (licenza MIT), integrazione web3 di serie e l’ambizione da sistema operativo.

La differenza cruciale, e in parte controintuitiva, è che il progetto con il token più martoriato resta uno dei più solidi sul piano tecnico. È il paradosso che accompagna Eliza da oltre un anno: la classifica dei prezzi e quella dell’ingegneria non coincidono quasi mai.

Il wallet come confine di fiducia: la sicurezza degli agenti

Dare a un software autonomo le chiavi di un wallet significa spostare il confine della fiducia. Un agente che può firmare transazioni è, nella pratica, un firmatario cieco: esegue ciò che il modello decide, e il modello può essere ingannato. È qui che nascono i problemi più seri.

Il primo vettore è il prompt injection (nella classifica OWASP degli LLM è la voce LLM01): un’istruzione malevola nascosta in un testo che l’agente legge, per esempio un post sui social o il contenuto di una pagina, viene scambiata per un comando legittimo. Il modello non sa distinguere l’istruzione dai dati. Il secondo, più insidioso, è la memory injection. Un gruppo di ricercatori di Princeton (Atharv Singh Patlan, Peiyao Sheng, Ashwin Hebbar, Prateek Mittal e Pramod Viswanath) lo ha documentato nel benchmark CrAIBench: avvelenando la memoria persistente di un agente si ottengono comportamenti dannosi in modo più affidabile che con il solo prompt injection, perché una volta corrotto il contesto memorizzato le difese contro il prompt injection servono a poco. Lo studio nota che non esiste alcuna verifica di integrità sulle voci di memoria, e all’epoca dell’analisi gli agenti costruiti su ElizaOS gestivano oltre 25 milioni di dollari.

Che non sia teoria lo mostra un caso reale, seppure non su Eliza. Il 4 maggio 2026 un agente collegato al servizio Bankr è stato indotto a trasferire circa 175 mila dollari in token: l’attaccante aveva nascosto un’istruzione in codice Morse in una risposta su X e sfruttato un NFT regalato per ottenere permessi. È la stessa classe di attacco che minaccia qualunque agente dotato di wallet.

La risposta più citata è quella di Vitalik Buterin. Nel suo intervento sugli LLM sicuri consiglia di ridurre al minimo la superficie d’attacco: «Tutta l’inferenza LLM prima di tutto in locale. Tutti i file ospitati in locale. Isolare ogni cosa in sandbox». Propone inoltre di trattare umano e modello come una firma congiunta, una sorta di 2-di-2, con tetti bassi sulle transazioni che l’agente può eseguire da solo. Non è un caso che lo stesso Walters, parlando di agenti a cui affidare denaro, abbia ammesso a Decrypt che «probabilmente non è una buona idea dare un mucchio di soldi a un agente AI aspettandosi che te ne faccia guadagnare di più». Sono accorgimenti che riducono il danno, non che eliminano il problema di fondo.

Verifica e compute: cosa si può dimostrare e cosa no

Attorno agli agenti è cresciuta un’intera filiera dedicata a rendere verificabile ciò che accade dentro il modello. L’idea è dare prove crittografiche o hardware del fatto che un calcolo sia stato eseguito correttamente e, in alcuni casi, in modo riservato. Le strade sono diverse. C’è l’esecuzione dentro ambienti hardware protetti (TEE), che attestano l’integrità del processo. C’è l’approccio opML, che permette di contestare un’inferenza con prove di frode, un tema che abbiamo affrontato chiedendoci se si possa tokenizzare un modello di AI. Ci sono le prove a conoscenza zero applicate al machine learning (zkML). E ci sono progetti che spostano tutto su catene dedicate, come Ritual, o che rendono verificabile l’addestramento su nodi non fidati, come Gensyn.

Qui però serve una precisazione che spesso si perde nel marketing. La verifica del calcolo dimostra che il modello ha eseguito esattamente quel calcolo, e magari che lo ha fatto senza rivelare i dati. Non dimostra che l’istruzione fosse legittima. Un agente perfettamente verificabile può comunque essere vittima di prompt o memory injection: la prova certifica il come, non il perché. La compute verificabile è quindi necessaria per la fiducia, ma da sola non basta a rendere sicuro un agente con un wallet. È un punto che chiunque valuti questi sistemi dovrebbe tenere sempre presente, per non scambiare una garanzia tecnica parziale per una garanzia totale.

Chi mantiene un framework senza fondazione?

La morte del token apre una domanda scomoda: chi paga per il mantenimento? Un progetto con quasi 20 mila stelle su GitHub richiede lavoro continuo, e la fondazione che lo sosteneva è in chiusura, senza tesoro né riacquisti di token a finanziare gli sviluppatori. Le risposte possibili sono tre, non alternative tra loro.

La prima è Walters stesso, che possiede la proprietà intellettuale e ha promesso di continuare a costruire ogni singolo giorno. La seconda sono gli adottanti commerciali: i team di infrastruttura e i fornitori di automazione per imprese hanno un interesse economico diretto a che il framework resti vivo e sicuro, e possono contribuire codice e risorse. La terza è la comunità di volontari, il modello classico dell’open source, fragile ma resiliente: è così che sopravvivono molte librerie critiche su cui gira mezza internet.

Il rischio, evidente, è la sostenibilità. Senza un flusso di ricavi legato al codice, il mantenimento dipende dalla buona volontà di chi ci guadagna altrove. È lo stesso dilemma di tanto software libero, con una differenza: qui il progetto ha già attraversato un ciclo completo di entusiasmo e delusione, e deve dimostrare di valere anche senza la benzina della speculazione. Paradossalmente, la scomparsa del token potrebbe rendere l’ecosistema più sano, perché allinea gli incentivi sull’uso reale e non sul prezzo.

Quanto vale (ancora) il settore degli agenti AI

Eliza vive dentro un settore che, nonostante gli alti e bassi, resta grande. La categoria «AI Agents» monitorata da CoinGecko capitalizza circa 4,1 miliardi di dollari (intorno a 3,6 miliardi di euro), con un volume giornaliero vicino ai 521 milioni. In cima ci sono progetti molto diversi tra loro: Venice (VVV), l’alleanza ASI (FET), Virtuals (VIRTUAL), Kite (KITE) e OriginTrail (TRAC).

Il confronto è impietoso per il token di Eliza, ridotto a poco più di un milione di euro mentre i primi della categoria valgono centinaia di milioni. Ma racconta anche una tendenza più ampia: il valore si sta spostando dalle scommesse sui singoli token-agente verso l’infrastruttura (calcolo, pagamenti, identità) e verso i framework che restano utili a prescindere dal loro token. È la svolta senza token che attraversa tutto il comparto, e di cui Eliza, suo malgrado, è diventata il caso di scuola.

Regole e fisco in Italia: Consob, MiCA e MiFID II

Per un lettore italiano la domanda è concreta: che cosa dicono le regole? La prima distinzione utile è che il framework in sé non è un oggetto regolato. È codice open source, come un compilatore o un database: usarlo o modificarlo non richiede autorizzazioni. La parte regolata era il token, ed è anche la parte che ha creato problemi legali.

Il regolamento europeo MiCA copre gli asset crypto a pronti e i servizi su di essi (scambio, custodia, collocamento), affidati in Italia alla vigilanza di Consob per la condotta di mercato e di Banca d’Italia per i profili prudenziali, secondo il D.lgs. 129/2024. Ma MiCA è pensato per token e strumenti, non per software autonomo: un agente non rientra nel suo perimetro più di quanto vi rientri un foglio di calcolo. È lo stesso motivo per cui buona parte della finanza decentralizzata resta fuori dalle maglie del regolamento, un tema che abbiamo trattato parlando del perimetro di MiCA rispetto alla DeFi.

Le cose cambiano se l’agente fa qualcosa di più che eseguire ordini. Se offre consulenza sugli investimenti o gestisce un portafoglio si entra nell’ambito della MiFID II, vigilata sempre da Consob, e valgono i principi che l’ESMA ha fissato sull’uso dell’AI nei servizi di investimento: governance, trasparenza e supervisione umana. C’è poi un vuoto strutturale: un agente non ha personalità giuridica né codice fiscale, quindi la responsabilità ricade sempre sulla persona o sulla società che lo controlla; per questo la vigilanza resta saldamente in capo alle autorità umane, con Consob come punto di riferimento italiano.

Sul piano fiscale, dal 1 gennaio 2026 le plusvalenze crypto in Italia sono tassate al 33%, mentre restano al 26% le stablecoin in euro conformi a MiCA (gli EMT), come ricorda FiscoOggi. Per un agente questo ha una conseguenza pratica: ogni operazione che genera una plusvalenza è un evento tassabile in capo al titolare del wallet, e un’attività ad altissima frequenza rischia la riqualificazione come reddito d’impresa. Non sono dettagli da poco per chi pensasse di lasciare un agente a operare 24 ore su 24.

Frequently Asked Questions

Che cos’è il framework Eliza (elizaOS)?

Eliza è un framework open source con licenza MIT, sviluppato da Eliza Labs, per costruire agenti AI autonomi che uniscono un modello linguistico, un wallet, una memoria e strumenti per agire on-chain e sui social. È scritto in TypeScript e, secondo i suoi autori, si sta trasformando in un vero e proprio sistema operativo per agenti.

Il token ELIZAOS è morto? Cosa cambia per il framework?

Sì. Il 4 agosto 2026 il fondatore Shaw Walters ha dichiarato il token «finito, completamente» e ha avviato la chiusura della fondazione dopo un accordo legale. Il framework però è cosa diversa dal token: il codice resta open source, viene aggiornato ogni giorno e continua a essere usato, perché la sua utilità non dipende dal prezzo dell’asset.

Cos’è Hyperia e perché Eliza punta sul gaming?

Hyperia è un MMORPG AI-native in sviluppo in cui agenti autonomi costruiti su ElizaOS giocano accanto agli umani, usando modelli linguistici per fissare obiettivi e agire. Per Shaw Walters i videogiochi sono un banco di prova sicuro per addestrare agenti capaci di pianificare e usare strumenti, competenze utili anche fuori dal gioco.

È sicuro affidare un wallet a un agente costruito con Eliza?

Comporta rischi concreti. Un agente può essere ingannato con il prompt injection o, in modo più insidioso, avvelenandone la memoria, come ha mostrato il benchmark CrAIBench dei ricercatori di Princeton. Le difese consigliate (esecuzione in locale, isolamento in sandbox, tetti di spesa e approvazione umana) riducono il danno ma non eliminano il problema di fondo: il modello non distingue con certezza le istruzioni dai dati.

Come sono tassati in Italia i guadagni realizzati da un agente AI?

I guadagni sono attribuiti al titolare del wallet. Dal 1 gennaio 2026 le plusvalenze crypto sono tassate al 33%, mentre le stablecoin in euro conformi a MiCA restano al 26%. Ogni operazione che genera una plusvalenza è un evento tassabile, e un’attività molto frequente può essere riqualificata come reddito d’impresa.

Un articolo di Marcus Okafor per HOGE Wire.