{"id":687,"date":"2026-09-30T22:39:30","date_gmt":"2026-09-30T22:39:30","guid":{"rendered":"https:\/\/hoge.gg\/it\/eliza-framework-2026-plugin-interoperabilita-agenti-onchain\/"},"modified":"2026-09-30T22:39:30","modified_gmt":"2026-09-30T22:39:30","slug":"eliza-framework-2026-plugin-interoperabilita-agenti-onchain","status":"publish","type":"post","link":"https:\/\/hoge.gg\/it\/eliza-framework-2026-plugin-interoperabilita-agenti-onchain\/","title":{"rendered":"Eliza framework 2026: plugin, interoperabilit\u00e0 e agenti on-chain"},"content":{"rendered":"

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

Questa \u00e8 una guida al framework Eliza (oggi elizaOS) cos\u00ec com’\u00e8 alla fine del 2026: che cosa fa, come \u00e8 costruito, perch\u00e9 l’ecosistema di plugin \u00e8 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\u00f9 e quali regole valgono per chi vuole costruirci in Italia. Il filo conduttore \u00e8 semplice: il token \u00e8 morto, ma il codice \u00e8 diventato uno standard di fatto.<\/p>

Che cos’\u00e8 il framework Eliza (e cosa non \u00e8)<\/h2>

Eliza \u00e8 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\u00e9 le proprie transazioni. \u00c8 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.<\/p>

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

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

Dal fondo ai16z al codice: la parabola in breve<\/h2>

Per capire perch\u00e9 oggi il framework conta pi\u00f9 del token serve un rapido riassunto di come si \u00e8 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 \u00abGAUNTLET THROWN\u00bb 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\u00f2 The Block<\/a>.<\/p>

Da l\u00ec, 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<\/a>, 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 \u00e8 consultabile su Justia<\/a>; le accuse restano non provate). Il 4 agosto 2026 Walters chiude il cerchio: \u00abIl token \u00e8 morto. Completamente\u00bb, e annuncia la liquidazione della fondazione dopo aver trasferito ai possessori il tesoro residuo per chiudere la vertenza.<\/p>

Il senso della tabella qui sotto non \u00e8 la cronaca giudiziaria, gi\u00e0 raccontata altrove: \u00e8 che il codice ha attraversato indenne tutte queste tappe.<\/p>

Data<\/th>Evento<\/th><\/tr><\/thead>
Ott 2024<\/td>Lancio di ai16z su Solana via daos.fun; raccolta iniziale modesta<\/td><\/tr>
27 ott 2024<\/td>Marc Andreessen twitta \u00abGAUNTLET THROWN\u00bb; la capitalizzazione tocca ~96 milioni di dollari in poche ore<\/td><\/tr>
2 gen 2025<\/td>Picco storico: capitalizzazione ~2,39 miliardi di dollari<\/td><\/tr>
28 gen 2025<\/td>Rebranding in ElizaOS, dopo la richiesta di a16z di prendere le distanze<\/td><\/tr>
Nov 2025<\/td>Migrazione del token da AI16Z a ELIZAOS<\/td><\/tr>
Apr 2026<\/td>Class action Pikabea contro Walters ed Eliza Labs (SDNY, New York)<\/td><\/tr>
4 ago 2026<\/td>Walters: \u00abIl token \u00e8 morto. Completamente\u00bb. La fondazione avvia la liquidazione<\/td><\/tr>
Set 2026<\/td>Il framework resta attivo: ~19.500 stelle su GitHub, token a ~1,2 milioni di dollari<\/td><\/tr><\/tbody><\/table><\/figure>

L’anatomia di un agente: runtime, character file e memoria<\/h2>

Al centro di ogni agente c’\u00e8 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.<\/p>

Il primo \u00e8 il character file, il documento (in pratica un file di configurazione) che definisce chi \u00e8 l’agente: personalit\u00e0, conoscenze di base, stile, obiettivi, quali modelli usare e quali plugin caricare. Cambiare agente significa, in larga misura, cambiare questo file. Il secondo \u00e8 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.<\/p>

Il terzo elemento \u00e8 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). \u00c8 una struttura pensata perch\u00e9 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 \u00e8 qui che il framework mostra la sua eleganza.<\/p>

I quattro primitivi: Actions, Providers, Evaluators, Services<\/h2>

Tutto ci\u00f2 che un agente Eliza sa fare passa da quattro primitivi. Le Actions sono le cose che l’agente pu\u00f2 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 \u00e8 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.<\/p>

La tabella riassume i quattro mattoni. La loro forza \u00e8 che si registrano tutti attraverso una sola interfaccia comune: aggiungere una capacit\u00e0 significa aggiungere un plugin, non riscrivere il runtime.<\/p>

