Eliza framework 2026: il token è morto, chi paga il codice?

Il 5 novembre 2026 parte su Robinhood Chain l’asta di $SLOP, il token di un sistema chiamato Slop Cash pensato per pagare chi scrive codice open-source. Dietro quel lancio c’è Shaw Walters, lo stesso sviluppatore che due anni fa aveva creato ai16z, il «fondo AI» diventato in poche settimane una delle storie più chiacchierate del settore e poi uno dei suoi crolli più rumorosi. Il token di quel progetto, oggi ribattezzato ELIZAOS, è sceso di oltre il 97% dal suo massimo storico (CoinGecko). Il codice che lo ha reso celebre, invece, è ancora vivo e continua a lavorare.

Quel codice è il framework Eliza: la libreria open-source più usata per costruire agenti AI autonomi che vivono sulla blockchain, parlano sui social e, nei casi più spinti, controllano un wallet. Capire Eliza nel 2026 significa tenere separate due cose che il mercato ha fatto di tutto per confondere: la qualità di un software e il prezzo di un token. Sono due storie diverse, e solo una delle due è finita male.

Questa è una guida a che cos’è il framework Eliza, come è fatto un agente costruito con esso, perché il token è morto mentre il repository continua a crescere e come un meccanismo di finanziamento senza token di protocollo (Slop Cash, con l’asta $SLOP della prossima settimana) prova a rispondere alla domanda più scomoda del software libero: chi paga gli sviluppatori quando non c’è una moneta da gonfiare.

Che cos’è il framework Eliza

Eliza è un framework open-source scritto in TypeScript per costruire agenti AI autonomi. Lo sviluppa Eliza Labs, la realtà nata dalla DAO che un tempo si chiamava ai16z, e la figura di riferimento è Shaw Walters. Il nome è un omaggio a ELIZA, il programma conversazionale scritto da Joseph Weizenbaum al MIT negli anni Sessanta: un richiamo volutamente ironico, perché gli agenti di oggi fanno molto più che rispondere con frasi preconfezionate.

Un agente non è un chatbot e non è un bot di trading a regole fisse. È la combinazione di quattro ingredienti: un modello linguistico che pianifica e interpreta, una memoria persistente, un insieme di strumenti (dai social al wallet on-chain) e un margine di autonomia che gli permette di decidere e, quando serve, firmare transazioni da solo. Eliza fornisce l’impalcatura che tiene insieme questi pezzi. Nel paper che descrive il sistema, Walters e i coautori lo riassumono così: «ogni aspetto di Eliza è un normale programma TypeScript sotto il pieno controllo del suo utente» (arXiv), una scelta di progettazione che privilegia la leggibilità e il controllo rispetto alla magia opaca.

Numeri alla mano, Eliza è uno dei progetti di AI più seguiti su GitHub: il repository elizaOS/eliza conta circa 19.700 stelle e 5.900 fork, è distribuito con licenza MIT e si presenta come «il tuo sistema operativo agentico». È model-agnostic, cioè non sposa un singolo fornitore di modelli: può appoggiarsi a servizi cloud oppure girare in locale con modelli leggeri della famiglia Gemma. Questa neutralità è una delle ragioni per cui Eliza è diventato uno standard di fatto per chi costruisce agenti, ben oltre il perimetro del progetto che l’ha generato.

Da ai16z al token morto: la cronologia

Per capire perché su Eliza aleggia ancora l’ombra di un token, bisogna tornare all’ottobre 2024. Walters lancia su daos.fun un fondo chiamato ai16z: il nome gioca spudoratamente con a16z, la società di venture capital di Marc Andreessen. Il meccanismo di daos.fun è lineare: una raccolta di una settimana, un trader (qui presentato come un agente AI) che controlla la tesoreria, i token scambiati su un AMM e, alla scadenza, la possibilità per chi detiene i token di bruciarli per riscuotere la quota proporzionale di tesoreria. Un endorsement di Andreessen su X fa esplodere la raccolta: il fondo sfiora i 100 milioni di dollari di capitalizzazione in poche ore (The Block).

