Eliza-Framework 2026: Leben nach dem Token

Der Code überlebt seinen eigenen Token

Am 21. Oktober 2026 steht das bekannteste KI-Agenten-Projekt der Kryptobranche in einem Zustand, den es so im Lehrbuch nicht gibt. Der dazugehörige Token, ELIZAOS, kostet laut CoinGecko rund 0,0004 US-Dollar (etwa 0,00035 Euro) und bringt es auf eine Marktkapitalisierung von knapp 3,0 Millionen US-Dollar, umgerechnet rund 2,6 Millionen Euro, Rang 2041. Zwei Jahre zuvor war genau dieses Projekt an der Börse der Aufmerksamkeit 2,39 Milliarden US-Dollar wert. Die Stiftung, die den Token trug, ist aufgelöst, die Kasse in einen Vergleich geflossen, der Gründer hat den Token öffentlich für tot erklärt.

Und doch läuft der Code weiter. Das Repository elizaOS/eliza auf GitHub zählt rund 19.600 Sterne, 5.800 Forks und mehr als 220 offene Pull Requests, Lizenz MIT, Hauptsprache TypeScript. Das ist kein Mausoleum, sondern eine aktive Baustelle. Genau hier liegt die Geschichte, die man 2026 über Eliza erzählen muss: nicht die vom spektakulären Absturz eines Tokens, die ist auserzählt, sondern die von einem Open-Source-Framework, das seinen eigenen Finanzierungsmechanismus überlebt hat und nun beweisen muss, dass Software-Qualität und Token-Kurs zwei verschiedene Dinge sind.

Dieser Text macht eine Bestandsaufnahme. Was ist das Eliza-Framework technisch heute, nachdem Token und Stiftung verschwunden sind? Wer schreibt den Code, wer bezahlt ihn, wer sichert ihn gegen Angriffe, und wer haftet, wenn ein Agent mit eigener Wallet Unsinn baut? Wir sehen uns die Architektur an, den Oktober-Kursausschlag des toten Tokens, den Finanzierungsversuch Slop Cash, die Gaming-Wette, das ungelöste Sicherheitsproblem, die Konkurrenz und den rechtlichen Rahmen für deutsche Nutzer unter BaFin, MiCA und Einkommensteuergesetz.

Was das Eliza-Framework heute ist

Eliza ist ein quelloffenes TypeScript-Framework zum Bau autonomer KI-Agenten. Ein Agent im Sinne von Eliza ist kein simpler Handels-Bot mit fest verdrahteten Wenn-dann-Regeln, sondern ein Programm, das ein Large Language Model als Denkapparat nutzt, Anweisungen interpretiert, einen Plan fasst, Werkzeuge aufruft und, wenn man es lässt, eigene Transaktionen signiert. Das zugehörige Paper der Entwickler trägt den Titel Eliza: A Web3 friendly AI Agent Operating System und beschreibt das System als erstes quelloffenes, Web3-freundliches Agenten-Framework, das Lese- und Schreibzugriffe auf Blockchains und die Interaktion mit Smart Contracts direkt einbaut.

Der entscheidende Satz aus diesem Paper lautet, dass „every aspect of Eliza is a regular Typescript program under the full control of its user“, also jeder Teil von Eliza ein gewöhnliches TypeScript-Programm unter voller Kontrolle des Nutzers sei. Das ist mehr als Marketing. Es ist die Design-Entscheidung, die das Projekt vom reinen Token-Spielplatz trennt: Eliza ist zuerst Software und erst danach, inzwischen gar nicht mehr, ein Token.

Das Repository selbst nennt sich mittlerweile „agentic operating system“, ein Betriebssystem für Agenten. In der Praxis bedeutet das: ein Laufzeitkern, der Wahrnehmung, Gedächtnis und Handlung eines Agenten orchestriert, dazu eine Sammlung von Bausteinen, mit denen ein Entwickler Persönlichkeit, Fähigkeiten und Anbindungen zusammensteckt. Wichtig für die Einordnung: Der Kern bleibt laut README TypeScript, Node und Bun; Python taucht offiziell nur in den Benchmarking-Werkzeugen auf (ab Version 3.11). Varianten in Rust und Python hat Gründer Shaw Walters mehrfach angekündigt, im Haupt-Repository sind sie bis heute nicht als fertiges Produkt sichtbar. Wer 2026 über Eliza schreibt, sollte diese Pläne als Absichtserklärung behandeln, nicht als Release.

Vom Milliarden-Fonds zum toten Token: die kurze Chronik

