Should You Build on Eliza in 2026? The Post-Token Framework

On 11 August 2026 the token that started life as ai16z printed a fresh all-time low. ELIZAOS traded as low as $0.00016 before bouncing back toward $0.0002, a market value of roughly $1.5 million and a rank past 2,300 on CoinGecko. Nineteen months earlier the same asset had been worth close to $2.4 billion, according to CoinDesk. That is not a drawdown; it is a demolition.

In the same fortnight, the software behind that token did something the token could not: it kept working. The elizaOS/eliza repository carries roughly 19,000 stars, more than 5,700 forks and a develop branch north of 12,000 commits, and it was still merging pull requests in the days after founder Shaw Walters declared the token finished. That split, between a collapsed asset and a framework that refuses to die, is the whole story for anyone deciding where to point their engineering hours this year.

This is not another obituary. Eliza has been eulogized already, several times over. The question that matters for builders in the second half of 2026 is narrower and more practical: with the token dead, the foundation winding down and the treasury handed to litigants, is the Eliza framework still a sensible base to build an autonomous agent on? Or has the wreckage of the asset dragged the credibility of the code down with it? What follows is a working answer, weighing the framework’s technical merits, its stewardship, its security record, its rivals and its true cost, from the point of view of someone who has to ship.

A Dead Token and a Living Repository

Start with the two facts that sit uncomfortably next to each other. On 4 August 2026, Walters posted on X that the token was over. The wording was blunt: the token is dead, completely, and the foundation is winding down. The trigger was a settlement of the Burwick Law class action in the Southern District of New York, which had accused Eliza Labs and its insiders of dressing a largely human-run fund in the language of autonomous artificial intelligence and of borrowing the a16z name without permission. Rather than fight, the foundation surrendered what remained of its treasury to the plaintiffs.

Now hold that against the repository. A token dying usually takes the project with it, because in crypto the token is the funding, the marketing and the community all at once. Eliza is the rare case where the code and the coin were never the same thing. The framework is MIT licensed, which means anyone can fork it, ship it and sell products built on it without asking permission and without owing royalties. When the corporate entity around it collapsed, the license did not care. Commits continued. Issues were triaged. The repository description even hardened its ambition during the wind-down, now billing Eliza as an agentic operating system rather than a mere agent library.

For a builder, that is the first and most important signal. You are not evaluating a company that might go bankrupt and take your dependency offline. You are evaluating a body of open-source TypeScript that has already survived the worst thing that can happen to a crypto project. The relevant risk is no longer solvency; it is maintenance, security and direction. Those are ordinary open-source questions, and they have ordinary open-source answers.

What the Eliza Framework Actually Is

Strip away the token drama and Eliza is a TypeScript framework for building autonomous agents: software that runs a large language model as its brain, holds persistent memory, exposes tools, and, in the crypto case, controls its own wallet so it can sign transactions without a human clicking approve each time. That last part is what separates an agent from a chatbot or a scripted trading bot. The model decides; the wallet acts.

The framework organizes everything through a single plugin interface. One plugin object can register database adapters, actions (things the agent can do), providers (context the agent can read), evaluators (post-hoc reflection and scoring), model handlers, HTTP routes, event listeners and background services. That uniformity is the framework’s best engineering idea, because it means integrating a new chain, a new data source or a new tool always looks the same. The messaging model layers on top of it: Worlds contain Rooms, Rooms contain Entities, and a 2026 shift has pushed the architecture toward channel-based rather than agent-centric addressing, which matters if you want one runtime to host many agents in many contexts.

Crucially, Eliza is model-agnostic. You can point it at a hosted frontier model, at an open-weights model you run yourself, or at the project’s own local-first Eliza-1 line, and swap between them without rewriting your agent. For teams building AI features into wallets, that flexibility is the same instinct driving the broader shift toward programmable accounts we covered in our look at smart-account wallets: the wallet becomes a surface an agent can operate through session keys and scoped permissions rather than a raw private key handed to a language model.