Da lì la parabola è vertiginosa. Il progetto si ribattezza ElizaOS a fine gennaio 2025, il token tocca un picco di circa 2,4 miliardi di dollari di capitalizzazione il 2 gennaio 2025, poi comincia la discesa. A novembre 2025 arriva una migrazione da ai16z a un nuovo contratto ELIZAOS. Ma è nel 2026 che il castello crolla: ad aprile lo studio Burwick Law deposita una class action alla corte federale di New York (SDNY) con due accuse di fondo, che il marchio imitasse a16z inducendo in errore gli investitori e che l’autonomia dell’agente fosse gonfiata, con persone in carne e ossa a gestire di fatto le operazioni.

L’accusa sull’autonomia non era inedita. Già nell’ottobre 2024 la testata Protos aveva definito «AI-washing» la narrazione dei fondi su daos.fun, osservando che nessuno era davvero gestito da un’intelligenza artificiale e che dietro ai16z c’era «un umano di nome Shaw» (Protos). Davanti al giudice Jed Rakoff, Walters sceglie di non combattere: la fondazione trasferisce la tesoreria per chiudere la causa. Il 5 agosto 2026 lo sviluppatore mette la parola fine al token con una frase diventata virale, «Il token è morto. Completamente», e aggiunge: «La loro pretesa era ridicola, ma non avevamo il capitale per combatterla in tribunale», e ancora «Ricomincio da capo, dato che possiedo la proprietà intellettuale, e non lascerò mai più che un token si avvicini a Eliza» (CoinDesk).

Perché framework e token non sono la stessa cosa

Il punto che quasi tutti i titoli di giornale hanno mancato è semplice: il token ELIZAOS non ha mai avuto una funzione tecnica dentro il framework. Non è il carburante che paga l’esecuzione degli agenti, non è una commissione per usare la libreria, non è un lasciapassare per scaricare il codice. Era uno strumento di finanziamento e di speculazione agganciato a un progetto software, nato dal meccanismo di daos.fun. La sua morte, per quanto fragorosa, non toglie nulla all’utilità del codice.

La licenza MIT lo rende evidente: chiunque può clonare, usare e modificare Eliza senza possedere un solo token. È per questo che il repository ha continuato a crescere mentre la capitalizzazione evaporava. Un progetto di software open-source si misura in contributi, fork, plugin e agenti effettivamente in produzione, non nel grafico di un asset su un exchange. Confondere i due piani, qualità del software e performance del token, è stato l’errore che ha gonfiato ai16z e poi lo ha fatto implodere.

Questa distinzione ha un risvolto pratico per chi investe o costruisce. Un token che non svolge alcuna funzione di protocollo non ha un meccanismo che leghi il suo prezzo all’uso del software: può salire o scendere per ragioni che non hanno niente a che vedere con il numero di agenti attivi. È una lezione che vale per buona parte del settore degli agenti AI, dove la narrazione corre spesso molto più veloce dell’adozione reale, e dove il grafico di un token racconta la febbre speculativa del momento, non lo stato di salute del progetto.

Come è fatto un agente: runtime, character file e i quattro primitivi

Al centro di ogni agente Eliza c’è il runtime (AgentRuntime), il motore che riceve gli input, costruisce il contesto da passare al modello, decide quali azioni eseguire e scrive i risultati in memoria. Attorno al runtime ruota il character file: un documento che definisce la personalità dell’agente, la sua biografia, lo stile di scrittura, le conoscenze di base e i plugin abilitati. È la differenza fra un agente che scrive sui social come un trader cinico e uno che risponde come un assistente tecnico: stesso motore, carattere diverso.

Il comportamento vero e proprio nasce dalla combinazione di quattro primitivi, i mattoni concettuali del framework:

• Actions: le capacità operative dell’agente, dall’invio di un messaggio alla chiamata di un’API fino alla firma di una transazione on-chain.
• Providers: le fonti che iniettano contesto in tempo reale nel prompt, come l’ora, il saldo del wallet o i dati di mercato.
• Evaluators: i processi che girano dopo l’interazione, estraggono fatti, aggiornano la memoria e valutano se gli obiettivi sono stati raggiunti.
• Memory: l’archivio persistente, spesso con ricerca semantica, che dà all’agente continuità fra una sessione e l’altra.

Sopra questi mattoni, Eliza organizza il mondo sociale dell’agente con tre astrazioni: Worlds (gli spazi, per esempio un server Discord), Rooms (le stanze o i canali in cui si conversa) ed Entities (le identità con cui l’agente interagisce). Questa struttura permette a un singolo agente di essere presente su più piattaforme contemporaneamente mantenendo una memoria coerente di chi ha incontrato e dove. Il tutto, come ricorda Walters, resta «un normale programma TypeScript»: niente scatole nere, tutto ispezionabile e modificabile. È una filosofia opposta a quella degli assistenti chiusi, e spiega perché tanti sviluppatori abbiano scelto Eliza come punto di partenza.

Plugin, modelli e interoperabilità: il vero fossato

Se il runtime è il motore, i plugin sono le ruote, le marce e gli accessori. Eliza espone una singola interfaccia Plugin attraverso cui si aggiungono integrazioni: connettori per i social, adattatori per decine di reti EVM, moduli per modelli di AI diversi, strumenti DeFi. Walters rivendica un ecosistema di oltre 250 plugin, ed è questo, più del codice del core, il vero fossato competitivo del progetto: chi vuole costruire un agente trova già pronto quasi tutto ciò che serve a collegarlo al mondo, senza riscrivere le integrazioni da zero.

Il secondo pilastro è l’interoperabilità. Eliza si aggancia agli standard emergenti dell’economia degli agenti: il Model Context Protocol (MCP) per collegare strumenti e fonti dati, i protocolli agente-a-agente e i binari di pagamento come x402, pensati per far pagare le macchine quando consumano un servizio. A novembre 2025 il progetto ha integrato Chainlink CCIP per i messaggi cross-chain. La direzione è chiara: un agente non deve vivere in un silos, ma muoversi fra catene, servizi e altri agenti come se parlassero tutti la stessa lingua.

Il terzo pilastro è la neutralità rispetto ai modelli. Eliza può usare modelli in cloud oppure, sempre più spesso, modelli eseguiti in locale, un tema caro a chi mette la privacy davanti alla comodità e che ricorre anche in altre scommesse del settore sull’AI privata e decentralizzata. Il repository è organizzato come un monorepo che contiene il runtime, l’app Eliza, la CLI, i servizi cloud, i bridge nativi e i plugin di prima parte, con distribuzioni per Linux e Android. Vale una precisazione tecnica, perché circola molta confusione: il core resta TypeScript (su Node e Bun), mentre Python compare solo nella suite di benchmark; le voci su una riscrittura in Rust o su un core multilinguaggio restano piani dichiarati da Walters, non un prodotto già rilasciato.

Chi paga il codice senza token: Slop Cash

Morto il token, resta la domanda che tormenta tutto il software libero: chi paga chi scrive il codice? La risposta di Walters si chiama Slop Cash, un sistema di finanziamento non custodiale per progetti open-source costruito insieme a Drew Pierson. Lo slogan è provocatorio quanto il progetto, «make money shipping open source», cioè fare soldi pubblicando software libero.

Il meccanismo è pensato per evitare i soldi facili. Slop Cash paga solo il lavoro effettivamente integrato (le pull request accettate e le revisioni di codice), con un punteggio deterministico e pubblico; i risultati mensili vengono congelati in proposte con una finestra di revisione di 14 giorni prima del pagamento. I contributori sono retribuiti in stablecoin, non nel token del progetto. Un dettaglio cambia la natura del sistema: a essere pagati possono essere esseri umani oppure agenti AI, il che riporta al centro il tema di come si distingue un umano da una macchina quando entrambi possono incassare.

