Eliza framework 2026: agenti AI con wallet e il nodo della fiducia

Il 4 agosto 2026 il fondatore Shaw Walters ha scritto tre parole che hanno chiuso una delle storie più chiacchierate della cripto-AI: «The token is dead. Completely». Con quella frase, ripresa da CoinDesk e da The Block, Walters annunciava anche lo scioglimento della fondazione, dopo aver trasferito la tesoreria residua per chiudere una class action. Eppure, cinque settimane dopo, il framework Eliza continua a pubblicare codice praticamente ogni giorno. È il paradosso che definisce questo progetto nel 2026: il token è morto, il codice no.

Se un progetto AI-crypto sopravvive alla morte del proprio token, cosa resta davvero? E soprattutto: ci si può fidare di consegnare un wallet a un agente costruito con quel codice? Questa guida spiega che cos’è il framework Eliza (da non confondere con il token ELIZAOS), come funziona un agente costruito con esso, quali sono i rischi di sicurezza che oggi contano più di ogni altra cosa, chi lo mantiene ora che la fondazione chiude, e che cosa significa tutto questo per chi, in Italia, vuole usarlo o costruirci sopra. Per dare la misura del crollo: a inizio settembre 2026 ELIZAOS quota circa 0,00014 euro (0,0001632 dollari), per una capitalizzazione di circa 1,05 milioni di euro e la posizione numero 2746 secondo CoinGecko, contro un picco che valeva circa 2,4 miliardi di dollari.

Che cos’è il framework Eliza (e perché non è il token ELIZAOS)

Eliza (nome del pacchetto: elizaOS) è un framework open-source scritto in TypeScript per costruire agenti AI autonomi. Nel gergo del settore, un agente non è un semplice bot di trading a regole: è un large language model che ragiona e pianifica, dotato di memoria persistente, di strumenti per agire (chiamate API, interazioni on-chain), di un proprio wallet e di un grado di autonomia sufficiente a firmare da solo le proprie transazioni. Il modello decide, l’agente esegue. È questa combinazione, LLM più wallet più autonomia, a rendere gli agenti interessanti e, come vedremo, pericolosi.

Sul piano del codice, Eliza è uno dei repository AI più seguiti al mondo. Su GitHub conta circa 19,3 mila stelle e 5,7 mila fork, è distribuito con licenza permissiva MIT e si descrive come «Your agentic operating system», il tuo sistema operativo agentico. In un’intervista a BlockchainGamer.biz (marzo 2026), Walters rivendicava «probably the most complete end-to-end framework», con oltre 250 plugin, il supporto al protocollo MCP e port in arrivo verso Rust e Python.

Il punto che quasi tutti confondono è questo: il framework e il token sono due cose diverse. Il framework è software libero, chiunque può scaricarlo, forkarlo e usarlo senza chiedere permesso a nessuno e senza toccare alcun token. ELIZAOS, invece, era un asset speculativo negoziato sugli exchange, nato dalla vicenda del fondo ai16z. La qualità del codice non ha mai coinciso con la performance del token, e il 2026 lo ha dimostrato nel modo più netto: il token è andato praticamente a zero mentre lo sviluppo del codice non si è fermato.

Dal fondo ai16z a elizaOS: la parabola in breve

La storia comincia nell’ottobre 2024. Walters lancia su Solana, tramite il launchpad daos.fun, un fondo chiamato ai16z, con una raccolta iniziale modesta. Il vero innesco è social: il venture capitalist Marc Andreessen (il nome ai16z gioca sulla sua a16z) rilancia il progetto su X con un lapidario «GAUNTLET THROWN», e nel giro di poche ore la capitalizzazione schizza verso i 100 milioni di dollari, mandando in tilt il sito del launchpad, come ricostruito da The Block.

Il progetto ruotava attorno a due personas AI (una versione prudente ispirata ad Andreessen e una aggressiva, Degen Spartan AI) e a un concetto chiamato «Marketplace of Trust». All’inizio di gennaio 2025 il token tocca il picco, con una capitalizzazione stimata intorno ai 2,4 miliardi di dollari. Il 28 gennaio 2025 arriva il rebrand in elizaOS, dopo che la stessa a16z aveva chiesto di prendere le distanze dal nome, come riportato da Decrypt. A novembre 2025 parte la migrazione dal vecchio token ai16z al nuovo ELIZAOS.

