Eliza framework nel 2026: il token è morto, il codice no

Per quasi due anni Eliza è stata due cose contemporaneamente: un token che a un certo punto valeva oltre due miliardi di dollari e un pezzo di software open source per costruire agenti AI. Il 4 agosto 2026 le due cose si sono separate in modo definitivo. Il fondatore Shaw Walters ha dichiarato il token «morto, completamente» e ha annunciato la chiusura della fondazione dopo aver usato il tesoro residuo per chiudere una class action negli Stati Uniti. Il codice, però, è ancora lì: gira su GitHub, riceve commit ogni settimana e resta uno dei framework per agenti autonomi più usati del settore.

Questa guida spiega che cos’è davvero il framework Eliza (oggi elizaOS), come è fatto sotto il cofano, perché la fine del token non coincide con la fine del progetto e cosa comporta tutto questo per chi, in Italia, vuole capire o usare un agente AI on-chain.

Cos’è il framework Eliza (e perché se ne riparla adesso)

Eliza è un framework open source per costruire agenti AI: programmi software dotati di una personalità, di una memoria e della capacità di agire in autonomia su piattaforme di messaggistica e, attraverso un wallet, sulla blockchain. A differenza di un semplice bot di trading a regole fisse, un agente Eliza usa un modello linguistico (LLM) per interpretare i messaggi, decidere cosa fare e produrre una risposta o una transazione. Il progetto è nato come parte di un esperimento chiamato ai16z, poi ribattezzato elizaOS, ed è distribuito con licenza MIT, il che significa che chiunque può leggerlo, modificarlo e usarlo anche a scopo commerciale.

Se ne riparla ora per un motivo preciso: il token che ha reso famoso il progetto è appena finito. Ma la vicenda è interessante proprio perché mostra la distanza, spesso enorme, tra la qualità di un software e la quotazione di un asset. Il framework e il token sono due oggetti diversi, con destini diversi, e confonderli è l’errore più comune quando si parla di Eliza.

Nella pratica, con Eliza sono stati costruiti agenti di tipo molto diverso, e vale la pena averli in mente per capire di cosa parliamo.

• Agenti social con una personalità, che pubblicano e rispondono su X o Discord.
• Agenti di trading e tesoreria, che leggono dati di mercato e firmano transazioni.
• Agenti di supporto e automazione per le imprese, come il prodotto Agentic SME.
• Personaggi non giocanti (NPC) in giochi on-chain, che agiscono in autonomia.
• Agenti per la DeFAI, che interagiscono con protocolli DeFi e mercati di previsione.

Dalla scommessa ai16z al framework elizaOS: una breve storia

Il progetto parte nell’ottobre 2024, quando Shaw Walters lancia ai16z su Solana attraverso il launchpad daos.fun, con un obiettivo di raccolta modesto. La svolta arriva quando Marc Andreessen, cofondatore reale del fondo a16z, pubblica su X un secco «GAUNTLET THROWN» (guanto di sfida lanciato). Nel giro di poche ore la capitalizzazione schizza verso i cento milioni di dollari e il sito di daos.fun va in tilt, come ricostruito da The Block. L’idea era quella di un fondo guidato da un’AI, con due personalità pubbliche, una in stile venture capitalist e una più aggressiva, che valutavano le proposte della community in una sorta di «marketplace della fiducia».

Il nome ai16z ricalcava troppo da vicino quello di a16z. Il 28 gennaio 2025, dopo le richieste di distanziamento arrivate dal fondo di Andreessen, il progetto cambia nome in elizaOS, come raccontato da Decrypt. Da lì in poi la parola Eliza smette di indicare soltanto un fondo speculativo e diventa il nome del framework tecnico: la libreria che permette a chiunque di costruire il proprio agente. Nel novembre 2025 arriva la migrazione dal vecchio token ai16z al nuovo ELIZAOS, con un aumento programmato dell’offerta massima fino a undici miliardi di unità.