Um zu verstehen, warum der Code heute ohne Fundament dasteht, muss man die Entstehung kennen. Alles begann im Oktober 2024 als ai16z, ein KI-gesteuerter Krypto-Fonds auf der Plattform daos.fun. Der Name war eine Parodie auf die Risikokapitalfirma Andreessen Horowitz (a16z), und als deren Mitgründer Marc Andreessen das Projekt auf X erwähnte, schoss die Marktkapitalisierung laut The Block binnen Stunden auf fast 100 Millionen US-Dollar. Hinter dem Fonds stand das Framework, das Walters und sein Team gebaut hatten; der Fonds war die Show, die Software das eigentliche Werk.

Im Januar 2025 folgte die Umbenennung von ai16z zu ElizaOS. Der Token erreichte am 2. Januar 2025 seinen Höchststand bei einer Bewertung von 2,39 Milliarden US-Dollar; an jenem Tag wechselten Token im Wert von 291 Millionen US-Dollar den Besitzer. Im November 2025 migrierte der alte ai16z-Token auf den neuen ELIZAOS-Vertrag. Danach ging es fast nur noch abwärts.

Im April 2026 reichte die Kanzlei Burwick Law vor einem Bundesgericht in New York eine Sammelklage ein. Die Vorwürfe: irreführende Werbung, Nachahmung des a16z-Namens, vorgetäuschte Autonomie, während in Wahrheit Menschen die Fäden zogen, und eine Angebotsausweitung von 1,1 auf 11 Milliarden Token, bei der ein erheblicher Teil an Insider floss. Um den Rechtsstreit zu beenden, überwies die Stiftung ihr verbliebenes Vermögen in einen Vergleich und fuhr den Betrieb herunter.

Am 5. August 2026 zog Walters den Schlussstrich. „The token is dead. Completely“, schrieb er laut CoinDesk auf X, es werde „no further foundation support, buybacks or supply measures“ geben, also keine Stützungskäufe, keine Angebotskürzungen, keinen Ersatz-Token. Er selbst habe einst Token im Wert von rund 25 Millionen US-Dollar gehalten und zugesehen, wie dieser Wert gegen null fiel. Seine Konsequenz, ebenfalls öffentlich: „I am starting over, since I own the IP, and I am never letting a token come close to Eliza again“, er fange neu an, besitze das geistige Eigentum und lasse nie wieder einen Token in die Nähe von Eliza kommen. Der Code bleibt, der Token geht: So lässt sich das Fazit dieser Episode zusammenfassen.

Der Oktober-Zombie-Rally: Preis gegen Wert

Ein toter Token kann trotzdem zucken. In der ersten Oktoberhälfte 2026 sprang der ELIZAOS-Kurs plötzlich an, am 7. Oktober um rund 34 Prozent auf etwa 0,000566 US-Dollar, mit einem Hoch um den 11. Oktober. Auf 30-Tage-Sicht steht noch immer ein Plus von rund 143 Prozent, doch die Welle hat sich längst zurückgebildet: Auf Wochensicht liegt der Kurs rund 15 Prozent im Minus, und mit knapp 3,0 Millionen US-Dollar Marktkapitalisierung notiert der Token laut CoinGecko rund 96 Prozent unter seinem Allzeithoch.

Bemerkenswert ist, was den Ausschlag nicht war. Es gab keine Produktankündigung, keine Rückkehr der Stiftung, keinen mechanischen Zusammenhang zwischen Kurs und Code. Walters besitzt keine dieser Token und distanziert sich von ihnen. Der alte, migrierte AI16Z-Token bewegte sich kaum mit (30-Tage-Plus rund 24 Prozent gegenüber 143 Prozent beim ELIZAOS-Ticker), die Spekulation suchte sich also gezielt nur den neueren Namen aus. Als Treiber bleiben eine hauchdünne Liquidität, in die schon kleine Kauforders große Prozentsprünge schlagen, ein Nachrichtenzyklus rund um Walters’ neues Vorhaben Umia und Slop Cash sowie ein insgesamt festerer KI-Agenten-Sektor.

Die Episode ist mehr als eine Kuriosität, sie ist die klarste Illustration der zentralen These dieses Textes: Token-Kurs und Framework-Qualität sind entkoppelt. Ein Projekt, dessen Gründer den Token für tot erklärt hat und selbst keine Stücke hält, kann an der Börse dreistellig steigen, während am Code nichts Besonderes passiert, und es kann ebenso schnell wieder fallen. Wer die Gesundheit von Eliza messen will, schaut nicht auf den Chart, sondern auf Commits, Pull Requests und die Zahl der Entwickler, die bleiben.

Wer pflegt ein Projekt ohne Stiftung?

