Eliza Framework in 2026: The Agent OS and Its Gaming Bet
Seven weeks after its token died, the Eliza framework keeps shipping and now calls itself an operating system. Can an agent OS that can be gaslit out of its wallet grow up?
The token died. The code did not.
On August 4, 2026, Eliza Labs founder Shaw Walters posted four words that closed the loudest chapter in crypto-AI: “The token is dead. Completely.” He had just settled a class action by handing the project foundation’s remaining treasury to token holders, and he said the foundation itself was winding down. Seven weeks later, the market agrees. ELIZAOS changes hands around $0.000168, a market value near $1.26 million and a rank outside the top 2,800 coins, sitting only a sliver above a fresh record low near $0.000147, according to CoinGecko. A token that once carried a roughly $2.4 billion market value in early 2025 is now a rounding error.
And yet the thing the token was supposed to fund is very much alive. The main elizaOS/eliza repository carries 19.4k stars, 5.8k forks, and hundreds of open pull requests, with commits still landing in mid-September. Its one-line description no longer reads like a chatbot library. It reads: “Your agentic operating system.” That is the story worth telling in the autumn of 2026, and it is not another obituary for a dead memecoin. It is the question of whether a framework can outgrow the token that made it famous, and whether the second act its creator has chosen, an operating system for autonomous agents that he wants to prove out inside a video game, is a real plan or a founder’s way of coping.
This piece walks through where the Eliza framework actually stands now: the technology, the operating-system pitch, the gaming bet, the security research that shadows all of it, who is left maintaining the code, and where United States regulators sit relative to software that signs its own transactions.
From an a16z in-joke to a $2.4 billion crater
The origin is by now well worn, so keep it short. In October 2024, a developer using the handle Shaw launched a token called ai16z on Solana through the daos.fun launchpad, pitching a community fund steered by an AI persona modeled on venture capitalist Marc Andreessen. The real Andreessen tweeted “GAUNTLET THROWN,” and the market cap ran to nearly $100 million within hours. Two agent personas anchored the pitch: a measured “AI Marc” meant to manage the fund, and an aggressive “Degen Spartan AI.”
The market cap peaked near $2.4 billion in early January 2025. Later that month the project rebranded to ElizaOS after a16z asked it to stop trading on the firm’s name. A token migration from AI16Z to ELIZAOS followed in November 2025. Then came the reckoning: in April 2026, Burwick Law filed a class action in the Southern District of New York on behalf of a Spanish holder, Gorka Pikabea, alleging the project had misrepresented its autonomy and misused the a16z name (docket 1:26-cv-03238). Walters settled in August by giving holders what was left, then declared the token dead. The framework, he insisted, would continue.
| Date | Milestone |
|---|---|
| Oct 2024 | ai16z launches on daos.fun; Andreessen tweets “GAUNTLET THROWN” |
| Jan 2025 | Peak market value near $2.4 billion; rebrand to ElizaOS begins |
| Nov 2025 | Token migration from AI16Z to ELIZAOS |
| Apr 2026 | Burwick Law files the Pikabea class action (SDNY) |
| Aug 4, 2026 | Walters settles the suit and calls the token dead; foundation winds down |
| Sep 2026 | ELIZAOS near a record low; framework still shipping on GitHub |
What the Eliza framework actually is
Strip away the token and Eliza is a TypeScript framework for building autonomous agents. At its center is a runtime, the AgentRuntime, that loads a character file (a JSON-like definition of an agent’s persona, goals, and knowledge) and wires it to models, memory, and tools. Everything an agent can do plugs into that runtime through a single plugin interface, and the framework organizes behavior into four primitives: Actions (things the agent can do, like send a transaction), Providers (context the agent reads before deciding), Evaluators (post-processing that can write conclusions back to memory), and Services (long-running connections such as a Discord or exchange client).
Around that sit a long-term memory store with retrieval-augmented recall, a messaging model built from Worlds, Rooms, and Entities, and a pluggable set of model providers with a deliberate local-first option so an agent does not have to depend on a single cloud API. None of this is exotic on its own. Eliza’s real contribution was making the wiring boringly repeatable. A command-line tool scaffolds a new project, plugins install from a public registry and register themselves with the runtime at startup, and the same character file can drive an agent on Discord, on X, or inside a trading loop with no rewrite. Spinning up an agent with a wallet, a personality, and a dozen integrations became a weekend project rather than a research effort. That accessibility is exactly why it became the most-forked agent stack in crypto, and also why its security profile matters far beyond one dead token.
The mental model is simple: an agent is a brain (the language model), a memory, a pair of hands (the plugins and tools), and, in crypto, a wallet. Get those four pieces talking and you have something that can plan, remember, act, and pay. Get the trust boundaries between them wrong and you have something that can be talked into emptying that wallet.
The “agentic operating system” bet
The word that keeps appearing now is “operating system.” The repository describes itself that way, and Walters talks about the project as infrastructure rather than a chatbot toolkit. In a 2026 interview he put the ambition plainly: “We probably have the most complete end-to-end framework. If you need an agent to do a thing, we have it,” adding, “We have over 250 plugins, obviously MCP support and all this stuff. Now we’re coming out with Eliza in Rust and Python,” per BlockchainGamer.biz.
What does “operating system” mean for software agents? Roughly this: a base layer that agents run on top of, bundling a runtime, a permission and plugin model, persistent memory, model routing, and a wallet, so that any given agent is an application rather than a bespoke script. Support for the Model Context Protocol lets agents reach external tools through a common standard, and the move toward a Rust core with Python and TypeScript bindings is a bid to be embeddable anywhere, from a browser tab to a server to a game client. That is a serious engineering direction, and the 250-plugin count is real evidence the ecosystem is broad.
The skepticism is equally fair. Calling yourself an operating system is a positioning claim, not a fact on the ground. Today the substance is a mature TypeScript runtime, a large plugin registry, and an in-progress rewrite, not a stable multi-language platform with the reliability guarantees the word “OS” implies. The bet is that agents become a durable software category and that the base layer for that category is worth owning. Whether Eliza is that layer is unproven, and the dead token makes the usual funding path for such a bet unavailable.
Why Eliza is chasing a video game
The most revealing part of Eliza’s second act is where Walters wants to test it. Not a trading desk, not a customer-service queue, but a game world. A repository under the PlayHyperia banner describes an MMORPG for humans and agents, in development, powered by ElizaOS. The game, Hyperia, is built on a customized version of the open-source 3D engine Hyperfy, and its distinguishing feature is that autonomous agents play alongside people: they fight, train skills, and trade, driven by language-model reasoning rather than scripted behavior, with a spectator mode that lets you watch an agent think.
Walters has been direct about why. “I think that playing games is the path to agents that do the real work,” he said, describing the goal, only half-joking, as an “AI RuneScape.” The logic is better than it first sounds. A persistent game world is an economy with scarcity, an adversarial environment full of other agents and griefers, and, crucially, a place where every action is observable and reversible enough to learn from. If an agent can hold its own in a world where other agents are trying to outcompete it, the argument goes, the same runtime can eventually manage a treasury or run a supply chain. For a publication that covers both crypto and games, this is the most interesting claim Eliza is making, and it slots neatly beside the on-chain economies that already blur the line between play and finance.
It is also unproven. The game is still in development, not launched, and a spectator-mode demo of agents grinding a skill tree is a long way from evidence that language models can be trusted with money. The gaming bet is a thesis with a GitHub repo attached, not a result. But it is a thesis, which is more than most surviving agent projects can say.
The security ceiling: agents that can be gaslit
Every ambition above runs into the same wall, and it happens to be documented most thoroughly on Eliza itself. In a paper titled “Real AI Agents with Fake Memories: Fatal Context Manipulation Attacks on Web3 Agents,” Princeton researchers working with the Sentient Foundation built CrAIBench, a benchmark of more than 150 realistic blockchain tasks and over 500 attack cases, using ElizaOS as the representative framework. Their headline finding is uncomfortable: AI models are significantly more vulnerable to memory injection than to prompt injection. Poison what an agent remembers, and it will act on the poison later, even when the live prompt looks clean.
The distinction matters because most defenses are aimed at the wrong door. Prompt injection is the attack everyone knows: hide an instruction in the text an agent reads and hope it obeys. Memory injection is quieter. An attacker writes a corrupted entry into the agent’s long-term store, perhaps through a fake social post the agent ingests, and that false memory is trusted on every future run. Decrypt summarized the research bluntly, describing how the vulnerability lets an agent be gaslit into losing millions. The researchers found that state-of-the-art prompt-based defenses do little once stored context is corrupted; fine-tuning the model against these attacks helped on single-step tasks but degraded on the multi-step chains that make agents useful in the first place.
| Attack vector | How it works | Relevance to Eliza-style agents |
|---|---|---|
| Prompt injection | Malicious instruction hidden in live input the model treats as a command | OWASP LLM01; partly defensible with filtering and guardrails |
| Memory injection | Poisoned entry written to the agent’s long-term store, trusted on later runs | CrAIBench found models more vulnerable here than to prompt injection |
| Plugin supply chain | A malicious or compromised plugin inherits the agent’s permissions | 250-plus plugins widen the surface; registry forks add attestation |
| Privilege escalation | A gift or grant unlocks rights the agent then abuses | The Grok/Bankr drain, non-Eliza but the same class of failure |
The wallet is the whole ballgame
Why does a context trick become a financial loss? Because the model sits behind a wallet, and the model cannot reliably tell an instruction from data. A language model reads everything in one stream: your command, the web page it fetched, the memory it recalled, the reply someone posted. If any of that says “transfer the funds,” the agent may sign. This is the same trust-boundary problem that haunts hardware-wallet users who approve a transaction they do not fully understand, except an agent approves at machine speed and never gets suspicious.
The wallet layer is not helpless. An agent’s wallet is increasingly a smart account rather than a raw key, which means it can carry rules, spending limits, and session keys that scope what a given agent process is allowed to do. Readers who want the mechanics can see our smart-account field guide, and the way delegated permissions interact with adversaries is exactly the surface explored in our look at EIP-7702 and MEV. Scoping helps. It does not solve the core issue, because a scoped agent that gets injected still does the wrong thing inside its allowance.
The canonical real-world example is not an Eliza agent, but it is the same failure. On May 4, 2026, an attacker drained a Grok-powered Bankr agent of roughly $175,000 of tokens on Base by hiding an instruction in Morse code inside a reply and gifting an NFT that unlocked transfer rights, a textbook combination of OWASP’s LLM01 (prompt injection) and LLM06 (excessive agency). The lesson repeats across crypto in 2026, from bridge exploits such as the Liquid Network hack to agent drains: value moves the instant something with signing authority is convinced to move it, whether that something is a compromised key or a gullible model.
The fixes on offer, and what they miss
The most cited response comes from Ethereum co-founder Vitalik Buterin, who has argued that agents should be boxed in by default. In an April 2026 essay he reduced it to three rules: “All LLM inference local first. All files hosted locally. Sandbox everything.” He has also floated capping an agent’s autonomous spending to a modest daily figure and treating a human signer as a mandatory second factor above that limit, so that a compromised agent can lose lunch money but not the treasury. These are blast-radius controls, and they are sane. They also blunt the autonomy that makes agents worth building, which is the unresolved tension at the center of the whole field.
The other camp is verifiable compute, and Eliza’s ecosystem has leaned into it. Automata Network maintains an Eliza plugin using Intel DCAP remote attestation, so an agent can prove it is running the expected code inside a trusted execution environment, and infrastructure teams including a major Ethereum client shop keep their own plugin-registry forks. Beyond hardware, fraud-proof (opML) and validity-proof (zkML) systems, along with training-focused projects like those we covered in the decentralized AI training race, aim to make model execution checkable rather than trusted.
Here is the nuance that too many pitches skip: verifiable compute proves that a computation ran as specified. It says nothing about whether the instruction was legitimate. A cryptographic proof that an agent faithfully executed a poisoned memory is still a proof of the wrong thing. Attestation and proofs shrink the trust you place in operators and hardware; they do not close the injection gap. That gap is a property of how language models read the world, and no proof system fixes it.
| Approach | What it proves | What it does not stop |
|---|---|---|
| Local-first plus spend caps | Limits blast radius; human as second factor | The injection itself; the agent still misbehaves within limits |
| TEE attestation (Automata DCAP) | Code and hardware integrity and confidentiality | A correctly running agent still obeys a poisoned instruction |
| opML / zkML proofs | The stated model produced the stated output | Whether the instruction the model followed was legitimate |
| Fine-tuning defenses | Lower attack success on single-step tasks | Multi-step chains, where robustness degrades |
Who maintains a framework with no foundation?
Open-source projects usually die of neglect, not drama. So the sharpest question about Eliza is prosaic: who keeps merging pull requests now that the token is worthless and the foundation is closing? Walters says he does. He told reporters he is “starting over, since I own the IP, and I am never letting a token come close to Eliza again,” and that he holds no tokens and does not support any of it. His stated plan is to fund development through his own work and commercial deals rather than a treasury.
The commercial edge is thin but real. Infrastructure teams run their own hardened plugin registries (Automata’s attestation-focused fork and a registry fork maintained by Ethereum client team Nethermind), a TSXV-listed company, Secure Blockchain Development Corp, has built a white-label small-business automation product on the open framework, and Jupiter, the Solana trading hub, set aside grant money for developers building on it. None of that is a foundation with a budget and a roadmap. It is a scatter of independent parties who happen to find the code useful, each maintaining the slice they depend on and nothing more.
That model has a known failure mode. A 19.4k-star repository controlled by one owner and no institution is a bus-factor risk: if Walters loses interest or runs out of runway, the most forked agent stack in crypto becomes a museum piece, forks fragment, and enterprises quietly move to something with a support contract. It also has an upside the token era never offered: no market cap to defend, no holders to placate, no incentive to ship a feature just to move a price. Walters framed it in the language of a mission rather than a business: “Gonna keep building no matter what, every single day,” and, more grandly, “Eliza is dead. Long live Eliza.” Whether that survives contact with a payroll is the open question.
Where Eliza sits in a crowded field
Eliza is not the only agent framework, and outside crypto it is not even the biggest. General-purpose orchestration frameworks have far larger developer bases, and among crypto-native projects the token-market leader is a different company entirely. Eliza’s claim is narrower and more defensible: it is the most complete open-source stack for agents that hold wallets and act on-chain, with the largest plugin ecosystem aimed at that use case.
| Framework | Origin | Focus | Note |
|---|---|---|---|
| ElizaOS | Eliza Labs (Walters) | Crypto-native agents, wallets, plugins | Token dead; MIT-licensed; most-forked crypto agent stack |
| Virtuals Protocol | Virtuals | Tokenized agent launchpad (Base, Solana) | Market-cap leader among agent tokens |
| Olas (Autonolas) | Valory | Autonomous services, agent-to-agent marketplace | Marketplace fee plus token buyback |
| LangGraph / LangChain | LangChain | General LLM orchestration | Large outside crypto; not chain-native |
| CrewAI | CrewAI | Multi-agent role orchestration | Popular general-purpose framework |
The strategic risk is that the general frameworks add wallet and chain support faster than Eliza can turn its head start into a moat, leaving it as a reference implementation rather than the default. The strategic hope is that being crypto-native from day one, with the plugins, the wallet handling, and the on-chain primitives already built, is a durable advantage in a world where more of the interesting agent activity happens on-chain. Both can be true at once for a while.
The sector recovered; the token did not
Zoom out and the contrast is stark. The broader AI-agent token category has recovered to a market value around $4.17 billion, with 24-hour volume near $511 million, led by Venice at $32.53 and a $1.57 billion market cap (now more than a third of the whole category on its own), followed by Virtuals near $0.76 and Fetch/ASI near $0.21, per CoinGecko. ELIZAOS, at a $1.26 million market cap, is not a participant in that recovery in any meaningful sense; the legacy AI16Z contract trades even thinner, around $0.00048 for a roughly $526,000 market cap.
| Token | Price | Market cap |
|---|---|---|
| Venice (VVV) | $32.53 | $1.57B |
| Virtuals (VIRTUAL) | $0.7573 | $499M |
| ASI Alliance (FET) | $0.2143 | $496M |
| Kite (KITE) | $0.1344 | $321M |
| OriginTrail (TRAC) | $0.3600 | $161M |
| ELIZAOS | $0.000168 | $1.26M |
The takeaway is the one Eliza has become a case study for: framework quality and token performance are different variables that can diverge completely. The sector even seems to be internalizing it, with newer projects leaning on revenue and buybacks rather than pure emissions. Walters himself gave the sharpest verdict on the original promise back in 2025, when he told an audience at a conference, per Decrypt: “You probably do not want to give an AI agent a bunch of money and expect it to make you more.” The man who built the most famous AI-fund token in crypto does not think an AI should run your fund. That is either refreshing honesty or a damning epitaph, depending on when you bought.
Where the SEC fits, and where it does not
An important thing to understand about Eliza’s legal saga is what it was not. The Pikabea case was a private class action over marketing and disclosures, not an enforcement action by the Securities and Exchange Commission. The SEC has not brought a case here, and when the SEC and the CFTC issued a joint interpretation on digital assets in March 2026, it did not mention autonomous AI agents at all. The regulatory perimeter that caught ai16z was consumer-protection and false-advertising law, applied by plaintiffs’ lawyers, not securities enforcement.
SEC Chair Paul Atkins has signaled awareness that this is coming. He has said that “artificial intelligence agents will increasingly participate in markets and financial decision-making at machine speed,” while framing the agency’s posture as light-touch: “Our job is to set the rules of play and referee the game, not to pick the winning team.” For now, that leaves a gap. An agent has no legal personhood and cannot be a defendant, so liability lands on the human who deployed or controlled it, and the deployer is also the one on the hook at tax time, since an agent’s gains are attributed to the wallet owner exactly as our guide to the 2026 crypto-tax rules lays out. Software that trades does not get its own tax ID.
What to watch into 2027
Four things will tell you whether Eliza’s second act is real. First, does Hyperia actually ship, and does watching agents survive in a game world produce any evidence they can do useful work outside one? A launched game with a live agent economy would be the strongest signal the project has offered in a year. Second, does the Rust and Python core land as a stable, embeddable runtime, or does the rewrite stall the way ambitious rewrites often do? Third, does anyone make real money building on it, because a single profitable commercial adopter would do more for the framework’s survival than any number of GitHub stars.
Fourth, and most important, does the memory-injection problem get a real answer? Until an agent can be trusted not to sign away its wallet because it read the wrong post, the ceiling on autonomy is low, and every serious deployment will keep a human in the loop and a spending cap in place. That is not a failure. A great deal of value can be captured by agents that are fast, cheap, and tightly supervised: rebalancing a portfolio inside preset limits, monitoring positions and alerting a human, routing payments a person has pre-approved, or grinding the unglamorous back-office work that never needs a wallet with unlimited authority. But that is a long way from an operating system that runs the world unattended, and pretending otherwise is how people keep losing money.
The honest verdict on Eliza in September 2026 is that it is a healthier project than its token price suggests and a less finished one than its “operating system” tagline implies. The token was always the least interesting thing about it, and now that the token is gone, the framework gets judged on merits: an active codebase, a genuine ecosystem, a real security problem it shares with the entire field, and a founder betting his time on the idea that games teach agents to work. That is a more defensible position than most of the wreckage from the 2024 agent mania. It is not yet a business, and it is not yet safe. It is, at least, still being built.
Frequently Asked Questions
Is the Eliza framework dead now that the ai16z token is gone?
No. The ELIZAOS token collapsed and the foundation is winding down, but the framework is open-source under an MIT license, still hosted on GitHub, and still actively developed. Shaw Walters says he owns the intellectual property and will keep building it without a token.
What is an agentic operating system?
It is the framing Eliza now uses for itself: a base layer that agents run on, bundling a runtime, a plugin system, long-term memory, model routing, and a wallet, rather than a single chatbot app. It is an ambition as much as a description, since the project is still adding multi-language support and core features.
Can an ElizaOS agent be hacked?
Yes. Princeton researchers showed that agents built on ElizaOS can be manipulated through memory injection, where a poisoned entry in the agent’s stored context leads it to move funds. Standard prompt-injection defenses do not reliably stop these attacks, which is why spending caps, human confirmation, and better memory design matter.
Is ElizaOS free to use?
Yes. The framework is free and open-source under an MIT license, and it does not require the ELIZAOS token to run. You still pay for the language-model calls and infrastructure your agent uses.
What is the Eliza AI RuneScape game?
It is Hyperia, an in-development multiplayer online game where autonomous agents play alongside humans, built on ElizaOS. Walters frames it as proof of his thesis that playing games is the path to agents that can do useful real-world work, though the game has not launched.
Marcus Okafor covers AI and crypto for HOGE Wire.