Eliza framework 2026: plugin, interoperabilità e agenti on-chain

Nell’autunno del 2026 il token che dava il nome al progetto è poco più di una nota a piè di pagina. ELIZAOS capitalizza circa 1,2 milioni di dollari, poco più di un milione di euro, oltre il 98% sotto il massimo storico, e la fondazione che lo sosteneva è in liquidazione: lo confermano i dati di CoinGecko e il resoconto di CoinDesk. Eppure il framework open source che porta lo stesso nome continua a pubblicare codice ogni giorno. La storia interessante, ormai, non è il grafico dei prezzi: è l’infrastruttura.

Questa è una guida al framework Eliza (oggi elizaOS) così com’è alla fine del 2026: che cosa fa, come è costruito, perché l’ecosistema di plugin è diventato il suo vero fossato competitivo, come si innesta nello stack emergente degli agenti AI, dove sta il suo limite di sicurezza, chi mantiene il codice ora che i soldi non ci sono più e quali regole valgono per chi vuole costruirci in Italia. Il filo conduttore è semplice: il token è morto, ma il codice è diventato uno standard di fatto.

Che cos’è il framework Eliza (e cosa non è)

Eliza è un framework open source, scritto in TypeScript e distribuito con licenza MIT, per costruire, distribuire e orchestrare agenti AI autonomi: software dotato di un cervello (un large language model), di una memoria persistente, di un wallet e di una serie di strumenti, che pianifica e firma da sé le proprie transazioni. È qui la differenza rispetto a un normale bot di trading a regole: un agente non esegue solo istruzioni predefinite, ma interpreta un contesto e decide come agire.

Prima di tutto conviene separare tre cose che il dibattito pubblico continua a confondere. C’è il framework, cioè il codice, ed è vivo e attivo. C’è il token ELIZAOS, ed è morto. E c’è la Eliza Foundation, l’entità che gestiva tesoro e marketing, ed è in liquidazione. Scambiare il destino del token per quello del software è l’errore ricorrente di chi guarda solo alle quotazioni.

Sul piano concettuale il progetto si autodefinisce ormai un «sistema operativo agentico»: la descrizione del repository elizaOS/eliza su GitHub recita «Open source agentic operating system» e conta circa 19.500 stelle e 5.800 fork. La visione è formalizzata in un paper accademico, «Eliza: A Web3 friendly AI Agent Operating System», firmato da Shaw Walters e altri, in cui gli autori sottolineano un principio di design che spiega buona parte delle scelte tecniche: «ogni aspetto di Eliza è un normale programma TypeScript sotto il pieno controllo del suo utente». Nessuna scatola nera, nessuna magia: codice ispezionabile.

Dal fondo ai16z al codice: la parabola in breve

Per capire perché oggi il framework conta più del token serve un rapido riassunto di come si è arrivati fin qui. Nell’ottobre 2024 Walters lancia ai16z su Solana tramite il launchpad daos.fun, con una raccolta iniziale modesta. Il 27 ottobre il vero Marc Andreessen twitta «GAUNTLET THROWN» e la capitalizzazione schizza a circa 96 milioni di dollari in poche ore, al punto da mandare in tilt il sito di daos.fun, come raccontò The Block.

Da lì, la parabola classica: picco di capitalizzazione a circa 2,39 miliardi di dollari (intorno ai 2,1 miliardi di euro) il 2 gennaio 2025, dato riportato da CoinDesk, rebranding in ElizaOS dopo che la stessa a16z chiese di prendere le distanze dal nome, migrazione del token nel novembre 2025, poi la causa. Nell’aprile 2026 lo studio Burwick Law deposita a New York la class action Pikabea contro Walters, Eliza Labs e altri, accusando il progetto di aver gonfiato l’autonomia dell’agente e di aver usato indebitamente il marchio a16z (il fascicolo è consultabile su Justia; le accuse restano non provate). Il 4 agosto 2026 Walters chiude il cerchio: «Il token è morto. Completamente», e annuncia la liquidazione della fondazione dopo aver trasferito ai possessori il tesoro residuo per chiudere la vertenza.