How the Token Died, and Why the Code Kept Shipping

To judge the framework fairly you have to understand what killed the token, because none of it was a code failure. Walters launched ai16z in October 2024 on Solana through the daos.fun launchpad, aiming to raise around $75,000 for a community-guided fund run by AI personas. Then Marc Andreessen quote-tweeted it with the words GAUNTLET THROWN, and the market cap rocketed to roughly $96.6 million within hours, as The Block documented at the time. The name similarity to Andreessen Horowitz was the whole marketing hook, and it eventually forced a rebrand to ElizaOS in January 2025 after a16z asked the project to distance itself.

The deeper problem was the gap between the pitch and the plumbing. The fund was marketed as autonomous, but humans approved the trades. Walters himself later put the reality plainly in a candid Decrypt interview: you probably do not want to give an AI agent a bunch of money and expect it to make you more. That honesty came too late to matter for the token, which had already migrated from a 6.6 billion supply toward an 11 billion cap, become the centerpiece of a lawsuit alleging insiders captured around 40 percent of the new supply, and lost more than 99 percent of its peak value.

The key insight for builders is that every failure in that chain was a failure of governance, disclosure and tokenomics, not of the runtime. The action-chaining worked. The memory system worked. The plugin architecture worked. What did not work was a financial and legal structure bolted on top of the software by people who wanted a moonshot asset. Walters drew the same conclusion in his farewell, telling reporters he is starting over because he owns the intellectual property, and that he is never letting a token come close to Eliza again. Read that as a design decision, not just a mood.

Who Maintains Eliza Now?

Here is where the honest builder gets nervous. Open-source software is only as durable as the people who patch it, and Eliza just lost its foundation and its treasury in one week. So who keeps the lights on? In practice, three overlapping constituencies now share stewardship, and each carries a different incentive and a different risk.

Walters has been emphatic that he is not walking away. His public line since the settlement is that he will keep building no matter what, every single day, and that the project will still be here in ten years pushing the edge of what agents can do. Founders say things like that. What gives it weight is the license and the commercial pull underneath it. When several well-capitalized infrastructure teams already depend on your framework, maintenance stops being charity and becomes self-interest. Nethermind, one of the major Ethereum client teams, runs its own plugin registry fork; Automata Network runs another, alongside a proof-of-agent plugin that uses Intel remote attestation to prove an agent ran inside a trusted enclave. Those are not hobbyists.

The stewardship picture, in short, is a distributed one that looks a lot like other mature open-source projects whose sponsoring entity faded. That is a survivable pattern, but it is not a guarantee. If you build on Eliza, you should assume you will occasionally have to fix upstream yourself, and budget for it.

The Technical Case for Building on Eliza

Set the drama aside and the framework has a genuine technical case, which is why serious teams still touch it. The plugin model is the headline. Because adapters, actions, providers, evaluators, model handlers, routes and services all register through one interface, the cognitive cost of extending an agent stays flat as the agent grows. Adding a new chain integration feels the same as adding a new data feed, which feels the same as adding a new tool. That consistency is worth more over a project’s life than any single clever feature.

Model-agnosticism is the second pillar. In a year when frontier-model pricing, rate limits and terms of service have whipsawed more than one AI startup, the ability to route an agent to a different provider, or to local weights, without touching your agent logic is a real hedge. The Eliza-1 local-model line pushes this further, letting privacy-sensitive or cost-sensitive deployments keep inference in-house. The release cadence is brisk; the project ships beta builds in bursts rather than sitting on a quarterly schedule, which cuts both ways but signals life.