I numeri iniziali sono concreti: da luglio 2026 il sistema ha completato alcuni cicli mensili e, secondo i dati pubblicati, i pagamenti di settembre ammontano a 6.005 USDC distribuiti in 72 trasferimenti per il lavoro svolto ad agosto, su pool che includono elizaOS, il progetto ASI e Slop Cash stesso (ChainCatcher). Non è beneficenza né un airdrop: è una paga legata alla produzione, verificabile sulla catena. È anche un tentativo di rispondere a un problema antico del software libero, quello di manutentori fondamentali che lavorano gratis finché non si esauriscono.

Il confronto con gli altri modelli di finanziamento del software libero aiuta a inquadrare la scommessa. Le donazioni e le sponsorizzazioni (il modello di GitHub Sponsors) dipendono dalla buona volontà; i grant retroattivi come il RetroPGF di Optimism premiano l’impatto ma con cadenze lunghe e con giurie che decidono; i bug bounty pagano soltanto la sicurezza. Slop Cash prova una via diversa: trasformare ogni pull request accettata in un’unità di valore misurabile e pagata subito, legando la remunerazione al flusso di lavoro quotidiano invece che a un evento periodico. È un esperimento, non una formula collaudata, ma affronta di petto il problema che ha svuotato tanti progetti critici.

L’asta $SLOP del 5 novembre, spiegata

Qui arriva la novità che rende questa settimana diversa dalle altre. Se i contributori vengono pagati in stablecoin, i soldi per pagarli devono pur arrivare da qualche parte: la tesoreria di Slop Cash viene finanziata e governata tramite un proprio token, $SLOP, che va all’asta. Il lancio è fissato per il 5 novembre 2026 su Robinhood Chain (TokenPost).

Il calendario è scandito: pre-bidding dal 5 novembre a mezzogiorno ora di New York (le 17:00 UTC), apertura formale delle offerte il 7 novembre e chiusura il 10 novembre alla stessa ora, con offerte in USDG, la stablecoin di Robinhood Chain. L’obiettivo di raccolta è di 400.000 dollari, a fronte di un’offerta fissa di 100 milioni di token, di cui 56 milioni in circolazione al lancio; il 45% è destinato all’asta pubblica (ChainCatcher). I proventi non finiscono in un wallet del team ma in una tesoreria on-chain non custodiale, governata da decision market.

Due avvertenze sono d’obbligo. La prima riguarda la sicurezza: secondo ChainCatcher i contratti della piattaforma Umia sono stati verificati da Certora, ma il contratto di pagamento di Slop Cash non è ancora stato sottoposto a un audit indipendente, un dettaglio non banale per un sistema che muove denaro reale. La seconda riguarda l’onestà della narrazione: il framework Eliza resta senza token, ma i token non sono spariti, sono saliti di un piano. Il software libero resta gratuito e i contributori sono pagati in stablecoin; la speculazione si concentra su $SLOP e sul token della piattaforma che lo ospita. Nei materiali del progetto i ruoli sono indicati con Drew Pierson come CEO e Shaw Walters come CTO.

Umia, i decision market e la lezione di ai16z

Slop Cash non nasce nel vuoto: è il primo progetto esterno lanciato su Umia, una piattaforma che vuole fare in modo pulito ciò che ai16z aveva fatto in modo caotico, cioè raccogliere capitali, strutturare una tesoreria e governarla. Dal punto di vista legale Slop Cash è un portafoglio segregato (Slop Cash, S.P.) all’interno di Umia Launcher SPC, una scelta che tiene separati codice, domini e account social dai soldi.