Hier beginnt die eigentlich interessante Frage von 2026. Ein Open-Source-Projekt dieser Größe verursacht laufende Kosten, auch wenn der Quelltext gratis ist. Jemand muss Sicherheitslücken schließen, Abhängigkeiten aktualisieren, Audits bezahlen, ein Bug-Bounty-Programm betreiben, Pull Requests prüfen und die Richtung vorgeben. In der klassischen Krypto-Welt übernimmt das eine Stiftung, finanziert aus einer Token-Kasse. Genau diese Kasse ist bei Eliza leer, die Stiftung existiert nicht mehr, der Token taugt nicht als Anreiz.

Das Problem ist nicht neu, nur verschärft. Ein großer Teil der digitalen Wirtschaft läuft auf quelloffener Infrastruktur, die von einer Handvoll schlecht oder gar nicht bezahlter Freiwilliger gepflegt wird; die Lücken Heartbleed in OpenSSL und Log4Shell in Log4j haben vorgeführt, was passiert, wenn kritischer Code chronisch unterfinanziert ist. Bei einem KI-Agenten-Framework wiegt das schwerer als bei einer Bibliothek, die nur Text formatiert. Ein Eliza-Agent hält im Zweifel eine Wallet mit echten Mitteln. Eine ungepatchte Lücke ist dann keine abgestürzte Website, sondern abgeflossenes Geld.

Dazu kommt die Haftungsfrage, die in Deutschland besonders scharf gestellt wird. Wer trägt die Verantwortung, wenn ein Agent, gebaut auf einem Framework ohne Betreiber, einen Schaden anrichtet? Die Antwort betrifft Entwickler unmittelbar, und die Grenze zwischen dem bloßen Veröffentlichen von Code und strafbarem Handeln ist alles andere als eindeutig, wie unser Beitrag Code vor Gericht: Wann DeFi-Entwickler strafbar werden im Detail zeigt.

Walters’ struktureller Ausweg lautet: Er besitzt das geistige Eigentum, entwickelt unter eigener Kontrolle weiter, verzichtet auf einen Token. Das beseitigt den Interessenkonflikt zwischen Kurspflege und Code-Pflege, verlagert das Problem aber nur. Ein von einer Person kontrolliertes Projekt hängt am fortgesetzten Interesse dieser Person und an einer einzigen Finanzierungsquelle. Woher soll das Geld kommen? Walters’ Antwort darauf heißt Slop Cash.

Slop Cash: Code finanzieren ohne eigenen Token

Slop Cash ist ein nicht-verwahrender Finanzierungsmechanismus für quelloffene Software, gebaut von Walters zusammen mit Drew Pierson, der zuvor bei Arweave, Orderly Network und Ava Labs tätig war. Die Grundidee ist radikal einfach: Bezahlt wird nur für Arbeit, die tatsächlich im Code landet. Slop Cash bewertet akzeptierte Pull Requests und Code-Reviews nach einem deterministischen, öffentlich nachvollziehbaren Verfahren, friert das Monatsergebnis in einem Vorschlag ein, lässt ein 14-Tage-Fenster für Einsprüche und zahlt dann in USDC aus. Entscheidend: Die Auszahlungen laufen über Wallets, die Slop Cash nicht selbst kontrolliert, und nicht über einen projekteigenen Spekulations-Token. Bezahlt werden kann im Übrigen nicht nur ein Mensch, sondern auch ein KI-Agent, der Code beisteuert.

Die bisherigen Zahlen sind überschaubar, aber real. Laut der Ankündigung über Chainwire hat Slop Cash seit Juli 2026 drei Monatszyklen abgerechnet, rund 10.000 gemergte Pull Requests bewertet und 4.700 Code-Reviews erfasst; allein im August-Zyklus des elizaOS-Pools waren 108 Mitwirkende aktiv. Die erste Auszahlung im September belief sich auf 6.005 USDC, verteilt über 72 Überweisungen, öffentlich einsehbar. Das ist kein Gehalt, von dem man in München leben könnte, aber es ist ein Anfang und, wichtiger, ein überprüfbarer Mechanismus.

Die ehrliche Nuance steckt in der Ebene darüber. Slop Cash ist rechtlich als abgeschirmtes Teilvermögen der Plattform Umia aufgehängt, einer On-Chain-Plattform zum Starten, Finanzieren und Steuern von Projekten. Umia selbst hat laut The Block in einer siebentägigen Auktion 6,11 Millionen US-Dollar eingesammelt, bei einer vollständig verwässerten Bewertung von 18 Millionen US-Dollar und mit zehn Fonds sowie knapp 700 Einzelbietern. Geführt wird Umia von Francesco Mosterts, zuvor beim Hedgefonds Point72. Und ein eigener Token für Slop Cash, $SLOP, ist für das vierte Quartal 2026 geplant, über eine sogenannte Tailored Auction auf der Robinhood Chain.