Vale la pena ricordare il contesto di quel momento: la fine del 2024 è stata l’apice dell’entusiasmo per gli agenti AI on-chain, con decine di token lanciati in poche settimane e capitali che si spostavano sull’onda dell’attenzione. In quel clima la promessa di un fondo gestito da un’intelligenza artificiale era esattamente il tipo di racconto capace di attrarre acquirenti. La distanza tra quella promessa e il funzionamento reale, con esseri umani che approvavano le operazioni, è la stessa che due anni dopo si è trasformata in una causa legale.

Il token è morto, il codice no: cosa è successo il 4 agosto 2026

Il 4 agosto 2026 Shaw Walters ha scritto su X che «il token è morto. Completamente. La fondazione sta chiudendo». La causa è una class action promossa dallo studio Burwick Law, che accusava il progetto di aver venduto ai16z come un fondo realmente autonomo mentre gli esseri umani approvavano le operazioni, e di aver sfruttato in modo improprio il richiamo al marchio a16z. Non avendo i mezzi per un contenzioso lungo, la fondazione ha trasferito il tesoro residuo ai possessori del token e ha chiuso. La vicenda è stata riportata da CoinDesk, Decrypt e crypto.news.

I numeri raccontano la parabola. Il token ha toccato un massimo di capitalizzazione attorno a 2,39 miliardi di dollari il 2 gennaio 2025 (oltre due miliardi di euro). Al momento in cui scriviamo, secondo CoinGecko, ELIZAOS vale meno di 0,0002 euro, con una capitalizzazione attorno a 1,3 milioni di euro e un posizionamento oltre la casella numero 2.300 per capitalizzazione: un crollo di oltre il 99,9% dal picco. Il fondatore è stato netto anche sul futuro: «Sto ricominciando da capo, dato che possiedo la proprietà intellettuale, e non lascerò mai più che un token si avvicini a Eliza». In altre parole, il framework prosegue senza un asset finanziario collegato.

Che cosa significa in pratica «token morto»? Non che smetta di esistere sulla blockchain: ELIZAOS continua tecnicamente a essere scambiato su alcuni exchange decentralizzati, ma senza tesoreria a sostenerlo, senza riacquisti e con una liquidità ridotta al minimo. Per chi lo detiene, il valore residuo è simbolico e la profondità di mercato è tale che anche piccoli ordini muovono molto il prezzo. È la differenza tra un asset che non viene più supportato e un software che continua a essere sviluppato: il primo si spegne lentamente, il secondo va avanti.

Come funziona un agente Eliza: runtime e character file

Sotto il cofano, un agente Eliza è la somma di alcuni componenti. Al centro c’è il runtime, cioè il motore che tiene insieme tutto: riceve i messaggi, costruisce il contesto, interroga il modello linguistico, decide quali azioni eseguire e aggiorna la memoria. Attorno al runtime ci sono i modelli (Eliza è agnostico rispetto al provider e può usare API come quelle di OpenAI oppure modelli aperti come Llama o Qwen), gli adattatori verso i database e i client verso le piattaforme.

La personalità dell’agente è definita in un character file: un file di configurazione che descrive il nome, la biografia, lo stile, gli argomenti di cui l’agente parla, gli esempi di conversazione e i plugin da caricare. È la parte che dà a ogni agente un carattere riconoscibile senza toccare il codice del framework. Questa scelta di progetto spiega perché con Eliza siano nati tanti agenti dalla forte identità: cambiare personalità significa cambiare un file, non riscrivere il software.

Il ciclo di lavoro si può riassumere in pochi passaggi che si ripetono a ogni messaggio: l’agente percepisce un input, raccoglie il contesto rilevante tramite i Providers, interroga il modello per decidere, esegue una o più Actions e infine lascia che gli Evaluators aggiornino la memoria. È un ciclo semplice da descrivere ma delicato da mettere in sicurezza, perché ogni passaggio può essere influenzato dai dati in ingresso. I mattoni fondamentali restano pochi.