Primitivo<\/th>Ruolo<\/th>Esempio<\/th><\/tr><\/thead>
Actions<\/td>Ci\u00f2 che l’agente pu\u00f2 fare<\/td>Inviare un token, pubblicare un post, chiamare un contratto<\/td><\/tr>
Providers<\/td>Il contesto che legge prima di decidere<\/td>Saldo del wallet, orario, prezzi, cronologia<\/td><\/tr>
Evaluators<\/td>L’elaborazione dopo l’interazione<\/td>Estrarre fatti, aggiornare la memoria, valutare obiettivi<\/td><\/tr>
Services<\/td>Le integrazioni persistenti<\/td>Connessioni a Discord, database, provider di modelli<\/td><\/tr><\/tbody><\/table><\/figure>

I plugin: il vero fossato del progetto<\/h2>

Se il runtime \u00e8 il motore, i plugin sono ci\u00f2 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\u00f2 quindi aggiungere una catena, una piattaforma social, un provider di intelligenza artificiale o un intero flusso di lavoro finanziario, e disattivarlo \u00e8 altrettanto semplice.<\/p>

Il registro ufficiale, documentato su docs.elizaos.ai<\/a>, 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\u00f9 ampio: in una intervista a BlockchainGamer.biz<\/a> Walters ha rivendicato \u00aboltre 250 plugin\u00bb e il supporto a MCP, definendo Eliza \u00abprobabilmente il framework end-to-end pi\u00f9 completo\u00bb.<\/p>

Il segnale pi\u00f9 forte, per\u00f2, non sono i numeri: \u00e8 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<\/a> dedicato; Automata Network, protocollo di attestazione basato su ambienti di esecuzione fidati (TEE), ne mantiene un altro<\/a> e ha sviluppato un plugin che aggiunge la remote attestation Intel DCAP. \u00c8 la dinamica che ha reso grande npm o l’App Store: il valore non \u00e8 pi\u00f9 solo nel nucleo, ma nell’ecosistema che gli cresce attorno. Ed \u00e8 un ecosistema che un token morto non pu\u00f2 portarsi via.<\/p>

MCP, A2A, x402 ed ERC-8004: Eliza nello stack degli agenti<\/h2>

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

Il primo \u00e8 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\u00e0 del framework. Il secondo \u00e8 A2A, lo standard promosso da Google per la comunicazione agente-agente. Il terzo riguarda i pagamenti: x402<\/a>, l’iniziativa di Coinbase poi confluita in una fondazione della Linux Foundation, resuscita il codice HTTP 402 \u00abPayment Required\u00bb 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<\/a>.<\/p>

Il quarto standard \u00e8 il pi\u00f9 giovane: ERC-8004<\/a>, \u00abTrustless Agents\u00bb, una proposta ancora allo stato di Draft che definisce un livello di identit\u00e0 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.<\/p>

Livello<\/th>Standard<\/th>A cosa serve<\/th><\/tr><\/thead>
Strumenti<\/td>MCP (Model Context Protocol)<\/td>Collegare l’agente a strumenti e dati esterni<\/td><\/tr>
Agente-agente<\/td>A2A (Google)<\/td>Far comunicare gli agenti tra loro<\/td><\/tr>
Pagamenti<\/td>x402 (Coinbase), AP2 (Google)<\/td>Far pagare gli agenti in stablecoin<\/td><\/tr>
Identit\u00e0 e reputazione<\/td>ERC-8004<\/td>Dare a un agente un’identit\u00e0 verificabile e uno storico<\/td><\/tr><\/tbody><\/table><\/figure>

Che cosa si costruisce davvero con Eliza<\/h2>

Al di l\u00e0 della teoria, che cosa costruisce davvero la gente con Eliza? I casi d’uso si raccolgono in poche famiglie. La prima \u00e8 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. \u00c8 il territorio pi\u00f9 ambizioso e anche il pi\u00f9 rischioso, perch\u00e9 mette denaro reale nelle mani di un software.<\/p>

La seconda famiglia \u00e8 sociale: agenti di community e di supporto che vivono su Discord, Telegram o X, rispondono alle domande, moderano e pubblicano contenuti. La terza \u00e8 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 \u00e8 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.<\/p>

Non pi\u00f9 una libreria: il monorepo diventato piattaforma<\/h2>

Chi immagina Eliza come una semplice libreria per costruire chatbot \u00e8 fermo al 2024. Il monorepo su GitHub raccoglie oggi una serie di pacchetti che descrivono un’ambizione ben pi\u00f9 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<\/a>. Non \u00e8 pi\u00f9 un attrezzo: \u00e8 una piattaforma.<\/p>