Il senso della tabella qui sotto non è la cronaca giudiziaria, già raccontata altrove: è che il codice ha attraversato indenne tutte queste tappe.

L’anatomia di un agente: runtime, character file e memoria

Al centro di ogni agente c’è l’AgentRuntime, il motore che tiene insieme tutti i pezzi: riceve i messaggi, recupera il contesto, chiama il modello, decide quali azioni eseguire e scrive i risultati in memoria. Attorno al runtime ruotano quattro elementi che vale la pena conoscere anche se non si scrive una riga di codice.

Il primo è il character file, il documento (in pratica un file di configurazione) che definisce chi è l’agente: personalità, conoscenze di base, stile, obiettivi, quali modelli usare e quali plugin caricare. Cambiare agente significa, in larga misura, cambiare questo file. Il secondo è la memoria: gli agenti Eliza non ripartono da zero a ogni conversazione, ma conservano fatti ed esperienze in un archivio persistente, spesso con tecniche di retrieval-augmented generation (RAG) che recuperano le informazioni pertinenti al momento giusto.

Il terzo elemento è il modello di messaggistica, organizzato su tre livelli: i Worlds (un server o uno spazio di lavoro), le Rooms (un canale o una conversazione) e le Entities (gli utenti e gli agenti che vi partecipano). È una struttura pensata perché lo stesso agente possa operare su Discord, Telegram, X o un’app su misura senza riscrivere la logica di fondo. Il quarto elemento sono i primitivi che traducono tutto questo in comportamento concreto, ed è qui che il framework mostra la sua eleganza.

I quattro primitivi: Actions, Providers, Evaluators, Services

Tutto ciò che un agente Eliza sa fare passa da quattro primitivi. Le Actions sono le cose che l’agente può compiere: inviare un token, pubblicare un messaggio, chiamare un contratto. I Providers sono le fonti di contesto che legge prima di decidere: il saldo del wallet, l’orario, i prezzi, la cronologia recente. Gli Evaluators intervengono dopo l’interazione, per estrarre fatti, aggiornare la memoria o valutare se un obiettivo è stato raggiunto. I Services, infine, sono le integrazioni persistenti, come la connessione a una piattaforma di chat, a un database o a un provider di modelli.

La tabella riassume i quattro mattoni. La loro forza è che si registrano tutti attraverso una sola interfaccia comune: aggiungere una capacità significa aggiungere un plugin, non riscrivere il runtime.

I plugin: il vero fossato del progetto

Se il runtime è il motore, i plugin sono ciò che rende Eliza interessante nel 2026. Nel framework tutto passa da una singola interfaccia Plugin: adapter di database, actions, evaluators, providers, modelli, rotte HTTP, gestori di eventi e services si dichiarano nello stesso modo. Un plugin può quindi aggiungere una catena, una piattaforma social, un provider di intelligenza artificiale o un intero flusso di lavoro finanziario, e disattivarlo è altrettanto semplice.

Il registro ufficiale, documentato su docs.elizaos.ai, organizza i plugin per categoria: supporto multi-chain EVM su oltre 30 reti con trasferimenti, swap, bridging e governance; integrazione ad alte prestazioni con Solana; connettori per Discord, Telegram, X e Farcaster; provider di modelli come OpenAI, Anthropic e OpenRouter. Alle decine di plugin di prima parte si somma un ecosistema più ampio: in una intervista a BlockchainGamer.biz Walters ha rivendicato «oltre 250 plugin» e il supporto a MCP, definendo Eliza «probabilmente il framework end-to-end più completo».

Il segnale più forte, però, non sono i numeri: è chi partecipa. Squadre di infrastruttura serie mantengono i propri fork del registro. Nethermind, uno dei principali team di client Ethereum, gestisce un registro di plugin dedicato; Automata Network, protocollo di attestazione basato su ambienti di esecuzione fidati (TEE), ne mantiene un altro e ha sviluppato un plugin che aggiunge la remote attestation Intel DCAP. È la dinamica che ha reso grande npm o l’App Store: il valore non è più solo nel nucleo, ma nell’ecosistema che gli cresce attorno. Ed è un ecosistema che un token morto non può portarsi via.