The third pillar is the ecosystem around the core. The plugin registry means you rarely start from zero: chain adapters, wallet connectors, social integrations and data providers already exist, and the mainstream forks from Nethermind and Automata mean the plugin surface is being hardened by teams that care about attestation and correctness, not just demos. If your agent needs to move value, the payment rails are maturing in parallel; the emergence of machine-to-machine settlement standards, which we mapped in our guide to how AI agents actually pay on-chain, gives an Eliza agent a growing menu of ways to transact without a bespoke integration for every counterparty.

Eliza Versus the Field

No framework decision happens in a vacuum. The honest comparison in 2026 is not Eliza against a blank page; it is Eliza against a handful of maturing alternatives, each optimized for a different builder. The table below is a map, not a scoreboard.

The token figures come from CoinGecko’s AI Agents category, which sat near $2.6 billion in aggregate value in mid-August 2026. Read the table this way. If you want a crypto-native, deeply customizable agent and you have engineers who can live in TypeScript, Eliza is still the most complete open runtime available, and the fact that its token is worthless is now a feature: there is no speculative overhang, no tokenholder governance to placate, no reason to build for a pump. If you want to ship a tokenized agent this week without writing much code, Virtuals is the pragmatic pick, hosting more than 15,000 agent tokens. If your problem is coordinating many agents around on-chain services, Olas is purpose-built for it. And if your use case is not really crypto at all, LangChain or CrewAI will give you a larger talent pool and, frankly, less baggage. Each of the general frameworks now carries well over a hundred thousand GitHub stars, dwarfing Eliza’s community, so the hiring-and-answers advantage there is real.

The Security Ledger: What Safe Agents Cost

This is the section that should decide most builds, and it is not Eliza-specific: it is the tax every on-chain agent framework pays. An agent that can sign transactions is an agent that can be tricked into signing the wrong one, and 2026 produced a grim catalogue of exactly that. The failure mode is structural. A language model cannot reliably tell the difference between instructions from its operator and instructions smuggled into the data it reads, so any untrusted input the agent ingests is a potential command.

The academic case against naive agents is well documented. A team of Princeton and allied researchers published Real AI Agents with Fake Memories, introducing the CrAIBench benchmark and showing that context-manipulation attacks can poison an agent’s memory so it later acts against its owner, with Eliza-style Web3 agents among the targets. The theory became practice in the wild.

The Grok and Bankr episode is the one to internalize. An attacker hid an instruction in Morse code inside a social-media reply and gifted the agent an NFT that quietly unlocked transfer and swap permissions, and the agent moved roughly $150,000 to $200,000 of tokens before anyone caught it, an incident logged by the OECD AI Incidents monitor. Most of the funds were later returned, but the point stands: the attack used no exploit in the usual sense. It used the agent’s own reasoning against it.

Vitalik Buterin’s prescription has become the default advice. In an April 2026 essay he argued that autonomous agents should carry hard spending caps, on the order of $100 a day, and that a human and the model should act as a two-of-two confirmation for anything larger, so neither can move real value alone. He also cited research suggesting a meaningful fraction of agent skills in the wild ship with malicious instructions, a reason to treat the plugin ecosystem you lean on as a supply chain, set out in his post on securing LLMs. If your Eliza agent touches DeFi, the composability that makes on-chain credit powerful also multiplies blast radius, a dynamic we mapped in our risk map for on-chain lending. Before shipping, price in a real audit and a bounty; the going rates and what they actually buy are laid out in our piece on bug bounty payouts in 2026.

Who Is Actually Shipping on Eliza

A framework’s real health shows in what people build on it, not in its token chart. On that measure Eliza is doing better than the price suggests. The most consequential adopter is Secure Blockchain Development Corp, a TSX Venture-listed company that entered a development agreement with the Eliza Foundation to build a white-label product called Agentic SME on the open framework, announced in May 2026. The product targets small and mid-sized businesses that want agents to handle sales, admin, finance, support ticketing and internal reporting, with a first deliverable inside 30 days and a launch aimed at the middle of August 2026.