• Runtime: il motore che coordina messaggi, modello, azioni e memoria.
• Modelli: l’LLM che interpreta e genera, con provider intercambiabili.
• Character file: nome, biografia, stile e plugin che definiscono l’agente.
• Plugin: i moduli che aggiungono capacità e integrazioni.
• Memoria: lo stato persistente che rende l’agente coerente nel tempo.

L’architettura a plugin: Actions, Providers, Evaluators e Services

Il cuore tecnico di Eliza è il sistema a plugin. Tutto ciò che estende un agente passa da un’unica interfaccia comune, documentata nel registro ufficiale dei plugin. Quattro primitivi ricorrono di continuo e conviene tenerli a mente, perché sono il vocabolario con cui si ragiona quando si costruisce su questo framework.

Il vantaggio di questo disegno è la modularità: un plugin che aggiunge il supporto a una nuova catena, a un exchange o a un protocollo DeFi si scrive una volta e si riusa ovunque. Attorno al registro ufficiale è cresciuto anche un ecosistema di fork: squadre di infrastruttura come Nethermind, tra i principali team di client Ethereum, e Automata Network, specializzata in attestazione hardware, mantengono propri registri e plugin. È un segnale che il framework viene preso sul serio da attori tecnici, non solo dalla community dei token.

Dal punto di vista dello sviluppatore, la forza di questo modello è che un plugin dichiara in un solo posto tutto ciò che aggiunge: azioni, provider, evaluator, servizi, rotte e gestori di eventi. Il ritmo di rilascio è sostenuto, con versioni che si susseguono anche a distanza di pochi giorni: un vantaggio per chi vuole funzionalità aggiornate, ma anche un motivo per fissare una versione stabile in produzione invece di seguire ogni beta.

Worlds, Rooms ed Entities: il modello della memoria e dei messaggi

Perché un agente sembri coerente nel tempo, deve ricordare. Eliza organizza conversazioni e memoria attraverso una gerarchia: le Entities sono gli attori (utenti e agenti), le Rooms sono i canali o i messaggi diretti in cui avviene lo scambio, i Worlds sono i contenitori più ampi, come un server o uno spazio di lavoro. Sopra questa struttura, gli Evaluators estraggono fatti e obiettivi dalle conversazioni e li salvano, così che l’agente possa richiamarli più avanti.

Questa memoria persistente è ciò che distingue un agente da un semplice completamento di testo, ma è anche il punto in cui si concentra buona parte dei rischi di sicurezza: se un attaccante riesce a inserire un falso ricordo, l’agente costruirà le decisioni successive su quel dato avvelenato. Ci torniamo tra poco. Nel corso del 2026 il progetto ha spinto verso un’architettura più orientata ai canali, segno che la parte di messaggistica resta in evoluzione attiva.

Nel concreto, quando l’agente deve rispondere, il runtime recupera dalla memoria i ricordi più pertinenti e li passa ai Providers, che li inseriscono nel prompt. Molte implementazioni usano rappresentazioni vettoriali (embedding) per trovare i ricordi simili a ciò di cui si sta parlando, un meccanismo vicino al retrieval augmented generation. È efficace, ma implica che la qualità e l’integrità della memoria pesino direttamente sulle decisioni: un ricordo sbagliato, per errore o per manipolazione, porta a una risposta sbagliata.

TypeScript, MIT e «sistema operativo agentico»: cosa c’è su GitHub

Il framework vive nel repository elizaOS/eliza, scritto in TypeScript e rilasciato con licenza MIT. I numeri, verificati sul repository, restano solidi: circa 19.100 stelle e 5.700 fork, con centinaia di issue e decine di pull request aperte. La descrizione ufficiale è ambiziosa: «Your agentic operating system», il tuo sistema operativo agentico. Il monorepo non contiene solo il runtime, ma anche l’applicazione Eliza, gli strumenti da riga di comando, i servizi cloud e i plugin di prima parte, con l’ambizione di girare su web, desktop, mobile e distribuzioni Linux.