Damit wird die Lage ehrlicher, als es die Überschrift „Framework ohne Token“ vermuten lässt. Das Eliza-Framework bleibt tokenlos, die Entwickler bekommen USDC. Aber die Finanzierungs- und Steuerungsschicht darüber arbeitet sehr wohl mit Token. Die Pointe von 2026 ist nicht, dass Token verschwunden wären, sondern dass sie eine Ebene nach oben gewandert sind, weg vom Produkt, hin zur Finanzierung. Mosterts begründet das mit genau dem Fehlanreiz, der Eliza das Genick brach: „A liquid token can push teams toward short-term decisions aimed at increasing its price“, ein handelbarer Token verleite Teams zu kurzfristigen Entscheidungen, die allein den Kurs treiben sollen.

Die Architektur unter der Haube

Wer auf Eliza baut oder nur verstehen will, wo die Angriffsfläche liegt, muss vier Begriffe kennen. Im Zentrum steht die Laufzeit, die AgentRuntime. Sie ist der Taktgeber: Sie nimmt eine Eingabe entgegen, sammelt Kontext, ruft das Sprachmodell, führt die beschlossene Handlung aus und schreibt das Ergebnis ins Gedächtnis zurück. Alles andere hängt an dieser Schleife.

Die Identität eines Agenten steckt in der Character-Datei, einer strukturierten Beschreibung von Name, Biografie, Tonfall, Wissen und Beispieldialogen. Diese Datei macht aus dem generischen Framework einen konkreten Agenten, vom nüchternen DeFi-Verwalter bis zur schlagfertigen Chat-Persönlichkeit. Sie ist zugleich der Ort, an dem viele Projekte ihre gesamte Persönlichkeit definieren, und, wie wir noch sehen werden, ein lohnendes Ziel für Angreifer.

Darum herum arbeiten drei Bausteintypen. Actions sind die Fähigkeiten, das, was ein Agent tun kann, etwa eine Transaktion senden, eine Schnittstelle abfragen, einen Beitrag posten. Providers speisen laufend Kontext ein, von der Uhrzeit über Kontostände bis zu externen Datenfeeds. Evaluators laufen nach einer Interaktion, extrahieren Fakten, ziehen Schlüsse und aktualisieren das Gedächtnis. Und die Memory-Schicht, meist eine Vektordatenbank, speichert vergangene Interaktionen, damit der Agent über Sitzungen hinweg konsistent bleibt.

Für komplexere Szenarien kennt Eliza zusätzlich die Abstraktionen Worlds, Rooms und Entities, mit denen sich mehrere Agenten, Kanäle und Nutzer sauber trennen lassen, etwa wenn ein Agent gleichzeitig auf Discord, X und in einem Spiel präsent ist. Das klingt nach viel Maschinerie, bleibt aber ein gewöhnliches TypeScript-Programm. Genau diese Nähe zum normalen Code macht Eliza für Entwickler zugänglich und erklärt einen Teil seiner Verbreitung.

Plugins und Interoperabilität als Burggraben

Der eigentliche Wert eines Frameworks liegt selten im Kern, sondern in dem, was sich daran anstecken lässt. Hier hat Eliza seinen Burggraben. Es gibt eine einzige, einheitliche Plugin-Schnittstelle, und darum herum ist über die Jahre ein großes Ökosystem gewachsen. Walters spricht von mehr als 250 Plugins und betont die Unterstützung für das Model Context Protocol (MCP). Ein Plugin kann eine Blockchain-Anbindung sein, ein Börsenkonnektor, ein Sprach- oder Bildmodell, ein Spiele-Adapter. Wer einen Agenten baut, muss das Rad nicht neu erfinden, sondern steckt zusammen, was er braucht.

Parallel hat sich das Repository vom einzelnen Framework zu einer Plattform ausgewachsen. Die Paketstruktur reicht vom Kern über Agent, Cloud, Auth und Training bis zu Betriebssystem-, Benchmark-, App- und UI-Komponenten. Das ist weniger eine Bibliothek als ein Baukasten für den gesamten Lebenszyklus eines Agenten. Dass dieses Ökosystem auch nach dem Tod des Tokens weiterwächst, ist das stärkste Argument für Walters’ These, dass der Code den Token nicht braucht.

Entscheidend für die Zukunftsfähigkeit ist die Interoperabilität. Eliza setzt nicht auf einen eigenen, geschlossenen Standard, sondern auf die offenen Protokolle, die sich 2026 im Agenten-Stack herausbilden. Vier davon sollte man kennen; sie entscheiden darüber, ob Agenten verschiedener Hersteller miteinander reden, bezahlen und einander vertrauen können.