MCP, A2A, x402 ed ERC-8004: Eliza nello stack degli agenti

Un agente utile raramente vive da solo. Deve usare strumenti, parlare con altri agenti, pagare per servizi e, sempre più spesso, dimostrare chi è. Nel 2026 questi bisogni si stanno cristallizzando in quattro standard, e la scelta più intelligente di Eliza è stata parlarli invece di inventarne di propri.

Il primo è MCP (Model Context Protocol), il modo ormai standard per collegare un modello a strumenti e fonti di dati esterne; Walters lo cita esplicitamente tra le capacità del framework. Il secondo è A2A, lo standard promosso da Google per la comunicazione agente-agente. Il terzo riguarda i pagamenti: x402, l’iniziativa di Coinbase poi confluita in una fondazione della Linux Foundation, resuscita il codice HTTP 402 «Payment Required» per far pagare gli agenti in stablecoin, mentre AP2 di Google ne copre l’autorizzazione. Chi vuole capire come si incastrano questi pezzi trova un quadro dettagliato nella nostra guida su come pagano gli agenti AI.

Il quarto standard è il più giovane: ERC-8004, «Trustless Agents», una proposta ancora allo stato di Draft che definisce un livello di identità e reputazione per gli agenti, in modo che due software possano scoprirsi e fidarsi l’uno dell’altro senza un rapporto pregresso. Messi insieme, questi standard trasformano Eliza da libreria isolata a nodo di un’economia di agenti interoperabile. La tabella riassume i livelli.

Che cosa si costruisce davvero con Eliza

Al di là della teoria, che cosa costruisce davvero la gente con Eliza? I casi d’uso si raccolgono in poche famiglie. La prima è finanziaria: agenti di trading e di DeFAI (la DeFi gestita dall’AI) che monitorano i prezzi, ribilanciano un portafoglio, proteggono una posizione dalla liquidazione o cercano rendimento tra i protocolli. È il territorio più ambizioso e anche il più rischioso, perché mette denaro reale nelle mani di un software.

La seconda famiglia è sociale: agenti di community e di supporto che vivono su Discord, Telegram o X, rispondono alle domande, moderano e pubblicano contenuti. La terza è l’automazione on-chain vera e propria: operazioni ricorrenti sul tesoro di un progetto, bot che raccolgono airdrop o eseguono claim, fino agli NPC dei videogiochi. Il filo comune è che Eliza fornisce lo scheletro (memoria, wallet, strumenti, plugin), mentre a te restano l’obiettivo da dare all’agente e i paletti entro cui muoverlo.

Non più una libreria: il monorepo diventato piattaforma

Chi immagina Eliza come una semplice libreria per costruire chatbot è fermo al 2024. Il monorepo su GitHub raccoglie oggi una serie di pacchetti che descrivono un’ambizione ben più larga: oltre al core e all’agent, ci sono pacchetti per il cloud, per l’autenticazione (auth), per l’addestramento (training), per i benchmark, per l’interfaccia (app e ui) e persino un pacchetto os, come mostra l’albero dei pacchetti. Non è più un attrezzo: è una piattaforma.

La direzione è coerente con il nome che il progetto si è dato, «sistema operativo agentico». Accanto al nucleo TypeScript sono comparsi componenti in Rust, per esempio nel modulo di controllo del computer (computer-use), e Walters ha dichiarato di voler portare Eliza anche in Rust e Python per allargarne la platea di sviluppatori: sono suoi piani dichiarati, non un traguardo già consolidato, e vanno letti come tali. Il framework punta inoltre a un funzionamento «local-first», con il supporto a modelli eseguiti in locale, così da ridurre la dipendenza dalle API a pagamento.

Questa ambizione ha un costo pratico ovvio: gli agenti autonomi consumano calcolo. Far girare inferenza a getto continuo su GPU cloud tradizionali è caro, ed è uno dei motivi per cui l’ecosistema guarda alle reti di calcolo decentralizzate; per chi vuole provare, abbiamo spiegato passo passo come noleggiare una GPU su Akash. La combinazione tra framework aperto e calcolo a basso costo è ciò che rende plausibile, per un piccolo team, un progetto che un tempo avrebbe richiesto un’infrastruttura da grande azienda.

