ElizaOS is an open-source TypeScript framework for building AI agents that can post on social platforms, call APIs, and act onchain. Its documentation describes it as "the TypeScript framework for building AI agents that think, learn, and act autonomously," with more than 90 plugins covering Discord, Twitter, Telegram, Ethereum, Solana and OpenAI (elizaOS docs). Developers define an agent's personality and behavior in a character file, then add plugins for the services it should use.
​

This article explains what elizaOS is, how its pieces fit together, what onchain actions look like, and which questions to settle before an elizaOS agent holds funds.
​

ElizaOS is a framework, not a single agent. It gives developers a runtime, a character file format, and a plugin system for connecting an agent to models, chat clients, and blockchains. The project states that "every line is open source," so teams can run and modify it on their own infrastructure rather than through a hosted service.
​

The framework sits in the same category as other agent toolkits such as Solana Agent Kit, which focuses only on Solana protocols (Solana Agent Kit). ElizaOS is broader: social presence, data analysis and onchain actions in one runtime. The docs list trading onchain, managing social media, creating content and calling "any API, blockchain, or repository" among its uses (elizaOS docs).
​

ElizaOS works by combining three layers: a character file that defines the agent's identity and style, a model provider that generates responses and decisions, and plugins that turn decisions into actions. The runtime routes messages from clients such as Discord or Telegram to the model, then executes whatever plugin action the model selects.
​

Agents start "with a character file," per the docs (elizaOS docs). The file holds the agent's name, background, example messages and style rules. It shapes tone and topic, but it is instructions to a model, not an enforcement layer.
​

Plugins connect the agent to outside systems. Chat plugins handle where the agent talks. Model plugins pick the language model. Blockchain plugins for chains such as Ethereum and Solana let the agent read balances and submit transactions from a wallet it controls.
​

An elizaOS agent can read onchain data and submit transactions through blockchain plugins, such as transfers and token swaps, using a wallet configured for it. What it can actually do depends on which plugins are installed, which wallet keys it holds, and what checks the developer adds before a transaction is signed.
​

That last point is the design decision that matters. A character file can tell the agent to stay within a budget, but model instructions can be misread or overridden by injected text in a post the agent reads. Limits that must hold belong in code the model cannot rewrite: a separate wallet holding only what the agent may spend, a policy check before signing, or conditions written into the transaction itself. For the control options, see AI agent spend controls and agent wallets.
​

ElizaOS differs from chain-specific toolkits by covering social clients, models and multiple chains in one framework. Solana Agent Kit goes deeper on one chain's protocols. Fetch.ai's uAgents focuses on agent-to-agent communication and a marketplace. The right choice depends on whether the agent mainly talks, mainly trades, or mainly coordinates with other agents.
​

See Solana Agent Kit explained and Fetch.ai autonomous agents for those toolkits.
​

Yes. The elizaOS documentation says every line of the framework is open source, and the project is developed in public. Teams can self-host the runtime, inspect the plugins they install, and modify behavior, which matters when an agent will hold keys or move funds.
​

Open source means the code is inspectable. It does not mean any given plugin has been reviewed for a team's use case, so teams that connect a wallet should read the plugin code that signs transactions. For the market context around agent projects, see top AI agent crypto projects.
​

Getting started with elizaOS takes three commands, according to the official docs: install the CLI with bun i -g @elizaos/cli, create a project with elizaos create, and run it with elizaos start (elizaOS docs). From there, the work is configuration: writing the character, choosing a model provider, and adding plugins.
​

A sensible first build follows this order:

ElizaOS is organized around a runtime that manages agents, memory, plugins and messaging. The docs describe three properties the project emphasizes: a plugin system with more than 90 plugins, "Persistent Memory: Agents remember and learn from every interaction," and "Deploy Anywhere: Local, Docker, Eliza Cloud, or your own infrastructure" (elizaOS docs).
​

The docs also include guides on multi-step action planning, background tasks, and TEE integration (elizaOS docs). Running an agent inside a trusted execution environment is one way to reduce the risk of key exposure on the host, though it does not limit what the agent itself decides to sign.
​

Persistent memory is useful because an agent can learn a user's preferences and context over time. It also means that text the agent read once can influence what it does later. If a post the agent read contained a hidden instruction, and that text was stored, the instruction could resurface in a future decision.
​

Three habits reduce that risk:

For a wider view of these risks, see security risks of autonomous AI agents.
​

ElizaOS supports agents that "trade onchain, manage social media, create content, analyze data, or interact with any API, blockchain, or repository," per the docs (elizaOS docs). In practice, builders tend to combine a social presence with one narrow onchain function. Common patterns:

Hard limits for an elizaOS agent belong in the wallet and the transaction, because the character file and the model can both be steered. There are three places to put them, and they stack.

The third layer is where Eco's Sauce SDK fits. A Sauce program reads onchain state, checks conditions such as minimum received or a price bound, and reverts the whole transaction if they fail (Sauce docs). Sauce also ships an MCP server and agent skills for coding agents (Sauce for AI agents). The rollback covers one transaction on one chain; approvals made earlier and network fees sit outside it.
​

Knowing these terms makes the docs easier to follow, and it makes design reviews sharper. When a team asks "what can this agent do," the answer should be a list of actions and the wallet they run against, not a description of the character.
​

The elizaOS docs include a token information page covering tokenomics, contract addresses and vesting (elizaOS tokenomics). The framework and the token are separate things: developers can build with the open-source framework without holding the token. Anyone looking at the token should read the project's own tokenomics page and treat it as a market asset with its own risks. This article does not assess its value.
​

TypeScript, per the official documentation.
​

Yes, through blockchain plugins and a wallet the agent controls. Limits should be enforced at the wallet or transaction level, not only in the character file.
​

A configuration file that defines an agent's name, background, example messages and style.
​

Install the CLI with bun, run elizaos create to make a project, then elizaos start, per the official docs.
​

Yes. The docs describe persistent memory so agents can use past interactions. Review what is stored if the agent reads untrusted content.
​

Locally, in Docker, on Eliza Cloud, or on your own infrastructure, per the docs.
​

No. The framework is open-source software. The token is a separate asset described on the project's tokenomics page.
​

You can run a default agent and edit its character without much code. Writing or reviewing plugins, especially any that sign transactions, needs TypeScript, since that is the language the framework is built in.
​

Sources: official documentation linked inline, accessed November 2026.
​