Diese Standards sind der Grund, warum Eliza auch ohne eigenen Token im Spiel bleibt. Ein Framework, das die gängigen Protokolle spricht, ist ein Knotenpunkt, kein Inselprojekt. Es kann Agenten bauen, die über A2A mit fremden Agenten verhandeln, über x402 bezahlen und sich über ERC-8004 ausweisen. Der Wert liegt in der Anschlussfähigkeit, nicht im Spekulationsobjekt.

Die Gaming-Wette: Agenten, die spielen

Für ein Krypto- und Gaming-Medium ist der interessanteste Zweig der Eliza-Geschichte ohnehin nicht die Finanz-Autonomie, sondern das Spiel. Walters verfolgt die Idee, dass Spiele der beste Trainingsplatz für Agenten sind, die später echte Arbeit erledigen. Das sichtbarste Projekt in dieser Richtung ist ein KI-natives MMORPG, das sich seit Monaten in Entwicklung befindet und auf einer angepassten 3D-Engine aufsetzt. Menschen und von Eliza gesteuerte Agenten sollen darin denselben Spielraum bewohnen, kämpfen, Ressourcen sammeln und Fähigkeiten wie Holzfällen, Bergbau oder Fischen ausüben.

Wichtig zur Einordnung, gerade weil die Szene gern vorgreift: Dieses Spiel ist nicht veröffentlicht, es ist ein Entwicklungsprojekt. Was Walters liefert, ist bislang vor allem eine ökonomische These. In einem Interview mit BlockchainGamer.biz rechnet er vor: „it’s going to cost us $80,000 to make a game that cost them $6,000,000, and we can make it in four months“, ein Spiel, das andere Millionen koste, lasse sich mit KI für einen Bruchteil und in vier Monaten bauen. Das ist eine Behauptung über die Zukunft, kein Kassensturz.

Hinter der Zuspitzung steckt dennoch ein ernster Gedanke. Ein MMORPG ist eine kontrollierte, regelbasierte Welt mit klaren Zielen und messbarem Erfolg, also eine ideale Umgebung, um Agenten planen, handeln und mit anderen koordinieren zu lassen. Wer einen Agenten bauen kann, der in einem Spiel überlebt und Ressourcen verwaltet, hat die Grundbausteine für einen Agenten, der in der realen Wirtschaft Aufgaben übernimmt. Walters’ Formel, sinngemäß: Spielen ist der Weg zu Agenten, die echte Arbeit tun.

Für Eliza ist das zudem eine Positionierung abseits des verbrannten Finanz-Images. Der KI-Fonds endete vor Gericht; ein offenes Spielframework mit autonomen Mitspielern erzählt eine andere, freundlichere Geschichte und trifft genau die Schnittmenge aus Krypto und Gaming, auf der 2026 viel Aufmerksamkeit liegt. Ob daraus ein Produkt wird, ist offen. Als strategische Wette ist sie nachvollziehbar.

Das Sicherheitsproblem: Wallet, Prompt- und Memory-Injection

Sobald ein Agent eine eigene Wallet kontrolliert, wird jede seiner Schwächen zu einem finanziellen Risiko. Der Kern des Problems ist prinzipieller Natur und betrifft nicht nur Eliza, sondern jedes LLM-gestützte System: Das Modell kann Anweisung und Daten nicht zuverlässig voneinander trennen. Alles, was in seinen Kontext gelangt, ein Chat, ein Social-Media-Beitrag, ein abgerufenes Dokument, kann als Befehl gelesen werden. Setzt ein Agent am Ende noch blind seine Signatur unter eine Transaktion, schließt sich die Kette vom manipulierten Text bis zum abgeflossenen Geld.

Der klassische Angriff heißt Prompt Injection und steht nicht ohne Grund auf Platz eins der OWASP-Risikoliste für LLM-Anwendungen. Die gefährlichere Variante hat ein Forschungsteam unter dem Namen Real AI Agents with Fake Memories beschrieben, ein Benchmark namens CrAIBench, der gezielt Web3-Agenten angreift. Das zentrale Ergebnis: „AI models are significantly more vulnerable to memory injection compared to prompt injection“, Modelle sind für die Vergiftung des Gedächtnisses deutlich anfälliger als für den einmaligen Prompt-Angriff. Schiebt ein Angreifer eine falsche Erinnerung in die Memory-Schicht, wirkt sie fort, lange nachdem der ursprüngliche Angriff vorbei ist. Pikant: ElizaOS dient der Studie ausdrücklich als repräsentatives Framework, geprüft an über 150 Blockchain-Aufgaben und mehr als 500 Angriffsfällen.