La direzione \u00e8 coerente con il nome che il progetto si \u00e8 dato, \u00absistema operativo agentico\u00bb. 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\u00e0 consolidato, e vanno letti come tali. Il framework punta inoltre a un funzionamento \u00ablocal-first\u00bb, con il supporto a modelli eseguiti in locale, cos\u00ec da ridurre la dipendenza dalle API a pagamento.<\/p>

Questa ambizione ha un costo pratico ovvio: gli agenti autonomi consumano calcolo. Far girare inferenza a getto continuo su GPU cloud tradizionali \u00e8 caro, ed \u00e8 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<\/a>. La combinazione tra framework aperto e calcolo a basso costo \u00e8 ci\u00f2 che rende plausibile, per un piccolo team, un progetto che un tempo avrebbe richiesto un’infrastruttura da grande azienda.<\/p>

Il tallone d’Achille: prompt injection e memory injection<\/h2>

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

Il primo vettore \u00e8 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 \u00e8 pi\u00f9 insidioso. Un gruppo di ricercatori di Princeton, nel paper \u00abReal AI Agents with Fake Memories\u00bb<\/a>, ha introdotto il benchmark CrAIBench usando proprio ElizaOS come framework rappresentativo, con oltre 150 compiti on-chain e pi\u00f9 di 500 casi di attacco. La conclusione \u00e8 netta: i modelli sono molto pi\u00f9 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.<\/p>

Non \u00e8 teoria. Il 4 maggio 2026 un agente costruito su Grok e Bankr \u00e8 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<\/a>. Non era un agente Eliza, ma la classe di attacco \u00e8 identica. Vitalik Buterin, in un saggio dell’aprile 2026<\/a>, riassume la ricetta difensiva minima (\u00abinferenza LLM tutta in locale, tutti i file ospitati in locale, sandbox su tutto\u00bb) e cita un dato che dovrebbe far riflettere chiunque installi plugin a cuor leggero: \u00abcirca il 15% delle skill che abbiamo visto conteneva istruzioni malevole\u00bb. Attenzione a un equivoco diffuso: il calcolo verificabile, di cui abbiamo scritto a proposito di opML e il limite di velocit\u00e0<\/a>, dimostra che un calcolo \u00e8 stato eseguito fedelmente, ma non rende l’agente immune all’iniezione: sono due problemi diversi.<\/p>

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\u00f2 che si \u00e8 disposti a perdere.<\/p>

Vettore<\/th>Come funziona<\/th>Difesa parziale<\/th><\/tr><\/thead>
Prompt injection<\/td>Istruzioni nascoste nell’input eseguite come comandi<\/td>Sandbox, conferma umana, filtri<\/td><\/tr>
Memory injection<\/td>Fatti falsi iniettati nella memoria persistente<\/td>Verifica dell’integrit\u00e0, memoria firmata<\/td><\/tr>
Escalation di permessi<\/td>Un dono o un NFT sblocca diritti di transfer e swap<\/td>Permessi minimi, isolamento<\/td><\/tr>
Blind signing<\/td>L’agente firma ci\u00f2 che non riesce a interpretare<\/td>Wallet che decodificano l’intento<\/td><\/tr><\/tbody><\/table><\/figure>

Chi mantiene il codice quando muore la fondazione<\/h2>

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

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

\u00c8 un modello di manutenzione fragile e potente al tempo stesso. Fragile, perch\u00e9 nessuno \u00e8 obbligato a nulla; potente, perch\u00e9 non dipende pi\u00f9 da un tesoro che pu\u00f2 evaporare in una class action. Il vero indicatore da tenere d’occhio non \u00e8 il prezzo del token, ma la salute del repository<\/a>: ritmo dei commit, pull request aperte e chiuse, reattivit\u00e0 sulle vulnerabilit\u00e0. Finch\u00e9 quel battito resta vivo, il framework \u00e8 vivo.<\/p>

Il banco di prova: il gaming e gli agenti che giocano<\/h2>

C’\u00e8 un banco di prova che a Walters sta particolarmente a cuore: i videogiochi. La tesi, ripetuta pi\u00f9 volte, \u00e8 che \u00abgiocare \u00e8 la strada verso agenti capaci di fare il lavoro vero\u00bb. Un mondo di gioco \u00e8 un ambiente ricco, dai costi contenuti e senza conseguenze reali, dove un agente pu\u00f2 imparare a pianificare, esplorare e collaborare su orizzonti lunghi.<\/p>

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

Eliza contro il resto del campo<\/h2>

Eliza non \u00e8 sola, e collocarla nel panorama aiuta a capirne il ruolo. Virtuals Protocol \u00e8 un launchpad no-code per agenti su Base e Solana, con un token (VIRTUAL) ancora vivo. Olas (Autonolas) \u00e8 pi\u00f9 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\u00f2 oggi sei tu a dover assemblare, senza un token che ti venda una scorciatoia.<\/p>