Il tallone d’Achille: prompt injection e memory injection

Qui arriva la parte scomoda. Dare un wallet a un agente significa spostare un confine di fiducia: non stai più autorizzando tu ogni transazione, la autorizza un modello linguistico che, per definizione, fatica a distinguere le istruzioni dai dati. È lo stesso problema del blind signing degli hardware wallet, ma amplificato: l’agente firma ciò che non sempre riesce a interpretare.

Il primo vettore è il prompt injection, classificato come LLM01 dalla OWASP: un’istruzione nascosta in un input (un messaggio, una pagina web, un commento) viene eseguita come se fosse un comando legittimo. Il secondo è più insidioso. Un gruppo di ricercatori di Princeton, nel paper «Real AI Agents with Fake Memories», ha introdotto il benchmark CrAIBench usando proprio ElizaOS come framework rappresentativo, con oltre 150 compiti on-chain e più di 500 casi di attacco. La conclusione è netta: i modelli sono molto più vulnerabili al memory injection (fatti falsi iniettati nella memoria persistente) che al prompt injection, e una volta corrotta la memoria le difese classiche servono a poco.

Non è teoria. Il 4 maggio 2026 un agente costruito su Grok e Bankr è stato drenato per un importo stimato tra 150.000 e 200.000 dollari su Base, tramite un’istruzione nascosta in codice Morse e un NFT ricevuto in dono che sbloccava diritti di transfer, come documenta l’incidente registrato da OECD.AI. Non era un agente Eliza, ma la classe di attacco è identica. Vitalik Buterin, in un saggio dell’aprile 2026, riassume la ricetta difensiva minima («inferenza LLM tutta in locale, tutti i file ospitati in locale, sandbox su tutto») e cita un dato che dovrebbe far riflettere chiunque installi plugin a cuor leggero: «circa il 15% delle skill che abbiamo visto conteneva istruzioni malevole». Attenzione a un equivoco diffuso: il calcolo verificabile, di cui abbiamo scritto a proposito di opML e il limite di velocità, dimostra che un calcolo è stato eseguito fedelmente, ma non rende l’agente immune all’iniezione: sono due problemi diversi.

In pratica, chi mette in produzione un agente con un wallet adotta alcune difese di buon senso: un tetto di spesa per periodo, una lista di indirizzi e contratti consentiti, la conferma umana obbligatoria sopra una certa soglia, un hot wallet separato con fondi minimi e un monitoraggio continuo delle transazioni. Nessuna di queste misure elimina il rischio, ma insieme riducono la superficie d’attacco e trasformano un potenziale disastro in una perdita contenuta. La regola d’oro resta una: automatizzare solo ciò che si è disposti a perdere.

Chi mantiene il codice quando muore la fondazione

Un framework open source con una fondazione ricca alle spalle è una cosa; lo stesso framework quando la fondazione si dissolve e il token vale zero è un’altra. La domanda, per chiunque valuti di costruirci sopra, è tutta qui: chi paga gli audit, chi rilascia le patch di sicurezza, chi gestisce il bug bounty quando il tesoro non esiste più?

Le risposte plausibili sono tre, complementari. La prima è Walters stesso, che possiede la proprietà intellettuale e ha promesso di continuare: «Ricomincio da capo, dato che possiedo l’IP, e non lascerò mai più che un token si avvicini a Eliza», ha dichiarato a CoinDesk. La seconda sono gli adottanti commerciali con interessi concreti: i già citati Nethermind e Automata, ma anche realtà che costruiscono prodotti chiavi in mano sopra elizaOS. La terza è la comunità: con licenza MIT e circa 19.500 stelle, chiunque può fare un fork e portare avanti il codice.

È un modello di manutenzione fragile e potente al tempo stesso. Fragile, perché nessuno è obbligato a nulla; potente, perché non dipende più da un tesoro che può evaporare in una class action. Il vero indicatore da tenere d’occhio non è il prezzo del token, ma la salute del repository: ritmo dei commit, pull request aperte e chiuse, reattività sulle vulnerabilità. Finché quel battito resta vivo, il framework è vivo.