Vale la pena essere prudenti con i confronti: capita di leggere che Eliza sia «il primo repository AI su GitHub» o cifre precise sulle stelle dei framework rivali, ma questi dati variano molto da fonte a fonte. Ciò che si può affermare con sicurezza è che elizaOS è tra i progetti open source più seguiti nella nicchia degli agenti AI, con un ritmo di rilascio veloce e una community attiva anche dopo la morte del token. La licenza MIT è la chiave della sua sopravvivenza: nessuno può togliere il codice dalla circolazione, e chiunque può proseguirlo.

Per chi vuole provarlo, il percorso tipico passa dagli strumenti da riga di comando del progetto: si parte da un modello di character file, si configurano le chiavi dei modelli e dei client e si avvia il runtime in locale prima di collegarlo a un wallet reale. La documentazione ufficiale su docs.elizaos.ai copre installazione, plugin e ciclo di vita dell’agente, ed è il punto di riferimento da tenere aperto mentre si lavora.

La sicurezza: memory injection, prompt injection e il problema dati contro istruzioni

Il problema di fondo degli agenti AI non è un difetto di Eliza in particolare, ma un limite dei modelli linguistici: non distinguono in modo affidabile tra le istruzioni del sistema e i dati che ricevono. Un ricercatore può nascondere un comando dentro un messaggio, un post o un finto ricordo, e il modello lo eseguirà come se venisse dal suo operatore. Un gruppo di ricercatori (tra cui accademici di Princeton) ha documentato proprio contro Eliza attacchi di questo tipo nel paper Real AI Agents with Fake Memories, che introduce il benchmark CrAIBench e mostra come falsi ricordi possano portare un agente a trasferire fondi non dovuti. La vulnerabilità è stata ripresa anche da Decrypt.

Non è teoria. Il 4 maggio 2026 un agente di un altro ecosistema è stato svuotato di circa 175.000 dollari con una combinazione di privilegi ottenuti tramite un NFT regalato e un comando nascosto in codice Morse dentro una risposta su X, come registrato dall’osservatorio incidenti dell’OCSE. Di fronte a questi rischi, Vitalik Buterin ha proposto di limitare a circa cento dollari al giorno le transazioni che un agente può firmare in autonomia, trattando l’essere umano e il modello come due firme distinte di uno schema 2-di-2. È il compromesso irrisolto del settore: più autonomia significa più utilità ma anche più superficie d’attacco, e i limiti che rendono un agente sicuro sono gli stessi che ne riducono l’autonomia.

Chi porta un agente Eliza in produzione ha comunque diverse leve per ridurre il rischio, la maggior parte delle quali è buon senso operativo prima ancora che codice.

• Limiti di spesa giornalieri e per singola transazione, come suggerisce Buterin.
• Approvazione umana per le operazioni oltre una certa soglia.
• Isolamento dei permessi: il wallet dell’agente non deve contenere più fondi del necessario.
• Liste di indirizzi e contratti consentiti, per bloccare destinazioni sconosciute.
• Monitoraggio e allerta in tempo reale sulle transazioni firmate.

Sono le stesse categorie di rischio che il progetto OWASP ha codificato per le applicazioni basate su LLM, dove la prompt injection occupa il primo posto della classifica. Nessuna di queste misure elimina il problema alla radice, ma insieme spostano il rapporto tra costo di un attacco e potenziale bottino a sfavore dell’attaccante. È un punto che vale per qualunque agente autonomo, non solo per quelli costruiti con Eliza.

Eliza a confronto con Virtuals, Olas, LangChain e CrewAI

Eliza non è l’unico modo per costruire agenti. Il panorama si divide tra framework nati nel mondo crypto e librerie generaliste importate dallo sviluppo software tradizionale. Virtuals Protocol è un launchpad no-code su Base e Solana, pensato per creare e monetizzare agenti; il suo token VIRTUAL, secondo CoinGecko, capitalizza ancora diverse centinaia di milioni di dollari, a differenza di ELIZAOS. Olas (Autonolas) offre uno stack in Python molto usato nella DeFAI e nei mercati di previsione. Dal lato non-crypto, LangChain e CrewAI sono librerie mature per orchestrare LLM e team di agenti, senza alcun token.