Das ist keine Theorie. Im Mai 2026 wurde ein Agent über eine Kombination aus versteckter Anweisung (unter anderem in Morse-Code in einer X-Antwort) und einer geschenkten NFT, die Transferrechte freischaltete, dazu gebracht, Token in sechsstelliger Höhe zu verschieben. Parallel warnte Microsoft in seinem Security-Blog, dass Prompt Injection in Agenten-Frameworks bis zur Remote Code Execution eskalieren kann: „vulnerabilities in the AI layer are no longer just a content issue and are an execution risk“, Schwachstellen in der KI-Schicht seien kein reines Inhaltsproblem mehr, sondern ein Ausführungsrisiko (Microsoft Security, mit zwei konkreten CVE-Einträgen). Benannt wurden dort Frameworks wie Semantic Kernel, LangChain und CrewAI, nicht Eliza; die Klasse der Lücke betrifft aber jedes Agenten-Framework gleichermaßen.

Autonomie gegen Sicherheit: der ungelöste Zielkonflikt

Gegen diese Angriffe gibt es Gegenmaßnahmen, nur haben sie einen Preis. Vitalik Buterin hat die gängige Linie in seinem Blog zusammengefasst: Inferenz möglichst lokal ausführen, alles strikt in einer Sandbox kapseln, autonome Transaktionen deckeln (als groben Richtwert nennt er etwa 100 US-Dollar pro Tag) und Mensch und Modell als Zwei-Faktor-Freigabe koppeln (vitalik.eth.limo). Seine Warnung unterfüttert er mit einer unbequemen Schätzung: Ein beträchtlicher Teil der angebotenen Agenten-Fähigkeiten trage bereits bösartige Anweisungen in sich.

Das Dilemma ist offensichtlich. Jede dieser Maßnahmen beschneidet genau die Autonomie, die ein Agent eigentlich verkaufen soll. Ein Agent, der für jede Transaktion über 100 US-Dollar eine menschliche Freigabe braucht, ist kein autonomer Akteur mehr, sondern ein besserer Assistent mit Bestätigungsknopf. Mehr Sicherheit bedeutet weniger Autonomie, und umgekehrt. Dieser Zielkonflikt ist 2026 ungelöst, und er ist der Grund, warum selbst Enthusiasten zur Vorsicht raten.

Walters selbst, der Mann, der das wohl bekannteste Agenten-Framework gebaut hat, formuliert es im Gespräch mit Decrypt verblüffend klar: „You probably do not want to give an AI agent a bunch of money and expect it to make you more“, man wolle einem KI-Agenten vermutlich nicht einfach viel Geld anvertrauen in der Erwartung, er mehre es. Aus dem Mund des Gründers ist das weniger Resignation als Realismus über den Stand der Technik.

Ein verbreitetes Missverständnis gehört hier ausgeräumt. Verfahren für verifizierbares Rechnen, also kryptografische oder hardwaregestützte Beweise, dass ein bestimmtes Modell eine bestimmte Rechnung korrekt ausgeführt hat, lösen das Injektionsproblem nicht. Sie beweisen, dass die Rechnung integer war, nicht, dass die Eingabe sauber war. Ein Agent kann nachweislich korrekt rechnen und trotzdem einem vergifteten Kontext folgen. Wie solche Beweise technisch in einen Smart Contract kommen, zeigt unser Beitrag zu Rituals Architektur für verifizierbare KI; und wo die Rechenleistung dafür günstig herkommt, beleuchtet unsere Analyse zum Comeback der dezentralen GPUs bei Akash. Beide adressieren die Integrität der Berechnung, nicht die Sauberkeit der Eingabe.

Die Konkurrenz: Eliza im Framework-Wettbewerb

Eliza ist 2026 nicht allein. Der Sektor der KI-Agenten bringt es laut CoinGecko auf eine Marktkapitalisierung von rund 3,82 Milliarden US-Dollar, angeführt vom Venice-Token (VVV) mit rund 1,35 Milliarden US-Dollar. Der direkteste Rivale als Framework und Startrampe ist Virtuals Protocol auf Base und Solana, eine No-Code-Plattform mit nach eigenen Angaben rund 15.800 Projekten; der zugehörige VIRTUAL-Token ist mit rund 463 Millionen US-Dollar bewertet und damit, anders als ELIZAOS, quicklebendig. Dazu kommen die Artificial Superintelligence Alliance (FET) und auf der Zahlungsseite spezialisierte Ketten wie Kite.

