{"id":539,"date":"2026-09-09T22:33:46","date_gmt":"2026-09-09T22:33:46","guid":{"rendered":"https:\/\/hoge.gg\/it\/eliza-framework-2026-agenti-ai-wallet-fiducia\/"},"modified":"2026-09-09T22:33:46","modified_gmt":"2026-09-09T22:33:46","slug":"eliza-framework-2026-agenti-ai-wallet-fiducia","status":"publish","type":"post","link":"https:\/\/hoge.gg\/it\/eliza-framework-2026-agenti-ai-wallet-fiducia\/","title":{"rendered":"Eliza framework 2026: agenti AI con wallet e il nodo della fiducia"},"content":{"rendered":"

Il 4 agosto 2026 il fondatore Shaw Walters ha scritto tre parole che hanno chiuso una delle storie pi\u00f9 chiacchierate della cripto-AI: \u00abThe token is dead. Completely\u00bb. Con quella frase, ripresa da CoinDesk<\/a> e da The Block<\/a>, 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. \u00c8 il paradosso che definisce questo progetto nel 2026: il token \u00e8 morto, il codice no.<\/p>

Se un progetto AI-crypto sopravvive alla morte del proprio token, cosa resta davvero? E soprattutto: ci si pu\u00f2 fidare di consegnare un wallet a un agente costruito con quel codice? Questa guida spiega che cos’\u00e8 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\u00f9 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<\/a>, contro un picco che valeva circa 2,4 miliardi di dollari.<\/p>

Che cos’\u00e8 il framework Eliza (e perch\u00e9 non \u00e8 il token ELIZAOS)<\/h2>

Eliza (nome del pacchetto: elizaOS) \u00e8 un framework open-source scritto in TypeScript per costruire agenti AI autonomi. Nel gergo del settore, un agente non \u00e8 un semplice bot di trading a regole: \u00e8 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. \u00c8 questa combinazione, LLM pi\u00f9 wallet pi\u00f9 autonomia, a rendere gli agenti interessanti e, come vedremo, pericolosi.<\/p>

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

Il punto che quasi tutti confondono \u00e8 questo: il framework e il token sono due cose diverse. Il framework \u00e8 software libero, chiunque pu\u00f2 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\u00e0 del codice non ha mai coinciso con la performance del token, e il 2026 lo ha dimostrato nel modo pi\u00f9 netto: il token \u00e8 andato praticamente a zero mentre lo sviluppo del codice non si \u00e8 fermato.<\/p>

Dal fondo ai16z a elizaOS: la parabola in breve<\/h2>

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 \u00e8 social: il venture capitalist Marc Andreessen (il nome ai16z gioca sulla sua a16z) rilancia il progetto su X con un lapidario \u00abGAUNTLET THROWN\u00bb, 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<\/a>.<\/p>

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 \u00abMarketplace of Trust\u00bb. 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>. A novembre 2025 parte la migrazione dal vecchio token ai16z al nuovo ELIZAOS.<\/p>

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<\/a>: 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<\/a> spiega la sua scelta: \u00abI am starting over, since I own the IP, and I am never letting a token come close to Eliza again\u00bb, ricomincio da capo, possiedo la propriet\u00e0 intellettuale e non lascer\u00f2 mai pi\u00f9 che un token si avvicini a Eliza.<\/p>

Data<\/th>Evento<\/th><\/tr><\/thead>
Ottobre 2024<\/td>Lancio di ai16z su Solana via daos.fun; il tweet \u00abGAUNTLET THROWN\u00bb di Marc Andreessen fa esplodere la capitalizzazione<\/td><\/tr>
2 gennaio 2025<\/td>Picco, capitalizzazione stimata intorno ai 2,4 miliardi di dollari<\/td><\/tr>
28 gennaio 2025<\/td>Rebrand da ai16z a elizaOS su richiesta di distanziamento di a16z<\/td><\/tr>
Novembre 2025<\/td>Migrazione del token ai16z verso ELIZAOS<\/td><\/tr>
Aprile 2026<\/td>Class action di Burwick Law alla corte federale di New York<\/td><\/tr>
4 agosto 2026<\/td>Walters: \u00abThe token is dead. Completely\u00bb; fondazione in liquidazione<\/td><\/tr>
2 settembre 2026<\/td>Nuovo minimo storico del token, circa 0,0001594 dollari<\/td><\/tr><\/tbody><\/table><\/figure>

Come funziona un agente Eliza: l’architettura in pratica<\/h2>

Sotto il cofano, un agente Eliza \u00e8 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\u00e0 dell’agente \u00e8 definita in un character file, un documento che descrive chi \u00e8 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.<\/p>

Il cuore programmabile del framework sono quattro primitivi, tutti registrati attraverso un’unica interfaccia Plugin, come documentato nella documentazione ufficiale<\/a>. Capirli \u00e8 il modo pi\u00f9 rapido per farsi un’idea di che cosa un agente possa e non possa fare.<\/p>

Primitivo<\/th>Che cosa fa<\/th>Esempio<\/th><\/tr><\/thead>
Actions<\/td>Le azioni che l’agente pu\u00f2 compiere<\/td>Inviare un token, pubblicare un post, eseguire uno swap<\/td><\/tr>
Providers<\/td>Iniettano contesto e dati prima che il modello decida<\/td>Saldo del wallet, prezzi, ora del giorno, cronologia<\/td><\/tr>
Evaluators<\/td>Elaborano ci\u00f2 che \u00e8 successo dopo un’azione<\/td>Estrarre fatti da salvare in memoria, valutare l’esito<\/td><\/tr>
Services<\/td>Connessioni persistenti a sistemi esterni<\/td>Client Discord o Telegram, nodo RPC, database<\/td><\/tr><\/tbody><\/table><\/figure>

Attorno a questi primitivi ruotano due elementi decisivi. Il primo \u00e8 la memoria: l’agente conserva conversazioni, fatti e rappresentazioni vettoriali (embeddings) e, quando deve agire, recupera il contesto rilevante con tecniche di retrieval (RAG). \u00c8 ci\u00f2 che gli permette di ricordarti e di comportarsi in modo coerente nel tempo. Il secondo \u00e8 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\u00f9 agenti e pi\u00f9 persone di coesistere nello stesso ambiente.<\/p>

Sui modelli, Eliza \u00e8 agnostico: pu\u00f2 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\u00e0 dei dati. Questa flessibilit\u00e0 \u00e8 il motivo per cui il framework viene usato tanto per bot social e assistenti quanto per agenti finanziari on-chain.<\/p>

Il wallet \u00e8 il punto in cui tutto diventa serio<\/h2>

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. \u00c8 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, \u00e8 il vero nodo della fiducia.<\/p>

Il parallelo pi\u00f9 utile \u00e8 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\u00f2 che gli viene mostrato. Un agente AI vive in una condizione strutturalmente simile, moltiplicata per la velocit\u00e0 e per l’autonomia. Ecco perch\u00e9, con il token ormai fuori gioco, la domanda che conta per Eliza nel 2026 non \u00e8 pi\u00f9 quanto vale, ma quanto \u00e8 sicuro affidargli un wallet.<\/p>

Prompt injection: il modello non distingue istruzione da dato<\/h2>

Il difetto \u00e8 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. \u00c8 la classe di vulnerabilit\u00e0 che l’OWASP cataloga come LLM01, prompt injection, ed \u00e8 considerata la pi\u00f9 pericolosa per gli agenti.<\/p>

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

Memory injection, l’attacco pi\u00f9 insidioso<\/h2>

Nel 2026 il lavoro accademico pi\u00f9 citato su questo fronte \u00e8 lo studio \u00abReal AI Agents with Fake Memories\u00bb<\/a>, 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.<\/p>

La conclusione \u00e8 controintuitiva e pesante: i modelli sono pi\u00f9 vulnerabili all’iniezione in memoria che al prompt injection classico. Se un attaccante riesce a corrompere ci\u00f2 che l’agente ricorda, le difese pensate per filtrare i prompt in ingresso servono a poco, perch\u00e9 il contesto avvelenato \u00e8 gi\u00e0 dentro. \u00c8 un problema profondo, perch\u00e9 la memoria persistente \u00e8 esattamente ci\u00f2 che rende un agente utile (ricorda te, i tuoi ordini, le tue preferenze), ma \u00e8 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\u00f9 di quelle basate sui prompt, ma nessuna difesa si \u00e8 dimostrata risolutiva. La copertura di Decrypt<\/a> ha sintetizzato il punto notando che gli agenti non hanno un modo affidabile di verificare l’integrit\u00e0 delle voci salvate in memoria.<\/p>

Il caso Grok\/Bankr e perch\u00e9 riguarda anche Eliza<\/h2>

Che non sia teoria lo ha mostrato un incidente reale. Il 4 maggio 2026, secondo l’archivio incidenti dell’OECD.AI<\/a>, 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.<\/p>

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

Vettore<\/th>Come funziona<\/th>Difesa parziale<\/th><\/tr><\/thead>
Prompt injection (OWASP LLM01)<\/td>Testo ostile spacciato per istruzione legittima<\/td>Filtri sull’input, separazione dei canali, permessi minimi<\/td><\/tr>
Memory injection<\/td>Corruzione del contesto salvato in memoria<\/td>Fine-tuning, controlli di integrit\u00e0 sulle voci<\/td><\/tr>
Escalation di privilegi<\/td>Ottenere diritti (per esempio via NFT o ruolo) che sbloccano azioni sensibili<\/td>Whitelist di azioni, conferma umana sopra una certa soglia<\/td><\/tr><\/tbody><\/table><\/figure>

Autonomia contro sicurezza, il dilemma irrisolto<\/h2>

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\u00f2 che lo rendeva attraente. Un agente che deve chiedere il permesso per ogni mossa \u00e8, in pratica, un’app con qualche fronzolo in pi\u00f9. Ma un agente davvero autonomo con accesso a un wallet \u00e8, per costruzione, a un prompt ostile di distanza dal disastro.<\/p>

Vitalik Buterin ha proposto una linea dura. Sul suo blog (secure_llms<\/a>, aprile 2026) riassume cos\u00ec l’approccio corretto: \u00abAll LLM inference local first. All files hosted locally. Sandbox everything\u00bb, inferenza locale prima di tutto, file ospitati in locale, isolare ogni componente. In interventi ripresi da testate di settore<\/a> 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\u00f9 LLM che funziona come una doppia firma.<\/p>

Lo stesso Walters \u00e8 stato sorprendentemente franco sul limite di fondo. Gi\u00e0 a Token2049, in dichiarazioni riprese da Decrypt<\/a>, aveva ammesso: \u00abYou probably do not want to give an AI agent a bunch of money and expect it to make you more\u00bb, probabilmente non \u00e8 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\u00f9 usati per gli agenti finanziari, \u00e8 un avvertimento che pesa.<\/p>

La risposta del settore: compute verificabile (e i suoi limiti)<\/h2>

Una parte del settore risponde con il compute verificabile. L’idea \u00e8 dimostrare crittograficamente che un certo calcolo (una inferenza del modello) \u00e8 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<\/a> puntano a rendere l’inferenza AI verificabile e riservata direttamente on-chain.<\/p>

C’\u00e8 per\u00f2 un equivoco da evitare. Il compute verificabile prova l’integrit\u00e0 (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\u00f2 comunque essere ingannato da un prompt injection o da una memoria avvelenata: la prova crittografica certifica il come del calcolo, non la bont\u00e0 della decisione. \u00c8 una distinzione che nel marketing sparisce spesso, e che chi valuta un agente per gestire fondi deve tenere ben presente.<\/p>

Chi mantiene Eliza ora che la fondazione chiude<\/h2>

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’\u00e8 pi\u00f9 una tesoreria a pagare gli sviluppatori? Nel caso di Eliza si delineano tre modelli di stewardship, non mutuamente esclusivi.<\/p>

Il primo \u00e8 Walters stesso con il core team: possiede l’IP, ha dichiarato di ricominciare da capo e di non voler pi\u00f9 legare un token a Eliza, e continua a costruire, con una visione che guarda sempre pi\u00f9 ai giochi (il progetto Hyperscape, un’ambizione descritta come una sorta di AI RuneScape). Come ha detto a BlockchainGamer.biz, \u00abplaying games is the path to agents that do the real work\u00bb, giocare \u00e8 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.<\/p>

Il rischio \u00e8 evidente: senza una fondazione e senza fondi dedicati, chi finanzia la manutenzione della sicurezza, cio\u00e8 proprio l’aspetto pi\u00f9 critico visto sopra? \u00c8 una domanda aperta, e vale per l’intera categoria degli agenti open-source, non solo per Eliza.<\/p>

Eliza a confronto con gli altri framework<\/h2>

Eliza non \u00e8 l’unico modo per costruire agenti. Vale la pena collocarlo nel panorama, perch\u00e9 le differenze di filosofia contano quanto quelle tecniche.<\/p>

Framework<\/th>Linguaggio<\/th>Token<\/th>Profilo<\/th><\/tr><\/thead>
elizaOS (Eliza)<\/td>TypeScript (Rust e Python in arrivo)<\/td>Token defunto, framework MIT vivo<\/td>Crypto-native, orientato a personalit\u00e0 e plugin, forte spinta verso il gaming<\/td><\/tr>
Virtuals Protocol<\/td>Piattaforma no-code<\/td>VIRTUAL, attivo<\/td>Launchpad per agenti su Base e Solana<\/td><\/tr>
Olas (Autonolas)<\/td>Python<\/td>OLAS, attivo<\/td>Agenti autonomi coordinati, DeFAI e mercati predittivi<\/td><\/tr>
LangChain<\/td>Python e JavaScript<\/td>Nessun token<\/td>General-purpose, orientato all’enterprise, non crypto-native<\/td><\/tr>
CrewAI<\/td>Python<\/td>Nessun token<\/td>Orchestrazione multi-agente, senza wallet nativo<\/td><\/tr><\/tbody><\/table><\/figure>

La lettura \u00e8 semplice: Eliza \u00e8 crypto-native e mette al centro la personalit\u00e0 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\u00f9 diffusi (LangChain e CrewAI) non abbiano mai avuto un token e prosperino comunque \u00e8 un dato che pesa sulla riflessione del prossimo paragrafo.<\/p>

Il token \u00e8 morto, ma il settore vive: la svolta senza token<\/h2>

Zoomando indietro, il settore degli agenti AI on-chain \u00e8 tutt’altro che spento. La categoria AI Agents di CoinGecko<\/a> 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’\u00e8 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\u00e0.<\/p>

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

Vale anche la pena ricordare che il crollo di ELIZAOS \u00e8 stato in larga parte idiosincratico, legato alla causa e alla perdita di fiducia, non a un tracollo di mercato: si \u00e8 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<\/a>. Un token pu\u00f2 morire da solo, senza bisogno di un mercato orso.<\/p>

Cosa significa per un utente o uno sviluppatore italiano<\/h2>

Sul piano normativo, la buona notizia per chi guarda a Eliza \u00e8 che il framework in s\u00e9, in quanto software open-source, non \u00e8 un servizio finanziario regolato. In Italia la vigilanza sui servizi in cripto-attivit\u00e0 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 \u00e8 chiuso il 1 luglio 2026 con nove soggetti abilitati<\/a>; chi vuole capire come si ottiene un’autorizzazione pu\u00f2 leggere la nostra guida alla licenza CASP<\/a>.<\/p>

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

Sul fisco, infine, il punto dolente. Dal 1 gennaio 2026 le plusvalenze in cripto-attivit\u00e0 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<\/a>. Per un agente autonomo questo ha un risvolto concreto: il soggetto d’imposta \u00e8 il proprietario del wallet, ogni cessione \u00e8 potenzialmente un evento tassabile, e un bot che opera 24 ore su 24 pu\u00f2 generare migliaia di micro-eventi da rendicontare, con il rischio ulteriore che un’attivit\u00e0 cos\u00ec sistematica venga riqualificata come reddito d’impresa. La comodit\u00e0 dell’automazione, sul piano fiscale, pu\u00f2 trasformarsi in un incubo di rendicontazione.<\/p>

Domande frequenti<\/h2>

Il token ELIZAOS \u00e8 morto: il framework Eliza funziona ancora?<\/h3>

S\u00ec. Il token e il framework sono due cose distinte. Il codice di Eliza (elizaOS) \u00e8 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\u00e0 a costruirlo, questa volta senza alcun token collegato.<\/p>

\u00c8 sicuro dare a un agente Eliza il controllo di un wallet?<\/h3>

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 \u00e8 non affidare a un agente pi\u00f9 di quanto si \u00e8 disposti a perdere, usare un wallet dedicato con fondi limitati, impostare tetti di spesa e prevedere una conferma umana per le operazioni rilevanti.<\/p>

Che differenza c’\u00e8 tra ai16z ed elizaOS?<\/h3>

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

Come vengono tassati in Italia i guadagni di un agente AI on-chain?<\/h3>

Le plusvalenze in cripto-attivit\u00e0 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 \u00e8 il proprietario del wallet, non l’agente, che non ha personalit\u00e0 giuridica. Il trading automatico ad alta frequenza pu\u00f2 inoltre far scattare la riqualificazione dei proventi come reddito d’impresa.<\/p>

Eliza \u00e8 meglio di LangChain o Virtuals?<\/h3>

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