Il banco di prova: il gaming e gli agenti che giocano

C’è un banco di prova che a Walters sta particolarmente a cuore: i videogiochi. La tesi, ripetuta più volte, è che «giocare è la strada verso agenti capaci di fare il lavoro vero». Un mondo di gioco è un ambiente ricco, dai costi contenuti e senza conseguenze reali, dove un agente può imparare a pianificare, esplorare e collaborare su orizzonti lunghi.

Il progetto concreto è Hyperia (in codice Hyperscape), descritto come un MMORPG «nativo per l’AI» in cui agenti autonomi giocano accanto agli umani, costruito su un motore 3D e integrato con elizaOS. È bene essere precisi: il progetto è dichiaratamente ancora «in sviluppo», non lanciato. Walters ne ha parlato in termini quasi provocatori a BlockchainGamer.biz, sostenendo di poter realizzare in quattro mesi, con una frazione del budget, ciò che a uno studio tradizionale costerebbe milioni: è una tesi, non un consuntivo. Al di là dell’iperbole, la logica è solida: gli stessi agenti che imparano a gestire risorse in un gioco sono, in prospettiva, quelli che gestiranno risorse nella DeFi.

Eliza contro il resto del campo

Eliza non è sola, e collocarla nel panorama aiuta a capirne il ruolo. Virtuals Protocol è un launchpad no-code per agenti su Base e Solana, con un token (VIRTUAL) ancora vivo. Olas (Autonolas) è più una rete di agenti coordinati, con il suo Mech Marketplace e una forte presenza sui mercati predittivi. LangChain e CrewAI sono framework generalisti, potenti ma non nativamente crypto. Eliza occupa una posizione precisa: framework crypto-nativo e completo, che però oggi sei tu a dover assemblare, senza un token che ti venda una scorciatoia.

Sul piano di mercato, il settore resta vivace nonostante la debacle di ELIZAOS. La categoria «AI Agents» di CoinGecko capitalizza circa 4 miliardi di dollari (intorno ai 3,5 miliardi di euro), trainata da Venice (VVV), Virtuals (VIRTUAL), la Artificial Superintelligence Alliance (FET), Kite (KITE) e OriginTrail (TRAC). Il contrasto con il milione scarso di ELIZAOS è la lezione più chiara di tutta la vicenda: la qualità di un framework e la performance di un token sono due cose diverse. E poiché questi token si muovono spesso come asset ad alto beta, il loro andamento va letto anche alla luce del quadro macro, come abbiamo analizzato a proposito della correlazione tra azioni e crypto.

Consob, MiCA e fisco: cosa cambia per chi costruisce in Italia

Per chi costruisce in Italia, la buona notizia è che il framework in sé non è un servizio finanziario regolamentato: è software. La parte delicata era il token, non il codice. Ma appena un agente inizia a operare con denaro reale, entrano in gioco regole precise.

Il primo principio è che un agente non ha personalità giuridica: non è un soggetto di diritto, non ha un codice fiscale, non risponde di nulla. La responsabilità ricade sull’essere umano o sulla società che lo mette in funzione (il principal). Il secondo principio riguarda l’attività svolta: se l’agente si limita a operare in autonomia su asset propri siamo nel perimetro delle cripto-attività, ma se offre consulenza sugli investimenti o gestisce portafogli di terzi allora si applica la MiFID II, di competenza della Consob, non la MiCA. In Italia il quadro è definito dal D.lgs. 129/2024, che assegna la vigilanza a Consob (condotta di mercato) e Banca d’Italia (profili prudenziali e stablecoin); il periodo transitorio MiCA si è chiuso il 1 luglio 2026 con nove soggetti abilitati, come comunicato dalla stessa Consob.