Jenseits von Krypto konkurriert Eliza mit einer ganz anderen Liga: LangChain, CrewAI, Microsofts Semantic Kernel und weitere Frameworks, die keinen Token kennen und aus der klassischen Softwarewelt kommen. Für einen Entwickler, der schlicht einen zuverlässigen Agenten bauen will, sind das echte Alternativen. Elizas Alleinstellung liegt in der Web3-Nähe: direkte Wallet- und Smart-Contract-Anbindung, das größte kryptonahe Plugin-Ökosystem und der Anspruch, ein vollständiges Betriebssystem für Agenten zu sein, nicht nur eine Bibliothek.

Die Schwächen sind die Kehrseite der Geschichte dieses Textes. Ohne Token-Kasse fehlt das Kriegsgeld, mit dem Konkurrenten Audits, Entwickler und Marketing bezahlen. Die Kontrolle durch eine Person ist Stärke (klare Richtung, kein Kurszwang) und Risiko (Abhängigkeit von Schlüsselpersonen) zugleich. Und die Sicherheitsdecke, das Memory-Injection-Problem, teilt Eliza zwar mit allen, trägt es aber als namentlich untersuchtes Beispiel mit einem Reputationsrisiko.

BaFin, MiCA und die Steuer: der Rahmen für deutsche Nutzer

Wer von Deutschland aus mit Eliza-Agenten arbeitet, sollte drei Ebenen auseinanderhalten: Aufsicht, Haftung und Steuer. Bei der Aufsicht gilt der Grundsatz, den die BaFin in ihrem Merkblatt zu Kryptowerte-Dienstleistungen festhält: Reguliert werden Dienstleister und Emittenten (die CASPs unter MiCA), nicht das Protokoll oder das Framework an sich. Ein quelloffenes Stück Software wie Eliza ist kein beaufsichtigtes Finanzprodukt. Sobald aber jemand damit eine erlaubnispflichtige Dienstleistung anbietet, etwa Verwahrung oder Handel für Dritte, greift die MiCA-Lizenzpflicht, deren Übergangsfrist in Deutschland am 1. Juli 2026 endete.

Die Haftungsfrage ist für Agenten besonders heikel, weil ein KI-Agent keine Rechtspersönlichkeit besitzt. Er kann nicht klagen, nicht verklagt werden, hat keine Steuernummer. Verursacht er einen Schaden, fällt die Verantwortung auf einen Menschen oder ein Unternehmen zurück, auf denjenigen, der den Agenten einsetzt, konfiguriert oder betreibt. Berät ein Agent bei der Geldanlage oder verwaltet er ein Portfolio, kann zudem MiFID II greifen, nicht MiCA, denn Anlageberatung ist eine Wertpapierdienstleistung.

Steuerlich behandelt das deutsche Recht Krypto-Gewinne als privates Veräußerungsgeschäft nach Paragraf 23 EStG, Kryptowerte gelten als anderes Wirtschaftsgut. Nach einem Jahr Haltefrist ist ein Gewinn steuerfrei, davor bis zum persönlichen Satz von bis zu 45 Prozent plus Soli steuerpflichtig, mit einer Freigrenze von 1.000 Euro und der FIFO-Methode. Für Agenten hat das eine unangenehme Pointe: Jede Zahlung, die ein Agent in einem Dollar-Stablecoin leistet, ist potenziell eine Veräußerung, tausende Mikrozahlungen werden zu tausenden steuerlich relevanten Vorgängen. Und 24/7 laufender, hochfrequenter Handel kann als gewerblich eingestuft werden, was die Einjahresfrist aushebelt. Was dabei an der Jahresgrenze zu beachten ist, führt unser Beitrag zum Stichtag 31. Dezember und der Bestandsschutz-Falle aus.

Ein letzter Punkt betrifft die Kasse der Finanzierungsschicht. Slop Cash zahlt in USDC, einem unter MiCA als E-Geld-Token eingeordneten Stablecoin. Wer solche Mittel über regulierte Börsen oder Verwahrer bewegt, stößt auf Identitäts- und Geldwäscheprüfungen, deren Ernsthaftigkeit in der Praxis schwankt; wie löchrig eine nur auf dem Papier existierende KYC-Prüfung sein kann, zeigt der Fall OKX und die 504-Millionen-Dollar-Strafe. Für ein tokenloses Framework ist das vor allem ein Hinweis darauf, dass die Regulierung an den Ein- und Ausstiegspunkten ansetzt, nicht am Code.

Ausblick: Was 2027 über Eliza entscheidet