Nell’aprile 2026 lo studio Burwick Law deposita una class action alla corte federale di New York (SDNY) per conto di un investitore, come risulta dal fascicolo su Justia: le accuse, non provate, riguardano l’uso non autorizzato del marchio a16z e una autonomia dell’agente presentata come reale ma di fatto guidata da esseri umani. Il 4 agosto 2026 Walters chiude la vicenda con un accordo, dichiara morto il token e avvia lo scioglimento della fondazione. A The Defiant spiega la sua scelta: «I am starting over, since I own the IP, and I am never letting a token come close to Eliza again», ricomincio da capo, possiedo la proprietà intellettuale e non lascerò mai più che un token si avvicini a Eliza.

Come funziona un agente Eliza: l’architettura in pratica

Sotto il cofano, un agente Eliza è orchestrato da un runtime (l’AgentRuntime) che tiene insieme quattro cose: il modello linguistico, la memoria, i plugin e le connessioni verso il mondo esterno. La personalità dell’agente è definita in un character file, un documento che descrive chi è l’agente (bio, stile, tono), che cosa sa, quali modelli usa e quali plugin carica. Cambiando quel file si passa da un assistente di ricerca a un market maker automatico senza riscrivere il motore.

Il cuore programmabile del framework sono quattro primitivi, tutti registrati attraverso un’unica interfaccia Plugin, come documentato nella documentazione ufficiale. Capirli è il modo più rapido per farsi un’idea di che cosa un agente possa e non possa fare.

Attorno a questi primitivi ruotano due elementi decisivi. Il primo è la memoria: l’agente conserva conversazioni, fatti e rappresentazioni vettoriali (embeddings) e, quando deve agire, recupera il contesto rilevante con tecniche di retrieval (RAG). È ciò che gli permette di ricordarti e di comportarsi in modo coerente nel tempo. Il secondo è il modello di messaggistica a tre livelli, Worlds (il server o lo spazio di lavoro), Rooms (il canale o la conversazione) ed Entities (utenti e agenti), che consente a più agenti e più persone di coesistere nello stesso ambiente.

Sui modelli, Eliza è agnostico: può appoggiarsi ad API commerciali (OpenAI, Anthropic) oppure girare in locale con motori come Ollama, un dettaglio che diventa cruciale quando si parla di sicurezza e sovranità dei dati. Questa flessibilità è il motivo per cui il framework viene usato tanto per bot social e assistenti quanto per agenti finanziari on-chain.

Il wallet è il punto in cui tutto diventa serio

Fino a quando un agente si limita a scrivere testo, un suo errore produce, appunto, testo sbagliato. Nel momento in cui gli si collega un wallet, ogni errore muove denaro reale, e sulla blockchain le transazioni non si annullano. È qui che il discorso su Eliza smette di essere accademico. L’agente firma da solo le proprie transazioni: questo confine, il punto in cui un modello probabilistico ottiene il potere di spostare fondi in modo irreversibile, è il vero nodo della fiducia.

Il parallelo più utile è la firma alla cieca sugli hardware wallet: quando un utente approva una transazione senza capire davvero che cosa sta autorizzando, si affida alla buona fede di ciò che gli viene mostrato. Un agente AI vive in una condizione strutturalmente simile, moltiplicata per la velocità e per l’autonomia. Ecco perché, con il token ormai fuori gioco, la domanda che conta per Eliza nel 2026 non è più quanto vale, ma quanto è sicuro affidargli un wallet.

Prompt injection: il modello non distingue istruzione da dato

Il difetto è strutturale e riguarda tutti gli LLM, non solo Eliza. Per un modello linguistico, le istruzioni del proprietario e i dati raccolti dal mondo (un tweet, un messaggio in chat, il contenuto di una pagina web che l’agente legge) arrivano sullo stesso canale: testo. Non esiste un confine forte e verificabile tra un ordine legittimo del proprietario e del testo ostile che qualcuno ha piazzato dove l’agente lo avrebbe letto. È la classe di vulnerabilità che l’OWASP cataloga come LLM01, prompt injection, ed è considerata la più pericolosa per gli agenti.

In pratica, chiunque possa inserire testo nel campo visivo dell’agente può tentare di dargli ordini. Se l’agente ha un wallet e i permessi per usarlo, un’iniezione riuscita non è un fastidio: è un bonifico non autorizzato. E poiché l’agente lavora in autonomia e ad alta velocità, spesso non c’è un essere umano nel momento decisivo a bloccare la mano.

Memory injection, l’attacco più insidioso