Progetto<\/th>Tipo<\/th>Token<\/th>Note<\/th><\/tr><\/thead>
elizaOS<\/td>Framework open source<\/td>Nessuno (ELIZAOS abbandonato)<\/td>TypeScript, MIT, ~19.500 stelle<\/td><\/tr>
Virtuals Protocol<\/td>Launchpad di agenti<\/td>VIRTUAL<\/td>Base e Solana, no-code<\/td><\/tr>
Olas (Autonolas)<\/td>Rete di agenti<\/td>OLAS<\/td>Mech Marketplace, mercati predittivi<\/td><\/tr>
LangChain \/ CrewAI<\/td>Framework generalisti<\/td>Nessuno<\/td>Potenti ma non crypto-nativi<\/td><\/tr><\/tbody><\/table><\/figure>

Sul piano di mercato, il settore resta vivace nonostante la debacle di ELIZAOS. La categoria \u00abAI Agents\u00bb di CoinGecko<\/a> 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 \u00e8 la lezione pi\u00f9 chiara di tutta la vicenda: la qualit\u00e0 di un framework e la performance di un token sono due cose diverse. E poich\u00e9 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<\/a>.<\/p>

Consob, MiCA e fisco: cosa cambia per chi costruisce in Italia<\/h2>

Per chi costruisce in Italia, la buona notizia \u00e8 che il framework in s\u00e9 non \u00e8 un servizio finanziario regolamentato: \u00e8 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.<\/p>

Il primo principio \u00e8 che un agente non ha personalit\u00e0 giuridica: non \u00e8 un soggetto di diritto, non ha un codice fiscale, non risponde di nulla. La responsabilit\u00e0 ricade sull’essere umano o sulla societ\u00e0 che lo mette in funzione (il principal). Il secondo principio riguarda l’attivit\u00e0 svolta: se l’agente si limita a operare in autonomia su asset propri siamo nel perimetro delle cripto-attivit\u00e0, 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 \u00e8 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 \u00e8 chiuso il 1 luglio 2026 con nove soggetti abilitati, come comunicato dalla stessa Consob<\/a>.<\/p>

C’\u00e8 poi il fisco, dove si annida un dettaglio pratico spesso ignorato. Dal 1 gennaio 2026 le plusvalenze in cripto-attivit\u00e0 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<\/a>. La conseguenza per un agente \u00e8 concreta: ogni pagamento in stablecoin in dollari pu\u00f2 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 \u00e8 tutt’altro che chiuso: ne abbiamo scritto a proposito della richiesta dell’Intergruppo di tornare al 26% dal 2027<\/a>. Occhio infine alla frequenza: un’operativit\u00e0 automatica 24 ore su 24 rischia la riqualificazione in reddito d’impresa.<\/p>

Conviene costruirci nel 2026? Il verdetto<\/h2>

Arriviamo al verdetto. I punti di forza di Eliza nel 2026 sono difficili da negare: \u00e8, per ammissione del suo autore, uno dei framework end-to-end pi\u00f9 completi; ha un ecosistema di plugin enorme e mantenuto anche da team esterni; \u00e8 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 \u00e8 un punto di partenza credibile, forse il pi\u00f9 credibile in circolazione.<\/p>

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

Il paradosso finale \u00e8 che la morte del token \u00e8 stata, con ogni probabilit\u00e0, la cosa migliore che potesse capitare al codice: senza la pressione speculativa resta un progetto di ingegneria, giudicabile per ci\u00f2 che fa. \u00abEliza \u00e8 morta. Lunga vita a Eliza\u00bb, ha scritto Walters. Per una volta lo slogan coincide con la realt\u00e0 tecnica.<\/p>

Domande frequenti<\/h2>

Il framework Eliza \u00e8 morto insieme al token ELIZAOS?<\/h3>

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

In che linguaggio \u00e8 scritto Eliza e serve un token per usarlo?<\/h3>

Il nucleo \u00e8 scritto in TypeScript ed \u00e8 distribuito con licenza MIT, quindi si pu\u00f2 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\u00e0 consolidati.<\/p>

Quanto \u00e8 sicuro dare un wallet a un agente Eliza?<\/h3>

\u00c8 il punto pi\u00f9 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\u00f9 di quanto tu sia disposto a perdere.<\/p>

Che differenza c’\u00e8 tra Eliza, Virtuals e Olas?<\/h3>

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

Come vengono tassati in Italia i guadagni di un agente crypto?<\/h3>

I guadagni sono imputati alla persona o alla societ\u00e0 proprietaria del wallet, non all’agente, che non ha personalit\u00e0 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 \u00e8 potenzialmente imponibile e un’operativit\u00e0 ad alta frequenza pu\u00f2 essere riqualificata come reddito d’impresa.<\/p>