La lettura interessante è che i due framework più maturi e diffusi, LangChain e CrewAI, non hanno mai avuto un token. Eliza, che invece nasce con un token al centro, ha visto quel token bruciare valore mentre il codice restava valido. È un dato che pesa nella scelta di dove costruire, e che introduce il tema più ampio del momento.

La scelta pratica dipende dall’obiettivo. Per un agente con una forte identità pubblica, che vive sui social e interagisce on-chain, Eliza resta una delle opzioni più complete. Per un flusso di lavoro aziendale interno, senza personaggio e senza blockchain, una libreria generalista come LangChain o CrewAI può bastare e portare con sé un ecosistema più ampio di strumenti. Non è una gara a chi vince: sono strumenti pensati per problemi diversi.

Chi mantiene un framework senza fondazione? La domanda della governance

La morte del token apre una domanda concreta: chi mantiene un progetto open source da quasi ventimila stelle una volta che la fondazione che lo finanziava si dissolve? In pratica emergono tre modelli, non alternativi ma complementari. Il primo è Walters stesso, che possiede la proprietà intellettuale e ha promesso di continuare a sviluppare. Il secondo sono gli adottanti commerciali: aziende che costruiscono prodotti sopra il framework e hanno quindi un interesse diretto a tenerlo vivo. Il terzo è la community di volontari che invia pull request e mantiene i plugin.

Un esempio del secondo modello è il prodotto white-label «Agentic SME», nato da un accordo tra Secure Blockchain Development Corp e la fondazione Eliza per automatizzare vendite, amministrazione e assistenza clienti delle piccole imprese, costruito sopra elizaOS e atteso proprio nella finestra di metà agosto 2026, come indicato nella documentazione dell’accordo. Qui c’è un’ironia degna di nota: uno dei dirigenti coinvolti in quel progetto commerciale è anche tra i convenuti della causa Burwick. La stessa persona costruisce sul framework e figura nel contenzioso che ha ucciso il token, a conferma che codice e vicenda societaria viaggiano su binari separati.

Il modello del manutentore unico che possiede la proprietà intellettuale non è privo di rischi: se Walters cambiasse idea o rallentasse, il peso ricadrebbe sulla community e sui fork. Ma la storia dell’open source è piena di progetti sopravvissuti ai loro sponsor originari proprio grazie a licenze permissive come la MIT. Finché il codice resta libero e qualcuno ha interesse a usarlo, la manutenzione tende a trovare un nuovo equilibrio, anche se non sempre con la stessa velocità di prima.

Il «tokenless turn»: perché il settore si allontana dai token

Il caso Eliza non è isolato. Nel 2026 una parte crescente dell’infrastruttura AI-crypto avanza sul piano tecnico mentre i relativi token perdono valore. È lo stesso divario tra tecnologia che scala e token che crollano che abbiamo raccontato per il verifiable compute, dove le prove crittografiche hanno raggiunto traguardi importanti mentre gli asset collegati calavano del 90% e oltre. Nel complesso, la categoria degli AI agent secondo CoinGecko capitalizza circa 2,45 miliardi di dollari, ben lontano dai massimi dell’inizio 2025, con Venice (VVV) e Virtuals (VIRTUAL) in testa.

Il punto è che il valore che gli agenti creano tende a spostarsi verso ciò che consumano davvero: calcolo, dati e pagamenti. Reti come Render, che vendono capacità GPU, ed ecosistemi come Bittensor, che remunerano l’inferenza attraverso i subnet, catturano domanda reale. Un framework come Eliza, che è puro software, non ha bisogno di un token per funzionare: la morte di ELIZAOS non toglie una riga di codice al progetto, e questa è forse la lezione più chiara della vicenda.