Nel 2026 il lavoro accademico più citato su questo fronte è lo studio «Real AI Agents with Fake Memories», firmato da un gruppo di ricercatori di Princeton (Atharv Singh Patlan, Peiyao Sheng, S. Ashwin Hebbar, Prateek Mittal e Pramod Viswanath). Gli autori costruiscono un benchmark, CrAIBench, con oltre 150 compiti realistici on-chain (trasferimenti, trading, bridge, operazioni cross-chain) e oltre 500 casi d’attacco, e scelgono proprio elizaOS come framework rappresentativo dell’intera categoria.

La conclusione è controintuitiva e pesante: i modelli sono più vulnerabili all’iniezione in memoria che al prompt injection classico. Se un attaccante riesce a corrompere ciò che l’agente ricorda, le difese pensate per filtrare i prompt in ingresso servono a poco, perché il contesto avvelenato è già dentro. È un problema profondo, perché la memoria persistente è esattamente ciò che rende un agente utile (ricorda te, i tuoi ordini, le tue preferenze), ma è anche una superficie d’attacco che vive nel tempo. Gli autori osservano che le difese basate sul fine-tuning riducono il tasso di successo degli attacchi più di quelle basate sui prompt, ma nessuna difesa si è dimostrata risolutiva. La copertura di Decrypt ha sintetizzato il punto notando che gli agenti non hanno un modo affidabile di verificare l’integrità delle voci salvate in memoria.

Il caso Grok/Bankr e perché riguarda anche Eliza

Che non sia teoria lo ha mostrato un incidente reale. Il 4 maggio 2026, secondo l’archivio incidenti dell’OECD.AI, un attaccante ha combinato due mosse: ha nascosto un’istruzione in codice Morse dentro una risposta su X e ha sfruttato permessi ottenuti in modo improprio, inducendo un agente collegato ai servizi Grok e Bankr a trasferire circa 150.000 euro (all’incirca 175.000 dollari, pari a 3 miliardi di token DRB) sulla rete Base. Nessun bug negli smart contract: l’exploit ha sfruttato il modo in cui l’AI interpretava l’input, non una falla dell’infrastruttura.

Attenzione: quello non era un agente Eliza. Ma appartiene esattamente alla stessa classe di attacchi (prompt injection più escalation di privilegi) cui è esposto qualunque framework che dia un wallet a un LLM, Eliza compreso, ed è bene ricordare che è proprio elizaOS il framework che i ricercatori di Princeton hanno scelto come rappresentativo. Il problema non è di un singolo progetto: è del paradigma.

Autonomia contro sicurezza, il dilemma irrisolto

Qui si arriva al compromesso che nessuno ha ancora sciolto. Ogni difesa seria (tetti di spesa, whitelist di destinatari, conferma umana prima di ogni operazione rilevante) toglie autonomia all’agente, e quindi gli toglie proprio ciò che lo rendeva attraente. Un agente che deve chiedere il permesso per ogni mossa è, in pratica, un’app con qualche fronzolo in più. Ma un agente davvero autonomo con accesso a un wallet è, per costruzione, a un prompt ostile di distanza dal disastro.

Vitalik Buterin ha proposto una linea dura. Sul suo blog (secure_llms, aprile 2026) riassume così l’approccio corretto: «All LLM inference local first. All files hosted locally. Sandbox everything», inferenza locale prima di tutto, file ospitati in locale, isolare ogni componente. In interventi ripresi da testate di settore ha aggiunto l’idea di limitare le transazioni autonome a un tetto giornaliero dell’ordine dei 100 dollari, con conferma umana oltre soglia, di fatto un meccanismo umano più LLM che funziona come una doppia firma.

Lo stesso Walters è stato sorprendentemente franco sul limite di fondo. Già a Token2049, in dichiarazioni riprese da Decrypt, aveva ammesso: «You probably do not want to give an AI agent a bunch of money and expect it to make you more», probabilmente non è saggio dare a un agente AI un mucchio di soldi aspettandosi che te ne faccia guadagnare altri. Detto dal creatore di uno dei framework più usati per gli agenti finanziari, è un avvertimento che pesa.

La risposta del settore: compute verificabile (e i suoi limiti)

Una parte del settore risponde con il compute verificabile. L’idea è dimostrare crittograficamente che un certo calcolo (una inferenza del modello) è stato eseguito correttamente e senza manomissioni. Sul fronte hardware si usano ambienti di esecuzione fidati (TEE, come Intel TDX e SGX) con attestazione remota; non a caso team infrastrutturali seri trattano elizaOS come un cittadino di prima classe: Automata Network mantiene un fork del registro dei plugin e un plugin di attestazione DCAP, e anche Nethermind (uno dei principali team di client Ethereum) mantiene un proprio fork del registro. Sul fronte software ci sono approcci come opML e zkML, e progetti come Ritual puntano a rendere l’inferenza AI verificabile e riservata direttamente on-chain.