Umia ha fatto da apripista con il proprio token: ha raccolto circa 6,11 milioni di dollari a una valutazione completamente diluita di 18 milioni tramite un’asta di sette giorni su Base, tra fine agosto e inizio settembre 2026 (The Block). A guidarla c’è Francesco Mosterts, amministratore delegato con un passato nel fondo Point72, affiancato dal CTO Nicolas Racchi. La parte più interessante è il modello di governance: le decisioni che superano una certa soglia di spesa mensile non vengono prese a maggioranza di voti, ma attraverso decision market, mercati condizionali in cui viene eseguita l’opzione che il mercato valuta di più.

La tesi di Mosterts è la lezione appresa dal caso ai16z: «Un token liquido può spingere i team verso decisioni di breve periodo mirate ad alzarne il prezzo», ha spiegato, e per questo la struttura cerca di separare il valore del progetto dalle pressioni speculative. È esattamente l’errore che aveva trasformato un framework promettente in un caso giudiziario: il token era diventato il prodotto, e il prodotto era passato in secondo piano. Resta il paradosso, già visto: anche Umia è, a sua volta, un livello con un token, per cui la speculazione non viene eliminata, ma spostata e, nelle intenzioni, incanalata in regole più chiare.

Il token morto che continua a correre

C’è un paradosso che vale la pena guardare in faccia: Walters ha dichiarato morto il token, non ne possiede più alcuna quota e ne prende le distanze, eppure il ticker ELIZAOS continua a scambiare, a volte con strappi violenti. Nel 2026 esistono di fatto due token fantasma dello stesso progetto: ELIZAOS, quello migrato, e il vecchio AI16Z, rimasto sul contratto Solana originale.

I dati di CoinGecko fotografano la situazione: ELIZAOS capitalizza poco più di due milioni di dollari, in rialzo di oltre il 70% su trenta giorni ma ancora sotto del 97,5% rispetto al suo massimo; il vecchio AI16Z vale appena qualche centinaio di migliaia di dollari e non ha partecipato all’ultimo rimbalzo. Sommati, i due valgono circa due milioni e mezzo di dollari, ossia più o meno il 99,9% in meno del picco da circa 2,4 miliardi.

Perché un token ripudiato si muove ancora? Per tre ragioni che non hanno nulla a che fare con la qualità del codice: la liquidità è sottilissima, quindi bastano pochi ordini per far oscillare il prezzo; il settore degli agenti AI, che nel suo complesso capitalizza intorno ai 3,3 miliardi di dollari (CoinGecko), funge da cassa di risonanza; e il ciclo di notizie su Umia e Slop Cash alimenta la speculazione, anche se non esiste alcun legame meccanico fra quelle iniziative e il vecchio token. A questi livelli di scambio, la capitalizzazione è più una finzione contabile che un valore reale, e il fatto che proprio il ticker migrato (e non il legacy) salga conferma che a muoversi è la scommessa sul nome, non un fondamentale.

La sicurezza: un agente con wallet è una superficie d’attacco

Il rischio più sottovalutato di questi sistemi non è il prezzo del token, ma cosa succede quando a un agente si consegnano le chiavi di un wallet. Il difetto di fondo è strutturale: un modello linguistico non distingue in modo affidabile le istruzioni dai dati. Se un agente legge un post, un messaggio o una pagina web, un’istruzione ostile nascosta in quel testo può essere eseguita come se venisse dal suo proprietario. È la prompt injection, e per un agente che può firmare transazioni significa furto.

Non è teoria. Il 4 maggio 2026 un agente costruito su Grok e collegato al servizio Bankr è stato svuotato di circa 175.000 dollari: l’attaccante aveva nascosto un’istruzione in codice Morse in una risposta su X e regalato un NFT che sbloccava i diritti di trasferimento, un classico esempio di escalation di permessi (OECD.AI). La ricerca accademica ha mostrato inoltre che i modelli sono particolarmente vulnerabili alla memory injection, cioè a dati avvelenati salvati in memoria che riaffiorano più tardi condizionando le decisioni (arXiv). Non stupisce che il tema si intrecci con il nuovo fronte dell’enforcement su frodi crypto e intelligenza artificiale.