The structure of that deal is the tell. Agentic owns the white-label SME product; it does not own the underlying open-source framework, which remains free for everyone else. That is exactly how a healthy open-source economy is supposed to work: companies capture value in the products and services they wrap around a commons, not by owning the commons itself. It is also, notably, the same commercial arrangement that survives the token being dead, because none of it depends on ELIZAOS having a price.

There is an irony worth naming. Sebastian Quinn-Watson, a co-founder of the Agentic venture and now a director at Secure Blockchain, is also a named defendant in the very lawsuit that killed the token, having been swept in for his role in the original project. The person building a legitimate business on the framework and the person accused of inflating the old token’s autonomy claims are, in one case, the same person. That is not a reason to avoid the framework; it is a reminder that the commercial layer and the legal wreckage overlap, and that due diligence on partners still matters. Beyond the enterprise track, the framework powers experiments like the AI-native game Clawville and has attracted developer-fund attention from the Solana ecosystem, so the builder base is not resting on a single deal.

Building a Business Without a Token

If you cannot issue a token, or have watched what happened when this project did, how do you make money on an agent framework? This is the question the whole sector is quietly re-learning, and Eliza is now an accidental case study in the answer. The token-first model treated the asset as the product: launch a coin, market the agent as its engine, and let speculation fund development. That model just detonated in the most public way possible.

The tokenless alternatives are less glamorous and far more durable. You can sell a white-label product, as Agentic SME does. You can sell hosting, support and service-level guarantees to teams that do not want to run their own agent infrastructure. You can build a paid plugin or a managed data provider and monetize the integration rather than a coin. And increasingly you can let the agents themselves become the revenue line, charging per task or per transaction as machine-to-machine payment rails standardize. When an agent can pay another agent a few cents for a data lookup or a compute job, the business model stops needing a speculative asset at all; it needs a service worth paying for.

Walters clearly landed on this lesson the hard way. His insistence that he will never let a token come close to Eliza again is, read commercially, a statement that the framework’s future value will be captured through software and services rather than an asset that regulators and litigants can treat as an unregistered security. For a builder, that alignment is reassuring: you are building on a commons whose maintainer has every incentive to keep it clean, boring and legally uninteresting.

The Regulatory Reality for US Builders

American builders tend to assume the SEC is lurking behind every crypto story. In Eliza’s case it was not. The action that ended the token was a private class action brought by a law firm on behalf of retail losers, not an enforcement matter, and that distinction shapes how you should think about legal risk on the framework. The claims were consumer-protection and false-advertising claims about the token’s marketing, and they were resolved by settlement, with a judge, Jed Rakoff, who at one point scolded plaintiffs’ counsel on the record for a single attempt at serving the founder, as courtroom reporting captured. The lesson is that your exposure comes from what you claim about your agent, not from the framework you used to build it.

The federal posture toward the underlying technology has been comparatively hands-off. The joint interpretation issued by the SEC and CFTC in March 2026, which sorted a slate of tokens into a digital-commodity taxonomy, did not mention AI agents once. SEC Chair Paul Atkins has framed his agency’s role in deliberately narrow terms, telling an audience that its job is to set the rules of play and referee the game, not to pick the winning team, in remarks reported by CoinDesk. That leaves a gap builders should respect rather than exploit. An agent has no legal personhood and no tax identity, so when it acts, liability flows to the human or company that deployed it. If your agent moves value across borders or on behalf of users, the same identity and compliance obligations that apply to any money-moving service still apply to you; our explainer on FATF crypto guidance and the Travel Rule is a useful starting point for where those lines fall.

The Build-or-Skip Decision, Factor by Factor

Pull the threads together and the decision becomes a checklist rather than a vibe. Weigh these factors against your own project, because the right answer for a two-person crypto-native team is not the right answer for an enterprise integration group.