C’è anche una lezione sul finanziamento. Un token può raccogliere capitali in fretta e attirare attenzione, ma è capitale speculativo: quando il prezzo crolla, spariscono sia i fondi sia gli incentivi a restare. La manutenzione di un software, al contrario, è un lavoro lento e continuo, mal servito da un asset che vive di cicli di hype. Il fatto che i framework senza token siano spesso i più solidi non è un caso, ma il segno che i due tempi, quello del mercato e quello dell’ingegneria, raramente coincidono.

La causa Burwick e il nodo dell’autonomia

La class action che ha chiuso il cerchio è Pikabea contro Walters e altri, depositata ad aprile 2026 alla corte federale del distretto sud di New York, il cui fascicolo è consultabile su Justia. Al centro c’è l’accusa che il fondo fosse presentato come realmente autonomo mentre, secondo un reportage di Protos già dell’ottobre 2024, le operazioni venivano di fatto approvate da esseri umani. Lo stesso Walters, in seguito, è stato più sincero della narrativa iniziale: «probabilmente non volete dare a un agente AI un mucchio di soldi aspettandovi che vi frutti di più», ha detto a Decrypt.

Al di là del singolo caso, la causa Burwick ha fissato un precedente per l’intero settore degli agenti a token. Tra le accuse c’era anche quella di una ripartizione poco trasparente nella migrazione, con una quota rilevante finita a investitori privati e al team piuttosto che ai possessori originari. Vero o meno che sia (le accuse non sono state provate in giudizio, perché si è arrivati a una transazione), il messaggio arrivato ai progetti simili è chiaro: promettere un’autonomia che non esiste e gestire la distribuzione dei token con leggerezza espone a un rischio legale concreto.

La causa è utile anche per capire quanto siano lente le dispute che coinvolgono le DAO. A un’udienza del maggio 2026, riportata dal servizio di cronaca giudiziaria InnerCityPress, il giudice Jed S. Rakoff si è mostrato insofferente per il fatto che i legali avessero tentato di notificare l’atto a Walters una sola volta: «Non farò avanzare il caso su questa base: un solo tentativo?», ha detto a verbale. Notificare gli altri convenuti, tra cui una DAO e una persona residente in Australia, richiede procedure ancora più complesse. È il motivo per cui molte azioni legali contro strutture decentralizzate si arenano prima ancora di entrare nel merito.

Cosa cambia in Italia: Consob, MiCA e la responsabilità dell’agente

Per un lettore italiano la domanda pratica è: chi risponde di un agente AI che opera on-chain? Il framework in sé non è un servizio regolato, ma le attività che ci si costruiscono attorno possono esserlo. In Italia il quadro è definito dal regolamento europeo MiCA, il cui periodo transitorio si è concluso il 1 luglio 2026: Consob vigila su condotta di mercato e tutela degli investitori, mentre Banca d’Italia si occupa degli aspetti prudenziali e degli stablecoin, secondo il D.lgs. 129/2024. Un punto spesso trascurato è che un agente non ha personalità giuridica: la responsabilità ricade sulla persona o sulla società che lo mette in produzione.

Ci sono due casi in cui il perimetro si sposta. Se un agente offre di fatto consulenza o gestione di portafoglio, si entra nel campo della MiFID II, con gli obblighi di governance e trasparenza che l’ESMA ha ribadito applicarsi anche quando è un’AI a operare. E se l’agente paga in stablecoin, come accade sempre più spesso nell’economia delle macchine, quei pagamenti ricadono sotto le regole MiCA per gli stablecoin. Sul versante statunitense il presidente della SEC Paul Atkins ha riassunto un approccio più leggero: «Il nostro compito è fissare le regole del gioco e arbitrare la partita, non scegliere la squadra vincente», ha dichiarato a maggio 2026. Vale la pena ricordare che la causa Burwick è stata un’azione privata, non un’iniziativa di un regolatore.

