The Eliza Framework After ai16z: What’s Actually Being Built
ai16z's token crashed over 99 percent, but the open source Eliza framework kept shipping: a bootable AI OS, an MMORPG, and an SME automation deal. Here is what actually got built.
Eighteen months ago, ai16z was a joke that got out of hand: a Discord bot riffing on the name of venture firm Andreessen Horowitz that briefly traded, on paper, above a two and a half billion dollar valuation. Today that token trades for a fraction of a cent, its founders are named defendants in a federal class action, and most coverage of the project has settled into a familiar shape: rise, rebrand, collapse, lawsuit. That story is true, and it is mostly finished.
What is not finished is the code underneath it. The Eliza framework, the open source software ai16z was built on top of, kept shipping through all of it. It now boots as a Linux desktop from a USB stick, runs a non-custodial wallet, powers the companion agents inside an online role-playing game, and is being wired into a white-label automation product for small businesses. None of that requires anyone to hold the ELIZAOS token, and none of it depends on how the ai16z lawsuit is eventually resolved. This is a look at what is actually being built on Eliza in mid-2026: who is funding it, how it stacks up against rival frameworks, and whether the security and governance problems that dogged its most famous application have actually been fixed.
What the Eliza Framework Actually Is
Strip away the token and the drama, and Eliza is a TypeScript framework for building AI agents that maintain memory, call external tools, and act across multiple platforms from a single character definition. It is MIT licensed and hosted on GitHub under the elizaOS organization, where the core repository has collected more than 18,800 stars and roughly 5,600 forks, among the largest followings of any open source agent framework in crypto, according to the elizaOS/eliza repository itself.
The architecture is organized around four primitives. Actions define what an agent can do, from executing a token swap to posting a reply. Providers inject context into the model’s prompt: wallet balances, recent messages, portfolio data. Evaluators run after a response is generated, updating long-term memory or scoring the quality of an interaction. Services are long-running connections, such as a Discord client or a price feed, that persist across conversations. A plugin bundles these pieces together, and the framework’s plugin registry now spans core infrastructure (message handling, SQL storage, retrieval-augmented knowledge), blockchain connectors (EVM support across more than thirty networks including Ethereum, Base, and Arbitrum, plus Solana with native swap routing), and the major model providers, including OpenAI, Anthropic, and OpenRouter. Community-maintained plugins extend this further into areas the core team does not prioritize directly, everything from niche chain support to specialized data feeds, which is the same double-edged pattern seen across most plugin-based software ecosystems: faster coverage, at the cost of a wider and harder-to-audit surface area.
Because the framework is model-agnostic and does not require a token to use, anyone can clone the repository, define a character file, and run an agent locally without ever touching ELIZAOS or interacting with anything the ai16z lawsuit is actually about. A single character file, in practice, can run identically as a Discord bot, a Telegram bot, and an X account at the same time, since the personality and memory live in the framework rather than in any one client. That distinction, code versus token, is the one most coverage of the collapse tends to flatten.
How an Eliza Agent Actually Handles a Request
The four primitives are easier to picture with a concrete walk-through. Say a user messages an Eliza-based agent in a Discord server and asks it to check a wallet balance and swap a small amount of SOL for USDC. The Discord client, running as a service, hands the incoming message to the runtime. A provider then pulls in context the model needs to respond sensibly: the user’s linked wallet address, its current balances, recent conversation history, maybe the last few prices seen for that pair. The underlying language model, whichever one the operator has configured, reasons over that context and decides to call the swap action, one of potentially dozens registered by the agent’s installed plugins, passing in the token pair and amount. The action executes the transaction through the Solana plugin’s swap routing and returns a result. Finally, an evaluator runs after the fact: it might log the trade to long-term memory, flag the interaction for a later credibility score, or simply note that the user tends to trade this pair on Fridays.
Nothing in that loop is unique to finance. Swap the wallet plugin for a calendar plugin and the same four-step pattern, gather context, decide, act, remember, is what powers Eliza’s personal-assistant features, and swap it again for a game-world plugin and it is what lets a game companion agent decide whether to keep mining, start a quest, or head home for the night. The pattern is also exactly where the framework’s best-known vulnerability lives: the evaluator step writes to memory that a later provider will trust without necessarily re-verifying it, which is the gap that memory-injection research, discussed further down, exploited directly.
How ai16z Became elizaOS, in Brief
The short version, for anyone who has not followed the saga: developer Shaw Walters and collaborators launched the AI16Z token on Solana on October 24, 2024. Three days later, Marc Andreessen posted about the project himself, and its market cap jumped toward $96 million overnight. By January 2, 2025, the token hit an all-time high of $2.47, implying a fully diluted valuation north of $2.6 billion, an extraordinary number for a project that was, by its own founder’s later public admission, closer to an experiment in agent tooling than an autonomous hedge fund.
Walters has been candid, at times, about that gap between marketing and mechanics. “You probably do not want to give an AI agent a bunch of money and expect it to make you more,” he told Decrypt in October 2025, describing a system built to score traders’ track records rather than one that lets a model freelance with real capital. A statement like that, roughly a year into the project’s life, sits awkwardly next to the autonomous AI hedge fund framing that drove the original token narrative, and it is a large part of why a class action exists at all.
The project’s early credibility was not purely hype-driven. In December 2024, Eliza Labs announced a research partnership with Stanford University’s Future of Digital Currency Initiative, with the work overseen by cryptographers Dan Boneh and David Mazieres and aimed at questions of how AI agents establish trust and coordinate inside decentralized financial systems, according to The Block’s reporting at the time. That kind of academic association is part of why the eventual collapse and lawsuit landed as more than just another memecoin blowup.
Pressure from Andreessen Horowitz over use of its name pushed a rebrand to elizaOS, and across October and November 2025 the project migrated the token at a ratio of one old token to six new ones, expanding total supply from 1.1 billion to 11 billion. About 60 percent of the new supply went to existing holders; the rest was split between private investors, the team, and other allocations, a structure that is now the central factual dispute in a federal class action filed by Spain-based investor Gorka Pikabea in the Southern District of New York in April 2026. The suit names Eliza Labs Inc, Walters, co-founder Sebastian Quinn-Watson, and the AI16Z DAO as defendants, and alleges the project misrepresented how autonomous its flagship trading agent really was while diluting early holders through the migration. None of the claims have been decided by a court. By mid-July 2026, ELIZAOS traded around $0.00058 with a market cap near $4.3 million, according to CoinGecko, down more than 99 percent from the January 2025 peak.
That is the part of the story that keeps getting retold. The part that gets skipped is what the underlying software did next.
The Pivot: From Trading Bot to Agent Operating System
Read the elizaOS GitHub repository today and the trading-bot framing is largely gone. The project now describes itself as “your agentic operating system,” split into two pieces: Eliza, a personal AI assistant for desktop, mobile, and web, and elizaOS, the runtime underneath it. That runtime is not a metaphor. The project’s own documentation describes bootable Linux images, built for amd64, arm64, and riscv64 hardware, that load a full desktop with the Eliza assistant built in directly from a USB stick, plus an Android build that can run as the default system launcher on Pixel-class devices.
The assistant layer leans heavily on on-device inference. Eliza-1, a family of local models built on Google’s Gemma-4, handles text, voice transcription, and vision processing without a network round trip, in sizes ranging from roughly 2 billion parameters for mobile devices up to 27 billion for desktop hardware. Bundled on top of that: multi-account messaging across iMessage, Discord, Telegram, WhatsApp, Slack, Farcaster, and X; a personal-assistant layer for calendars, reminders, and daily briefings; browser automation; document analysis through retrieval-augmented generation; and a non-custodial wallet covering both EVM chains and Solana, built around a rule the documentation states directly: every spend needs the user’s OK. That consent-gated design puts Eliza in the same conversation as the industry’s broader struggle with blind signing, where wallets ask users to approve transactions they cannot actually read in any meaningful way; HOGE Wire has covered that problem in depth in the context of multisig wallets, and it applies just as much to an AI agent asking for a green light on a swap it composed itself.
This is a meaningfully bigger scope than “AI agent framework for crypto trading,” and it did not happen by accident. It reflects a bet that the durable business is not a fund that trades on someone’s behalf, but an operating system layer that other people build products on top of, which is exactly what has happened over the past year. Eliza Labs also runs auto.fun, a self-serve launchpad for spinning up new agents, so the operating system pitch and the older launchpad model now coexist rather than one replacing the other.
| Metric | Figure |
|---|---|
| GitHub stars / forks | 18,800+ / 5,600+ |
| License | MIT |
| Primary language | TypeScript |
| Core primitives | Actions, Providers, Evaluators, Services |
| Blockchain support | EVM (30+ networks), Solana |
| On-device model family | Eliza-1 (Gemma-4 based, roughly 2B to 27B parameters) |
| ELIZAOS price (mid-July 2026) | Approximately $0.00058 |
| ELIZAOS market cap | Approximately $4.3 million |
| Circulating supply | Approximately 7.5 billion tokens |
| Ecosystem fund (with Jupiter) | $10 million, the Magic Fund |
Clawville and the Case for Agent-Native Games
The clearest proof of concept for Eliza as infrastructure, rather than as an ai16z side project, is a game. Clawville, described by its creators as an AI-native open-world MMORPG built inside the Milady ecosystem, an existing NFT-linked community and brand universe, launched in mid-May 2026 with a pitch that sounds gimmicky until you look at what is actually running underneath: players can deploy autonomous companion agents that explore the world, complete quests, and gain experience on their own, and those companions run on the same elizaOS runtime, the same memory system, and the same action protocol as any other Eliza agent, per Cointelegraph’s coverage of the launch.
Activities inside the world span racing, building, and character customization, and what a companion learns from any of it persists across sessions through elizaOS’s retrieval-augmented memory, merging back into the same knowledge base an agent would draw on outside the game. An agent that has spent a week racing or building carries that history into the next session, and reportedly even across exports to other Eliza-based deployments, rather than starting over each time. It is a genuinely different pitch from the launchpad-and-token model that defined the first wave of AI agent projects: the game is the product, and Eliza is invisible plumbing rather than the headline. That is also a notable contrast with how slowly agent-native and AI-assisted mechanics have shown up in Bitcoin-adjacent gaming, where HOGE Wire has written about why Web3 gaming skipped Lightning Network almost entirely in favor of the EVM and Solana rails that Eliza agents already default to.
The Enterprise Bet: Secure Blockchain and Agentic SME
The second concrete signal is corporate rather than cultural. On May 15, 2026, publicly traded Secure Blockchain Development Corp announced a development agreement with the Eliza Foundation, the entity that stewards elizaOS’s open source development, to co-build a white-label AI agent product for small and mid-sized businesses, branded Agentic SME. The plan, according to the companies’ own announcement, targets sales support, administrative work, finance tasks, customer support ticketing, FAQ handling, and internal reporting, with an initial version due within 30 days and a fuller release within three months. The agreement also contemplates Secure Blockchain staking or deploying ELIZAOS tokens within the ecosystem, one of the few concrete, disclosed pieces of enterprise demand for the token itself since the migration.
The path to that agreement has an odd wrinkle worth flagging. On April 10, 2026, Secure Blockchain Development Corp, a TSX Venture-listed company, closed an all-stock acquisition of Agentic Solutions Limited, an elizaOS-focused AI company, issuing five million shares at $0.09 each and appointing Agentic co-founder Sebastian Quinn-Watson as a Secure Blockchain director, according to the companies’ own disclosure. Ten days later, the Pikabea class action named that same Sebastian Quinn-Watson as a co-founder defendant alongside Walters. The Agentic SME product that Secure Blockchain and the Eliza Foundation unveiled a month after that is, in other words, being built in part by a team whose own co-founder was named in a lawsuit over the previous project’s autonomy claims within the same two-week window.
It is a small deal in dollar terms next to the ai16z token’s old paper valuation, but it is the kind of unglamorous, recurring-revenue use case that AI agent frameworks have mostly promised rather than delivered. Whether Agentic SME actually ships on schedule and finds paying customers is a far better test of the framework’s commercial viability than anything the ai16z token does next, even if the overlapping cast of characters is a reminder of how small this corner of crypto still is.
Funding the Ecosystem: Magic Fund and Jupiter
elizaOS is also trying to seed its own developer ecosystem directly. Alongside Solana DEX aggregator Jupiter, the project launched a $10 million fund, called the Magic Fund, aimed at open-source AI development in Web3, backing infrastructure projects, agent tooling, and ecosystem utilities rather than speculative token launches, as reported by The Block. One disclosed portfolio company, agent-coordination startup Questflow, had already raised a $6.5 million seed round in mid-2025 with backing tied to the fund. Jupiter’s involvement is notable in its own right: as one of Solana’s largest DEX aggregators by routed volume, it has an obvious commercial interest in more agents executing swaps through its infrastructure, which makes the fund as much a distribution deal for Jupiter as it is a grant program for elizaOS.
The logic is straightforward: a framework is only as valuable as what gets built on it, and a token treasury that funds outside teams is a more credible growth engine than a marketing budget. It is also an implicit acknowledgment that the flagship application, an autonomous trading agent, was never going to be the thing that proved the framework’s worth. Grant programs like this one are also a hedge against the maintainer bottleneck that hits most open source projects eventually: paying outside teams to build plugins and tooling spreads development load beyond whatever core team Eliza Labs can staff directly.
Eliza vs GAME vs Rig: The Framework Landscape
Eliza does not have this space to itself. The most direct rival is Virtuals Protocol’s GAME framework (short for Goal, Action, Mind, Engine), which powers agents launched through the Virtuals platform on Base. Where Eliza is a developer library that anyone can fork and self-host without touching a token, GAME is one layer of a vertically integrated stack: framework, launchpad, and token ownership model bundled together, with agents typically built on foundation models like Llama 3.3 70B, DeepSeek R1 and V3, and Qwen 2.5 72B doing the underlying reasoning. Virtuals co-founder Tiew Wee Kee, known as Weekee, described the philosophy behind the platform’s push into agent-to-agent commerce plainly when the company launched its Revenue Network in February 2026: “today’s launch marks another major step toward a global AI agent economy,” he said in the announcement. That is a fundamentally different bet than Eliza’s: Virtuals wants value to flow back through its own token and launchpad, while Eliza’s open license means a project can build and profit without the framework capturing any of it directly.
A third option, Rig, takes a narrower technical angle. It is written in Rust rather than TypeScript, trading Eliza’s larger contributor base and faster iteration speed for the memory safety and raw performance Rust offers in computationally heavy DeFi agent workloads. It has a smaller developer pool simply because fewer engineers write production Rust than TypeScript, and it has shipped fewer live, high-profile agents as a result, but it remains a common choice for teams that need to run complex on-chain computation inside the agent loop rather than farm it out to an external service. Smaller frameworks such as ZerePy, built around the Sonic ecosystem, and ARC occupy adjacent niches, though neither has matched Eliza’s contributor base or GAME’s launchpad volume.
| Framework | Language | Typical models | Core philosophy |
|---|---|---|---|
| Eliza / elizaOS | TypeScript | Model-agnostic (OpenAI, Anthropic, local Eliza-1) | Open source library; no token required to build |
| GAME (Virtuals Protocol) | Python-based agentic engine | Llama 3.3 70B, DeepSeek R1/V3, Qwen 2.5 72B | Vertically integrated launchpad with token and ownership layer |
| Rig | Rust | Model-agnostic | Performance-oriented; smaller pool of DeFi-focused agents |
The Security Problem Nobody Has Fully Solved
The most serious open question about any wallet-connected agent framework, Eliza included, is not the token price. It is whether the agent can be tricked into acting against its own owner. In March 2025, researchers from Princeton University and the Sentient Foundation published a paper, Real AI Agents with Fake Memories, that demonstrated exactly that against ElizaOS-based agents on Ethereum. The attack required no exploit in the traditional sense: an attacker sent a message into a Discord channel an agent was monitoring, formatted to be stored as a durable memory, for example an instruction claiming to be from an administrator directing funds to a new address. The agent filed it away as legitimate, and later, when a real user asked it to send funds, it recalled the fabricated memory and paid the attacker instead. The researchers, Atharv Singh Patlan, Peiyao Sheng, S. Ashwin Hebbar, Prateek Mittal, and Pramod Viswanath, found that simple prompt-based guardrails were not sufficient defense against this kind of context manipulation.
That finding sits inside a larger pattern. Security researcher Chaofan Shou, describing a separate but related class of attack against LLM routing infrastructure used by agentic systems more broadly, put the stakes bluntly: a single malicious router “is enough to compromise the entire system,” and his team traced one live incident to a $500,000 wallet drain, according to CoinDesk’s reporting from April 2026. That specific incident did not involve Eliza, but it illustrates why agent security is treated as an unsolved, sector-wide problem rather than something any one framework has closed out.
On the mitigation side, elizaOS’s plugin ecosystem has grown a defensive layer since the Princeton paper was published. A plugin known as plugin-tee gives agents secure key derivation and remote attestation inside a trusted execution environment, so a wallet’s private key never has to sit in plaintext memory the agent’s normal reasoning loop can touch, and a companion logging plugin timestamps sensitive actions inside the same enclave for later audit. elizaOS has also partnered with EigenCloud to run full agent workflows inside a TEE with cryptographic proof that the agent executed unmodified code on the correct model weights, an approach EigenCloud has detailed as a way to make an agent’s outputs independently verifiable rather than simply trusted. EigenCloud sits inside the same EigenLayer-linked restaking ecosystem that HOGE Wire has covered as it pulls in institutional capital, a sign that verifiable-compute infrastructure and restaking security budgets are increasingly the same story; see our coverage of restaking’s institutional adoption for more on where that money is coming from.
The harder problem is not cryptographic, it is social: anyone can publish a plugin to the registry, and a careless or malicious one can introduce exactly the kind of memory-poisoning vector the Princeton paper described, no enclave required if the agent simply trusts the plugin’s own outputs. That has pushed more of the framework’s security burden onto the same kind of independent, adversarial review that has become standard practice elsewhere in crypto; HOGE Wire has covered how that workforce operates in our reporting on whitehat bug bounty hunters, and plugin audits are a natural extension of that same model into the agent-framework layer.
Governance After the Lawsuit
The corporate structure behind Eliza is more fragmented than a single “ai16z team” framing suggests, and the lawsuit has made that fragmentation a legal question rather than just an organizational curiosity. Eliza Labs Inc is the commercial research and development entity, named as a defendant in the Pikabea suit alongside Walters personally. The Eliza Foundation is the separate entity that shows up signing outward-facing deals, including the Secure Blockchain agreement described above. The AI16Z DAO, also named in the litigation, is nominally where token holders coordinate. None of that structure was fully tested in public until a plaintiff’s lawyers were forced to draw it out in a court filing.
The litigation itself has moved slowly enough to become its own small story. At a May 2026 hearing, presiding judge Jed S. Rakoff learned that plaintiffs’ counsel had made exactly one attempt to serve lead defendant Shaw Walters, at a San Francisco address, where he was not present. “I am not going to move the case forward on this basis: 1 attempt?” Rakoff said from the bench, according to Inner City Press’s courtroom reporting, before ordering a written accounting of service efforts and adjourning the matter. Quinn-Watson’s residence in Australia adds its own delay, since serving him formally requires Hague Convention procedures that can take months. None of that speaks to the merits, but it is a useful reminder that a filed lawsuit and a resolved one are very different things, and that this one was still, procedurally, barely underway as of mid-2026.
The practical effect for anyone evaluating the framework today is that the software’s governance and the token’s governance are not the same question. Building on open-source Eliza code does not require any relationship with the DAO, the Foundation, or Eliza Labs, and does not expose a developer to the migration dispute at the center of the lawsuit. It does mean inheriting a project whose leadership is currently defending its past marketing claims in the Southern District of New York, with no ruling yet on the merits, and whose community has openly debated, in public developer channels, whether the token itself still gives holders any real claim on the software’s direction.
Where Regulators Stand
Eliza’s original sin, according to the class action, is the gap between “autonomous AI investment agent” as a marketing claim and a much more human-operated reality underneath. That exact gap is what US regulators have started to probe, separately from the lawsuit. On March 17, 2026, the SEC and CFTC jointly issued a formal interpretation applying the Howey test to digital assets, explicitly classifying sixteen major crypto assets as digital commodities and setting out a five-category taxonomy for how the rest can be sorted, the first time the two agencies have coordinated a joint classification framework of this kind; HOGE Wire has covered the broader rulebook shift in detail in our explainer on the SEC’s new crypto ETP and market structure rules. That framework does not name AI agent tokens specifically, but its emphasis on how a token is marketed and sold, not just what it technically is, maps directly onto the ai16z dispute: a token can be marketed as powering an autonomous fund and treated very differently by regulators than one marketed as governance rights over open source software.
Agentic trading itself is now drawing separate scrutiny. Representatives Bill Foster and Brad Sherman, both Democrats on the House Financial Services Committee, sent SEC Chair Paul Atkins a letter demanding written answers by July 31, 2026, on what oversight exists as brokerages roll out AI agents that trade on behalf of retail customers, following Robinhood’s May 2026 launch of agentic trading and Coinbase’s own agent product the following month, according to the lawmakers’ own release. Nothing in that letter is Eliza-specific, but any framework whose agents are designed to hold keys and move funds without a human approving every step sits squarely inside the question Congress is now asking the SEC to answer.
A Builder’s Checklist Before Choosing Eliza
For a developer actually deciding whether to build on Eliza today, most of the ai16z drama is noise. What matters is whether the framework fits the job, whether the specific plugins involved are trustworthy, and whether the team has the operational discipline to keep an agent’s permissions narrow. The questions below are the ones worth working through before writing the first line of a character file.
- Plugin provenance: does every plugin the agent loads come from a reviewed, first-party source, or from an unaudited community contribution that could introduce a memory-injection vector?
- Key management: does the agent’s wallet key sit in a trusted execution environment through plugin-tee, or in plaintext memory the model’s own reasoning loop can access?
- Token dependency: confirm that self-hosting the framework does not require holding or interacting with ELIZAOS at all, which insulates a project from the token’s volatility and legal overhang.
- Maintainer bandwidth: an 18,800-star repository still depends on a defined core team; check recent commit and release activity rather than assuming scale equals stability.
- Use case fit: consumer and gaming applications like Clawville carry a fundamentally different risk profile than an agent authorized to move funds in DeFi, which is where the published attacks have concentrated.
- Legal exposure by association: building on the open-source code does not entangle a project in the Pikabea litigation, but branding decisions that lean on the ai16z name specifically inherit reputational baggage the framework itself does not carry.
What to Watch Next
Three things will say more about Eliza’s trajectory over the next two quarters than the token’s price chart. First, whether Agentic SME actually ships its promised 30-day initial build and three-month full release on schedule, and whether Secure Blockchain finds paying SME customers rather than just a press release. Second, whether the Magic Fund’s portfolio grows beyond Questflow into a genuine ecosystem of funded teams, which would be the clearest sign the framework can generate value independent of any single flagship application. Third, how the Pikabea litigation proceeds through the Southern District of New York, since discovery could surface exactly how much of the original autonomous-trading claim was real, a question that matters for the next AI agent project marketed the same way, not just this one. A fourth, quieter signal worth tracking is developer retention: whether the contributors who kept shipping through 2025’s price collapse are still committing code a year from now, since that kind of unglamorous persistence, more than any single funding announcement, is usually what separates infrastructure that lasts from infrastructure that was just first to market.
The more interesting story here is not that the ai16z token collapsed. It is that the code it left behind did not need the token to keep finding new users, from game studios to a small-business software vendor. Whether that is enough to build a durable open-source project, rather than just a durable meme, is still an open question, and it is one that will be answered by shipped software rather than by anything that happens to the price of ELIZAOS.
Frequently Asked Questions
What is the Eliza framework?
Eliza is an open source, MIT licensed TypeScript framework for building AI agents that keep memory, call external tools, and operate across platforms like Discord, Telegram, and X from a single character definition. It was created by developer Shaw Walters and is maintained through the elizaOS GitHub organization, and it does not require holding any token to use. Its four core building blocks, actions, providers, evaluators, and services, let a developer bundle new capabilities into an agent as plugins rather than rewriting the agent from scratch.
Is ai16z the same thing as elizaOS?
Not exactly. ai16z was the original token and branding launched in October 2024 around an autonomous trading agent built on the Eliza framework. Under pressure from Andreessen Horowitz over use of its name, the project rebranded its token and community to elizaOS in 2025. elizaOS today refers both to that rebranded token and DAO and, separately, to the open source software framework and operating system layer, which has grown well beyond the original trading-agent use case and now underpins products that have nothing to do with trading at all.
Do you need to hold the ELIZAOS token to build an AI agent with Eliza?
No. The core Eliza framework is MIT licensed and free to clone, self-host, and extend from GitHub. Projects like the MMORPG Clawville and the enterprise product Agentic SME are built on the open source runtime without requiring users to hold or transact in ELIZAOS, though some ecosystem partners choose to stake or use the token voluntarily as part of a separate business arrangement.
Is it safe to let an Eliza-based agent hold a crypto wallet?
It requires care. Princeton and Sentient Foundation researchers demonstrated in 2025 that ElizaOS-based agents could be manipulated into sending funds to an attacker through fabricated memories injected via ordinary chat messages, and simple prompt-based safeguards were not enough to stop it. Since then, plugins that keep wallet keys inside a trusted execution environment and partnerships enabling cryptographically verifiable agent execution have reduced, though not eliminated, the risk, and plugin provenance remains the biggest single variable in how safe any given agent actually is.
How does Eliza compare to Virtuals Protocol’s GAME framework?
Eliza is a self-hostable, open source developer library with no token required to build on it, while Virtuals Protocol’s GAME framework is one part of a vertically integrated stack that bundles the agent framework together with a launchpad and a token and ownership layer. GAME leans toward a no-code, faster-to-launch experience for creators, while Eliza favors deep customization for developers willing to work directly with its TypeScript codebase.
Written by the HOGE Wire AI x Crypto desk.