The pattern is clear once it is laid out. Build on Eliza if you are a crypto-native team that wants a customizable, model-agnostic, openly licensed agent runtime, and you have the security discipline to run it responsibly. In that profile, the dead token is genuinely an advantage, not a red flag, because it removes the one thing that has repeatedly turned agent frameworks into regulatory and reputational hazards. Skip Eliza, or at least prefer a general framework, if your use case is not really on-chain, if you need a deep hiring pool, or if you require vendor-backed support with contractual guarantees. In that world, LangChain and its peers give you more people, more answers and less history.

What Could Still Go Wrong

A fair verdict names the ways it could still fail. The first is the bus factor. As much as commercial adopters have skin in the game, Eliza’s direction still leans heavily on one founder who just lost his funding vehicle. If Walters burns out or moves on, the framework does not vanish, but its momentum could stall into the slow decay that swallows many post-hype open-source projects.

The second is a security event. The framework’s reputation is already bruised, and a high-profile drain of an Eliza-built agent, fairly or not, would be pinned on the framework in headlines even if the fault lay with a careless integrator. The prompt-injection problem is industry-wide and unsolved, which means this risk never fully clears; it can only be managed with spending caps, human gates and disciplined handling of untrusted input.

The third is competitive drift. Virtuals keeps lowering the barrier to shipping an agent with no code, and the general-purpose frameworks keep absorbing crypto features from the outside in. Eliza’s edge is being the most complete open, crypto-native runtime, but edges erode. The through-line of the past year, that framework quality and token performance are entirely separate variables, cuts both ways: the code can be excellent while the project quietly loses relevance. For builders, the takeaway is not to avoid Eliza but to build on it the way you would build on any dependency whose future is uncertain: keep your own logic portable, isolate the framework behind interfaces you control, and be ready to move if the maintenance story changes.

Frequently Asked Questions

Is the Eliza framework still being maintained in 2026?

Yes. Despite the token’s death and the foundation winding down, the open-source elizaOS/eliza repository remained active through August 2026, with roughly 19,000 stars, more than 5,700 forks and pull requests still being merged. Founder Shaw Walters has said he will keep building, and commercial adopters including Nethermind and Automata Network maintain their own plugin registry forks, so maintenance no longer depends on a single entity.

What happened to the ai16z and ELIZAOS token?

The token launched as ai16z in October 2024, peaked near a $2.4 billion market value in January 2025, and then collapsed. In August 2026, after settling a Burwick Law class action in New York that alleged deceptive marketing, the foundation handed its remaining treasury to the plaintiffs and Walters declared the token dead. By mid-August 2026 it had set a fresh all-time low near $0.00016 and traded around $0.0002, a market value of roughly $1.5 million.

Is Eliza safe to use for on-chain agents?

It is only as safe as how you deploy it. The core risk, shared by every agent framework, is prompt injection and memory poisoning, where untrusted input tricks the model into signing malicious transactions. Real incidents such as the 2026 Grok and Bankr drain show the danger is not hypothetical. Mitigate it with hard daily spending caps, human confirmation for large transfers, careful vetting of plugins, and a professional audit before handling real value.

How does Eliza compare to Virtuals Protocol and LangChain?

Eliza is a full, openly licensed, model-agnostic runtime for custom crypto-native agents, best for teams that can work in TypeScript. Virtuals Protocol is a no-code launchpad for shipping tokenized agents quickly with less engineering. LangChain is a general-purpose orchestration framework with a much larger community and no crypto focus, better suited to enterprise or non-crypto workflows. The right pick depends on whether you need deep customization, speed, or a large talent pool.

Do I need the ELIZAOS token to build on the framework?

No. The framework is MIT licensed and has never required the token to build, deploy or run agents. The token was a separate financial instrument layered on top by the original project, and its collapse has no bearing on your ability to use the software. If anything, building on the framework is now cleaner because there is no speculative asset or tokenholder governance to design around.

By Marcus Okafor, senior editor at HOGE Wire, covering AI agents and on-chain infrastructure.