C’è poi il fisco, dove si annida un dettaglio pratico spesso ignorato. Dal 1 gennaio 2026 le plusvalenze in cripto-attività sono tassate al 33%, mentre le stablecoin in euro conformi alla MiCA (gli e-money token denominati in euro) mantengono l’aliquota del 26%, come ricostruisce FiscoOggi. La conseguenza per un agente è concreta: ogni pagamento in stablecoin in dollari può generare una cessione fiscalmente rilevante sul cambio, moltiplicata per migliaia di micro-transazioni, mentre una stablecoin in euro riduce l’attrito. E il dibattito su quell’aliquota è tutt’altro che chiuso: ne abbiamo scritto a proposito della richiesta dell’Intergruppo di tornare al 26% dal 2027. Occhio infine alla frequenza: un’operatività automatica 24 ore su 24 rischia la riqualificazione in reddito d’impresa.

Conviene costruirci nel 2026? Il verdetto

Arriviamo al verdetto. I punti di forza di Eliza nel 2026 sono difficili da negare: è, per ammissione del suo autore, uno dei framework end-to-end più completi; ha un ecosistema di plugin enorme e mantenuto anche da team esterni; è distribuito con licenza MIT, quindi senza il rischio di dipendere da un token; e parla gli standard emergenti invece di combatterli. Per un builder crypto-nativo è un punto di partenza credibile, forse il più credibile in circolazione.

I limiti, però, sono altrettanto reali e vanno messi in conto prima di scrivere codice. Non c’è più un ente finanziato che garantisca audit e patch: la sicurezza è responsabilità tua. Il tetto di sicurezza degli LLM (il memory injection su tutti) non è risolto, e nessun calcolo verificabile lo risolve. E l’affidabilità degli agenti davvero autonomi resta bassa: lo ammette lo stesso Walters, che a Decrypt ha detto senza giri di parole «probabilmente non vuoi dare a un agente AI un mucchio di soldi aspettandoti che te ne faccia guadagnare altri».

Il paradosso finale è che la morte del token è stata, con ogni probabilità, la cosa migliore che potesse capitare al codice: senza la pressione speculativa resta un progetto di ingegneria, giudicabile per ciò che fa. «Eliza è morta. Lunga vita a Eliza», ha scritto Walters. Per una volta lo slogan coincide con la realtà tecnica.

Domande frequenti

Il framework Eliza è morto insieme al token ELIZAOS?

No. Sono tre cose distinte: il token ELIZAOS è morto e la fondazione è in liquidazione, ma il framework open source è vivo, pubblicato con licenza MIT e ancora aggiornato su GitHub. Confondere il destino del token con quello del codice è l’errore più comune sul progetto.

In che linguaggio è scritto Eliza e serve un token per usarlo?

Il nucleo è scritto in TypeScript ed è distribuito con licenza MIT, quindi si può usare, modificare e forkare liberamente senza acquistare alcun token. Il fondatore ha dichiarato di voler portare il framework anche in Rust e Python, ma sono piani annunciati, non traguardi già consolidati.

Quanto è sicuro dare un wallet a un agente Eliza?

È il punto più delicato. Gli agenti sono esposti al prompt injection e, soprattutto, al memory injection, come ha mostrato il benchmark CrAIBench di Princeton usando proprio ElizaOS. Le mitigazioni (permessi minimi, conferma umana, esecuzione in locale, sandbox) riducono il rischio ma non lo azzerano: non affidare a un agente più di quanto tu sia disposto a perdere.

Che differenza c’è tra Eliza, Virtuals e Olas?

Eliza è un framework con cui costruisci tu l’agente da zero. Virtuals Protocol è un launchpad no-code per creare e monetizzare agenti, con un token attivo. Olas (Autonolas) è una rete di agenti coordinati, molto usata sui mercati predittivi. Rispondono a bisogni diversi: controllo totale contro rapidità di lancio.

Come vengono tassati in Italia i guadagni di un agente crypto?

I guadagni sono imputati alla persona o alla società proprietaria del wallet, non all’agente, che non ha personalità giuridica. Dal 1 gennaio 2026 le plusvalenze in cripto sono tassate al 33%, con l’eccezione delle stablecoin in euro conformi alla MiCA che restano al 26%. Ogni cessione è potenzialmente imponibile e un’operatività ad alta frequenza può essere riqualificata come reddito d’impresa.

Di Marcus Okafor, redattore senior di HOGE Wire, specializzato in AI e cripto-attività.