La difesa più citata arriva da Vitalik Buterin, che nel suo schema di LLM «locale, privato e sicuro» raccomanda di eseguire l’inferenza in locale quando possibile, di mettere ogni cosa in sandbox, di imporre un tetto alla spesa autonoma (dell’ordine di un centinaio di dollari al giorno) e di trattare l’essere umano e il modello come due fattori di conferma, in una logica 2-su-2 (vitalik.eth.limo). Buterin stima anche che una quota non trascurabile delle «skill» offerte agli agenti porti con sé istruzioni malevole. Il nodo irrisolto è che ogni limite serio all’autonomia (un’approvazione umana, un tetto di spesa) riduce proprio l’autonomia che rende questi agenti interessanti: è un compromesso, non una soluzione.

Regole e fisco: Consob, MiCA e la responsabilità di chi lo usa

Dal punto di vista normativo, un framework come Eliza è semplicemente software: MiCA regola gli emittenti di cripto-attività e i fornitori di servizi (i CASP), non le librerie open-source. In Italia il presidio spetta alla Consob per la condotta di mercato e la tutela dell’investitore e alla Banca d’Italia per i profili prudenziali e per le stablecoin, secondo l’impianto del D.lgs. 129/2024. Il punto delicato nasce quando il software diventa un agente che agisce: chi è responsabile se un agente autonomo compie un illecito o perde i fondi di un cliente?

La risposta oggi è netta: un agente non ha personalità giuridica, quindi la responsabilità ricade sull’essere umano o sulla società che lo mette in funzione. Se poi l’agente fornisce consulenza o gestisce un portafoglio per conto di terzi, si entra nel perimetro della MiFID II, non di MiCA: l’ESMA ha chiarito che l’uso dell’intelligenza artificiale nei servizi di investimento non sospende gli obblighi di governance, trasparenza e supervisione umana (ESMA). È il cuore della questione che il nostro approfondimento sulla compliance nella DeFi chiama la sala macchine: la norma cerca sempre un soggetto a cui imputare il controllo. Non a caso la stretta europea sulla vigilanza passa anche dalla proposta di affidare all’ESMA la supervisione diretta dei grandi CASP, un dossier che vede un italiano al vertice dell’Autorità.

Sul fronte fiscale, il 2026 ha cambiato le carte in Italia. Dal 1 gennaio le plusvalenze su cripto-attività sono tassate al 33% ed è stata abolita la soglia di esenzione da 2.000 euro, mentre le stablecoin in euro conformi a MiCA (gli e-money token) restano al 26% e la semplice conversione fra euro ed euro-stablecoin non genera plusvalenza (Fisco Oggi). Per un agente la differenza è enorme: se paga in stablecoin in dollari, ogni variazione di cambio rispetto all’euro può configurare un evento fiscalmente rilevante, moltiplicato per migliaia di micro-pagamenti; un token in euro eviterebbe gran parte di quei passaggi, il che è anche un argomento a favore della sovranità monetaria europea. Infine, l’uso di un agente per trading automatico ad alta frequenza, 24 ore su 24, rischia la riqualificazione dei proventi in reddito d’impresa.

Eliza tra gli altri framework per agenti

Eliza non è l’unico modo per costruire un agente, ma occupa una posizione particolare. La maggior parte dei concorrenti nasce attorno a un token o a un launchpad; Eliza nasce come libreria e runtime, con il token aggiunto dopo (e poi ripudiato). Virtuals Protocol, per esempio, è un launchpad no-code su Base e Solana che ha fatto nascere migliaia di agenti, con il token VIRTUAL al centro del modello economico. Olas (Autonolas) fornisce uno stack per servizi multi-agente, molto usato nei mercati predittivi. L’alleanza ASI riunisce Fetch.ai, SingularityNET e Ocean attorno al token FET.