Sul piano fiscale il principio è coerente: gli eventuali guadagni realizzati da un agente sono imputati alla persona o all’entità che lo controlla, non all’agente, che non è un soggetto di diritto. Per chi opera in Italia questo significa che progettazione, custodia delle chiavi e adempimenti restano responsabilità umane, e che affidarsi a un software autonomo non trasferisce il rischio legale a nessun altro.

Conviene ancora costruire su Eliza nel 2026?

Per chi valuta il framework da un punto di vista tecnico, la morte del token cambia sorprendentemente poco. Eliza resta gratuito, maturo, scritto in un linguaggio diffuso come TypeScript e mantenuto attivamente. Non serve possedere o comprare ELIZAOS per farlo girare, e la licenza MIT garantisce che nessuno possa ritirarlo. I plugin coprono già molte catene e integrazioni, e l’architettura a quattro primitivi è comprensibile in poche ore.

Restano però tre domande da porsi prima di impegnare tempo o denaro. La prima è la governance: senza una fondazione, la manutenzione dipende da Walters, dagli adottanti commerciali e dalla community, e conviene verificare quanto sia vivo il repository nel momento in cui si decide. La seconda è la sicurezza: qualsiasi agente che tocca fondi va progettato con limiti di spesa, approvazioni umane e isolamento dei permessi, perché il rischio di prompt injection non è ipotetico. La terza è la conformità: in Europa la responsabilità è del principale umano, e un agente che consiglia investimenti o muove stablecoin entra in territori regolati.

Trattato come una libreria software solida e non come una scommessa su un asset, Eliza ha ancora molto senso. Trattato come un token, non ne aveva già più da tempo. Prima di scrivere la prima riga conviene rispondere a poche domande concrete.

• Il repository riceve ancora commit e rilasci regolari?
• I plugin che mi servono esistono e sono mantenuti?
• Quanti fondi toccherà l’agente e con quali limiti e approvazioni?
• Chi è il responsabile legale se qualcosa va storto?
• Ho un piano se il manutentore principale si ferma?

Domande frequenti

Che cos’è il framework Eliza (elizaOS)?

Eliza, oggi noto come elizaOS, è un framework open source scritto in TypeScript e rilasciato con licenza MIT per costruire agenti AI autonomi. Un agente Eliza combina un modello linguistico, una memoria persistente, una personalità definita in un character file e una serie di plugin che gli permettono di agire su piattaforme come Discord o X e, tramite un wallet, sulla blockchain.

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

Sì. Il 4 agosto 2026 il fondatore Shaw Walters ha dichiarato il token morto e ha avviato la chiusura della fondazione dopo aver ceduto il tesoro residuo per chiudere una class action. Il framework è però separato dal token: resta open source su GitHub, continua a ricevere aggiornamenti e non richiede ELIZAOS per funzionare.

In che linguaggio è scritto Eliza ed è davvero open source?

Eliza è scritto in TypeScript ed è distribuito con licenza MIT, una delle licenze permissive più usate. Il repository elizaOS/eliza conta circa 19.100 stelle e 5.700 fork su GitHub: chiunque può leggerlo, modificarlo e distribuirlo, anche a scopo commerciale.

Eliza è sicuro? Quali sono i rischi degli AI agent on-chain?

Il rischio principale non è un bug del codice ma il fatto che un modello linguistico non distingue in modo affidabile tra istruzioni e dati. I ricercatori hanno mostrato attacchi di memory injection e prompt injection capaci di far firmare a un agente transazioni non volute. Per questo esperti come Vitalik Buterin suggeriscono limiti stringenti agli importi che un agente può muovere in autonomia.

Conviene ancora costruire un agente su Eliza nel 2026?

Per un progetto tecnico la morte del token cambia poco: il framework è maturo, gratuito e mantenuto. I punti da valutare sono la governance (chi lo manterrà senza una fondazione), la sicurezza degli agenti che gestiscono fondi e gli obblighi normativi in capo alla persona o alla società che li mette in produzione.

Marcus Okafor è senior editor di HOGE Wire e segue il settore AI e crypto.