Eliza ist 2026 ein Test, an dem sich eine größere Frage entscheidet: Lässt sich in der Krypto-KI die nützliche Software vom spekulativen Token trennen? Vier Dinge sind im kommenden Jahr zu beobachten. Erstens, ob die $SLOP-Auktion im vierten Quartal gelingt und das tokenlose Finanzierungsmodell tatsächlich genug Geld in die Entwicklung spült, oder ob es beim symbolischen Anfang bleibt. Zweitens, ob die seit Langem angekündigten Rust- und Python-Varianten endlich als fertiges Produkt erscheinen; bis heute sind sie im Kern nicht sichtbar.

Drittens, ob aus der Gaming-Wette ein spielbares Produkt wird, nicht nur ein Repository mit Versprechen. Und viertens, die eigentliche Nagelprobe, ob das Memory-Injection-Problem spürbar entschärft werden kann, ohne die Autonomie vollends zu kastrieren. Gelingt das niemandem, bleibt die ehrlichste Anwendung eines Agenten auf absehbare Zeit die mit engem menschlichem Zügel.

Die Antwort auf die Titelfrage, Leben nach dem Token, fällt vorsichtig optimistisch aus. Der Code lebt messbar, am GitHub-Puls, am Plugin-Ökosystem, an einem Finanzierungsmechanismus, der zumindest existiert. Was fehlt, ist der Beweis, dass dieses Leben sich selbst trägt, über Jahre, gegen token-finanzierte Konkurrenz, unter dem Damoklesschwert der Sicherheitslücken. Walters hat die Wette aufgemacht, dass Qualität ohne Kursfantasie genügt. 2027 wird zeigen, ob sie aufgeht.

Fürs Erste gilt die nüchterne Doppelbotschaft, mit der dieser Text begann. Der Token von Eliza ist tot, daran ändert kein Oktober-Zucken etwas. Der Code lebt, daran ändert die leere Kasse nichts. Wer das Projekt bewerten will, sollte aufhören, auf den Chart zu starren, und anfangen, den Commits zu folgen.

Häufig gestellte Fragen

Ist der ELIZAOS-Token tot?

Ja. Gründer Shaw Walters hat den Token im August 2026 öffentlich für tot erklärt, es gibt keine Stützungskäufe, keine Angebotskürzungen und keinen Ersatz-Token. Der Kurs liegt rund 96 Prozent unter dem Allzeithoch, bei einer Marktkapitalisierung von nur noch rund 3 Millionen US-Dollar. Das quelloffene Framework dagegen wird unabhängig vom Token weiterentwickelt.

Was ist das Eliza-Framework (ElizaOS)?

Eliza, auch ElizaOS, ist ein quelloffenes TypeScript-Framework zum Bau autonomer KI-Agenten mit Web3-Anbindung. Ein Agent nutzt ein Large Language Model als Denkapparat, besitzt Gedächtnis und Fähigkeiten und kann eigene Blockchain-Transaktionen signieren. Das Projekt versteht sich heute als Betriebssystem für Agenten und ist unter der MIT-Lizenz auf GitHub verfügbar.

Wer finanziert ElizaOS, seit der Token weg ist?

Die Entwicklung läuft über Slop Cash, einen nicht-verwahrenden Mechanismus von Walters und Drew Pierson, der Beiträge nur für tatsächlich gemergten Code in USDC bezahlt. Die Finanzierungs- und Steuerungsschicht darüber, die Plattform Umia, arbeitet allerdings sehr wohl mit Token; das Framework selbst bleibt tokenlos, die Token sind eine Ebene nach oben gewandert.

Ist ein Eliza-KI-Agent mit eigener Wallet sicher?

Nur mit klaren Grenzen. Der Kern des Risikos ist, dass ein Sprachmodell Anweisung und Daten nicht zuverlässig trennt; besonders gefährlich ist laut der Studie CrAIBench die Memory Injection, das dauerhafte Vergiften des Gedächtnisses. Experten raten zu lokaler Ausführung, strikter Sandbox, Ausgabenlimits und menschlicher Freigabe, was die Autonomie des Agenten allerdings einschränkt.

Wie werden Gewinne mit KI-Agenten in Deutschland besteuert?

Krypto-Gewinne gelten als privates Veräußerungsgeschäft nach Paragraf 23 EStG. Nach einem Jahr Haltefrist sind sie steuerfrei, davor bis zum persönlichen Satz von bis zu 45 Prozent steuerpflichtig, mit einer Freigrenze von 1.000 Euro. Jede Stablecoin-Zahlung eines Agenten kann eine Veräußerung sein, und hochfrequenter Dauerbetrieb riskiert die Einstufung als gewerblich.

Von Marcus Okafor, Senior Editor bei HOGE Wire, Ressort Krypto und KI.