La differenza non è solo tecnica ma filosofica. Un launchpad ha interesse a far nascere molti token; una libreria open-source ha interesse a far nascere molto codice. La scelta di Walters di rendere Eliza esplicitamente privo di token di protocollo, finanziandolo con Slop Cash, è un tentativo di rompere il legame tossico fra l’adozione del software e la speculazione che ha affondato ai16z. Se funzioni è un’altra questione, e la prima risposta arriverà proprio dall’esito dell’asta della prossima settimana.

Che cosa aspettarsi dopo il 5 novembre

Il banco di prova immediato è l’asta di $SLOP, che chiude il 10 novembre: se raggiunge l’obiettivo, Slop Cash avrà dimostrato che si può finanziare un framework senza vendere ai contributori l’illusione di un token da arricchimento. Se fallisce, la tesi del finanziamento senza speculazione subirà un colpo. Vale la pena ricordare che l’obiettivo dichiarato, 400.000 dollari, è modesto: la vera scommessa non è la cifra, ma il modello.

Sul fronte del prodotto, restano aperti i cantieri annunciati da Walters: usi nel gaming, un’eventuale evoluzione multilinguaggio del runtime, nuovi plugin. Conviene prenderli per quello che sono, piani, e non per funzioni già disponibili, perché la storia di questo progetto è lastricata di annunci anticipati. E resta sullo sfondo la domanda più grande, quella che lo stesso Walters ha posto con disarmante onestà parlando al Token2049 di Singapore: «probabilmente non vuoi dare a un agente AI un mucchio di soldi aspettandoti che te ne faccia guadagnare altri» (Decrypt).

È il paradosso con cui Eliza lascia il 2026: il framework è maturo, l’ecosistema di plugin è un fossato reale, la comunità di sviluppatori è viva. Ma la parte che aveva attirato miliardi, l’agente che fa soldi da solo, è anche la più fragile e la più pericolosa. La lezione del token morto non è che gli agenti AI on-chain siano una bolla; è che il software e la speculazione vanno tenuti su due binari separati. Eliza, a caro prezzo, lo ha imparato prima degli altri.

Domande frequenti

Che cos’è il framework Eliza?

Eliza è un framework open-source scritto in TypeScript, sviluppato da Eliza Labs, per costruire agenti AI autonomi che possono operare sui social e sulla blockchain. Fornisce un runtime, un sistema di memoria, i cosiddetti character file e un vasto ecosistema di plugin, ed è distribuito con licenza MIT.

ELIZAOS è lo stesso token di ai16z?

ELIZAOS è il token nato dalla migrazione del vecchio ai16z, avvenuta a novembre 2025. Il contratto originale AI16Z su Solana esiste ancora come token legacy, ma lo sviluppatore Shaw Walters ha dichiarato morto il token ad agosto 2026 e non ne possiede più alcuna quota.

Il framework Eliza ha un token ufficiale nel 2026?

No. Dopo la vicenda giudiziaria con Burwick Law, Walters ha deciso di mantenere il framework senza token di protocollo. Gli sviluppatori che contribuiscono vengono pagati in stablecoin tramite Slop Cash; la speculazione si concentra su token separati come $SLOP e quello della piattaforma Umia, non sul framework.

Che cos’è l’asta $SLOP del 5 novembre?

È l’asta del token $SLOP, che finanzia e governa la tesoreria di Slop Cash, il sistema che paga i contributori open-source. Si svolge su Robinhood Chain, con pre-bidding dal 5 novembre, offerte dal 7 e chiusura il 10 novembre, un obiettivo di 400.000 dollari e offerte nella stablecoin USDG.

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

È rischioso. Gli agenti basati su modelli linguistici sono vulnerabili alla prompt injection e alla manipolazione della memoria, come ha mostrato lo svuotamento di un agente Grok/Bankr per circa 175.000 dollari nel maggio 2026. Le buone pratiche prevedono tetti di spesa, sandbox, privilegi minimi e un’approvazione umana per le operazioni rilevanti.

Marcus Okafor è senior editor di HOGE Wire e segue gli agenti AI on-chain e l’intersezione fra cripto e intelligenza artificiale.