C’è però un equivoco da evitare. Il compute verificabile prova l’integrità (il modello giusto ha girato, i dati non sono stati alterati) e talvolta la riservatezza, ma non prova che l’istruzione fosse legittima. Un agente perfettamente attestato può comunque essere ingannato da un prompt injection o da una memoria avvelenata: la prova crittografica certifica il come del calcolo, non la bontà della decisione. È una distinzione che nel marketing sparisce spesso, e che chi valuta un agente per gestire fondi deve tenere ben presente.

Chi mantiene Eliza ora che la fondazione chiude

La morte del token apre una domanda tipica dell’open-source: chi mantiene un framework MIT da quasi 20 mila stelle quando la sua fondazione si scioglie e non c’è più una tesoreria a pagare gli sviluppatori? Nel caso di Eliza si delineano tre modelli di stewardship, non mutuamente esclusivi.

Il primo è Walters stesso con il core team: possiede l’IP, ha dichiarato di ricominciare da capo e di non voler più legare un token a Eliza, e continua a costruire, con una visione che guarda sempre più ai giochi (il progetto Hyperscape, un’ambizione descritta come una sorta di AI RuneScape). Come ha detto a BlockchainGamer.biz, «playing games is the path to agents that do the real work», giocare è la strada verso agenti capaci di fare lavoro vero. Il secondo modello sono gli adottanti commerciali: chi costruisce prodotti sopra elizaOS, dai fork dei registri di Automata e Nethermind alle iniziative di automazione per le piccole e medie imprese, ha un interesse diretto a mantenere vivo il codice. Il terzo sono i volontari della community, i 5,7 mila fork e i contributori che, per un progetto MIT, restano la spina dorsale quotidiana.

Il rischio è evidente: senza una fondazione e senza fondi dedicati, chi finanzia la manutenzione della sicurezza, cioè proprio l’aspetto più critico visto sopra? È una domanda aperta, e vale per l’intera categoria degli agenti open-source, non solo per Eliza.

Eliza a confronto con gli altri framework

Eliza non è l’unico modo per costruire agenti. Vale la pena collocarlo nel panorama, perché le differenze di filosofia contano quanto quelle tecniche.

La lettura è semplice: Eliza è crypto-native e mette al centro la personalità dell’agente e un wallet nativo, mentre strumenti come LangChain e CrewAI sono general-purpose, molto usati in azienda, ma senza integrazione on-chain di serie. Virtuals e Olas restano invece dentro l’orbita cripto, con token ancora vivi e mercati attivi. Che due dei framework più diffusi (LangChain e CrewAI) non abbiano mai avuto un token e prosperino comunque è un dato che pesa sulla riflessione del prossimo paragrafo.

Il token è morto, ma il settore vive: la svolta senza token

Zoomando indietro, il settore degli agenti AI on-chain è tutt’altro che spento. La categoria AI Agents di CoinGecko vale, a inizio settembre 2026, oltre 3 miliardi di dollari (circa 2,8 miliardi di euro), con un volume giornaliero nell’ordine dei 650 milioni. In cima c’è Venice (VVV), in forte rialzo (intorno al +90% in 30 giorni) e attorno al miliardo di dollari di capitalizzazione, seguito da Virtuals (VIRTUAL, circa 426 milioni), ASI/Fetch (FET, circa 390 milioni) e Kite (KITE, circa 270 milioni). Sono cifre da prendere come istantanea, data la volatilità.

La lezione Eliza, però, è di quelle scomode per l’intero comparto: il token può azzerarsi mentre il software prospera. Riemerge così la domanda che accompagna tutta la cripto-AI, cioè se il token catturi davvero il valore che il software crea, un interrogativo che HOGE Wire ha affrontato a proposito dell’inferenza decentralizzata. La svolta senza token è già in corso: Walters ha scelto di non averne più, e i due framework generalisti più diffusi non ne hanno mai avuto.

Vale anche la pena ricordare che il crollo di ELIZAOS è stato in larga parte idiosincratico, legato alla causa e alla perdita di fiducia, non a un tracollo di mercato: si è consumato mentre il resto del comparto restava relativamente solido e mentre l’attenzione degli investitori era rivolta ad appuntamenti macro come le decisioni della Fed, che HOGE Wire ha seguito nel contesto di una settimana chiave per Bitcoin. Un token può morire da solo, senza bisogno di un mercato orso.

Cosa significa per un utente o uno sviluppatore italiano

Sul piano normativo, la buona notizia per chi guarda a Eliza è che il framework in sé, in quanto software open-source, non è un servizio finanziario regolato. In Italia la vigilanza sui servizi in cripto-attività fa capo a Consob (condotta di mercato e tutela degli investitori) e a Banca d’Italia (profili prudenziali e stablecoin), secondo il D.lgs. 129/2024, dentro la cornice europea di MiCA. Ma MiCA regola i prestatori di servizi (CASP) e gli emittenti, non un protocollo o una libreria di codice: era il token, semmai, la parte regolabile della vicenda, non il repository su GitHub. Il periodo transitorio di MiCA in Italia si è chiuso il 1 luglio 2026 con nove soggetti abilitati; chi vuole capire come si ottiene un’autorizzazione può leggere la nostra guida alla licenza CASP.

Attenzione a un caso specifico: se un agente non si limita a eseguire ordini ma di fatto dà consulenza o gestisce un portafoglio, si entra nel perimetro della MiFID II (strumenti finanziari), non più solo di MiCA; l’ESMA lo ha chiarito nel suo orientamento sull’uso dell’AI nei servizi di investimento, che ribadisce governance, trasparenza e supervisione umana. E poiché un agente non ha personalità giuridica né un codice fiscale, la responsabilità di ciò che fa ricade sul principale: la persona o l’azienda che lo ha messo in funzione.

Sul fisco, infine, il punto dolente. Dal 1 gennaio 2026 le plusvalenze in cripto-attività sono tassate con imposta sostitutiva al 33%, mentre l’aliquota del 26% resta solo per gli stablecoin in euro (gli EMT conformi a MiCA), come spiega Fisco Oggi. Per un agente autonomo questo ha un risvolto concreto: il soggetto d’imposta è il proprietario del wallet, ogni cessione è potenzialmente un evento tassabile, e un bot che opera 24 ore su 24 può generare migliaia di micro-eventi da rendicontare, con il rischio ulteriore che un’attività così sistematica venga riqualificata come reddito d’impresa. La comodità dell’automazione, sul piano fiscale, può trasformarsi in un incubo di rendicontazione.

Domande frequenti

Il token ELIZAOS è morto: il framework Eliza funziona ancora?

Sì. Il token e il framework sono due cose distinte. Il codice di Eliza (elizaOS) è rilasciato con licenza MIT su GitHub e continua a essere sviluppato attivamente anche dopo la dichiarazione di morte del token dell’agosto 2026. Il fondatore Shaw Walters ha detto che continuerà a costruirlo, questa volta senza alcun token collegato.

È sicuro dare a un agente Eliza il controllo di un wallet?

Comporta rischi reali. Gli agenti costruiti su LLM sono vulnerabili a prompt injection e, soprattutto, a memory injection, come mostra lo studio di Princeton su CrAIBench. La regola pratica è non affidare a un agente più di quanto si è disposti a perdere, usare un wallet dedicato con fondi limitati, impostare tetti di spesa e prevedere una conferma umana per le operazioni rilevanti.

Che differenza c’è tra ai16z ed elizaOS?

ai16z era il nome e il token originali del progetto, lanciato nell’ottobre 2024. A gennaio 2025 il progetto è stato rinominato elizaOS, anche su richiesta della società di venture capital a16z. Oggi elizaOS indica il framework open-source, mentre il token che ne era derivato è considerato defunto dall’agosto 2026.

Come vengono tassati in Italia i guadagni di un agente AI on-chain?

Le plusvalenze in cripto-attività sono tassate al 33% dal 1 gennaio 2026, mentre il 26% resta solo per gli stablecoin in euro conformi a MiCA. Il soggetto d’imposta è il proprietario del wallet, non l’agente, che non ha personalità giuridica. Il trading automatico ad alta frequenza può inoltre far scattare la riqualificazione dei proventi come reddito d’impresa.

Eliza è meglio di LangChain o Virtuals?

Dipende dall’obiettivo. Eliza è crypto-native, con wallet nativo e forte enfasi sulla personalità dell’agente e sul gaming. LangChain e CrewAI sono general-purpose e molto usati in azienda, ma senza integrazione on-chain di serie. Virtuals è invece un launchpad no-code per agenti tokenizzati. Non esiste un vincitore assoluto: cambia lo strumento a seconda del caso d’uso.

Marcus Okafor copre intelligenza artificiale, cripto e mercati per HOGE Wire.