Skip to main content

ElizaOS

ElizaOS — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

ElizaOS — an AI/Agents project (an open‑source framework and platform for AI agents), token (symbol: ELIZAOS).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: an open‑source framework and platform for building/running autonomous AI agents (CLI + web UI + plugins).
  • Who it’s for: developers and teams that want to quickly launch agent applications and extend them with plugins.
  • Why onchain/token: the project has a multichain token; no Tier‑1 justification of “why the token is critically needed for the product to work” was found.
  • What you can actually touch (Tier‑1): Quickstart: bring up an agent and open the web interface locally.

How it works (very briefly)

  1. The user does: installs the CLI, creates an agent project and specifies a model provider (for example, OpenAI).
  2. The system does: starts the agent runtime (memory/actions/plugins) and brings up a local web interface.
  3. The user gets: a working agent that can be talked to via the web UI and whose functionality can be extended with plugins.
  4. Where the blockchain is: the onchain part in Tier‑1 is represented by the token (contract addresses on several networks).
  5. Token role (if any): the tokenomics/release schedule are described, but the utility role of the token for the core product requires separate verification per Tier‑1.

Quick links: AI thesis fit

Project passport

Field Value
Project name ElizaOS
Also known as (aliases) ai16z | elizaOS
Logo (logo) ../assets/442_ai16z_logo.svg
Token symbol (ticker) ELIZAOS
Category AI/Agents
Primary chain (chain) Solana
Type non-EVM
Network status mainnet
Consensus (consensus) PoS (Solana)
Launch date (launch_date) —
Project status (status) active
Token (standard) SPL
Token contract DuMbhu7mvQvqQHGcnikDgb4XegXJRyhUBfdU22uELiZA
Token model (token_type) —
Max supply 11,000,000,000
Issuance —
Tokenomics (tokenomics, brief) migration: ai16z → elizaOS; multichain addresses
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) agentic framework (memory/actions/plugins)
Use‑case (use_case) build + run autonomous AI agents
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 3 / 1 / 0 / 2
Last verified 2026-02-11

General project overview

ElizaOS is an open‑source framework and platform for developing autonomous AI agents. Per Tier‑1 sources, the project includes a CLI for a quick start, an agent runtime (memory/actions) and a web interface for communication and management. The platform claims a modular architecture and extension via plugins (connectors, integrations, additional features).

Features/modules

  • CLI: creating/running agent projects without the need to edit the core repository.
  • Web UI: a local interface for communicating with and managing the agent.
  • Plugins/integrations: extension via a registry and connection to external services.
  • Memory and state: claimed as part of the agent’s runtime model.

Typical scenarios

  • Scenario 1: a developer creates an agent via the CLI → gets a locally running bot with a web interface.
  • Scenario 2: a team builds an agent application with plugins → connects the needed integrations and deploys.
  • Scenario 3: a developer writes their own plugin → adds custom actions/providers.

Getting started (wallet/network)

  • What you need: Node.js + bun (for the CLI), an API key of a model provider (the example in the Quickstart — OpenAI).
  • Network/chain: a blockchain is not mandatory for the core product; the explicit onchain part — the token and its addresses.
  • Fees: costs of using the model (at the chosen provider) and the deployment infrastructure; onchain fees — only when interacting with the token.

Architecture/tech (non‑AI)

  • Components: CLI (creating/running projects), agent backend/runtime, web client (UI), plugins/registry (extensions), state/memory storage (depends on the DB chosen in the project).
  • Participant roles: developers (create projects/plugins), operators (deploy and maintain the agent), users (interact with the agent via UI/API).
  • Where logic runs: offchain (locally/on a server/in a container): the agent runtime and the web UI. Onchain components in Tier‑1 are described separately as the token (contracts on different networks).
  • Dependencies: model providers (for example OpenAI/others), the chosen DB/storage for memory, deployment infrastructure; when working with the token — the RPC of the chosen network.

Token/economics (expanded, no forecasts)

  • Token utility: per Tier‑1, information about contract addresses/standards and the release logic is available; the utility role of the token in the core product (payment/access/incentives) is not established per Tier‑1.
  • Protocol necessity drivers: — (no Tier‑1 argument that “the product does not work without the token” was found).
  • Who pays fees: users bear the costs of models (at the providers) and infrastructure; onchain fees are paid by those who make transactions with the token.
  • Where fees go: — (not established per Tier‑1).
  • Issuance/burn: — (not normalized per Tier‑1 in this card; see tokenomics in links_*/Evidence).
  • Security/incentive mechanisms: — (not established per Tier‑1).
  • Distribution and token issuance schedule: there are mentions of vesting/transparency and supply expansion in the tokenomics (see links_*/Evidence).
  • Treasury: — (not established per Tier‑1).

Governance

  • Who makes decisions: — (not established per Tier‑1).
  • How protocol parameters change: via updates of the code (repository) and documentation; changes to the token/contracts — per the rules of the respective networks.
  • Where decisions are discussed/made: GitHub (issues/PR/releases) and community channels (see links_*).
  • Keys/multisig: — (not established per Tier‑1).

Security and incidents

  • Audits: — (there is no Tier‑1 link to an audit report in links_*).
  • Bug bounty: — (there is no Tier‑1 link to a program in links_*).
  • Incidents: — (not established per Tier‑1).
  • Threat model: the main risks — leaks of secrets/keys of model providers, vulnerabilities in plugins and the supply chain, misconfiguration of the environment/DB. Separate onchain risks appear only when interacting with the token.

Project status and timeline

  • Current status: active (there is a public repository, releases and documentation).
  • Key releases/milestones: — (not normalized).
  • Roadmap: see links_* (roadmap repository).

Ecosystem/integrations

  • Integrations: plugins and connectors (including for social networks/messengers and blockchains — as claimed in the Tier‑1 description), connection of model providers, databases for memory.
  • Partners: — (not established per Tier‑1).
  • Where it’s actually used: — (cases/examples of production use require separate verification per Tier‑1).

AI component of the project

  • What is real AI here? AI agents as applications: the runtime orchestrates the agent’s work (memory/actions) and connects model providers via configuration/plugins.
  • What is truly onchain? In Tier‑1 sources, the onchain facts relate to the token (contract addresses on several networks).
  • Why is a token needed? No Tier‑1 wording “the product/protocol does not work without the token” was found.
  • Red flags (based on the information found): token‑washing (if the token is positioned as a “must‑have” without Tier‑1 utility artifacts); it is important to separate “framework” from “decentralized protocol”.

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality high 3
Onchain necessity low 1
Token necessity low 0
Evidence Tier‑1 present (AI/OC/TK) 2
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): the intent flag is not needed: Tier‑1 contains a description of the product as an AI‑agent framework.
  • Evidence: Tier‑1 — https://github.com/elizaOS/eliza
  • Why sufficient / why not (one line): AI_0 applies in the absence of AI reality; here AI agents are the main subject of the product.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): the platform is intended for building and running AI agents (AI‑powered applications).
  • Evidence: Tier‑1 — https://github.com/elizaOS/eliza
  • Why sufficient / why not (one line): the Tier‑1 README describes ElizaOS as a framework for AI agents with a web UI and CLI.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): the Quickstart describes launching an agent and the web interface (localhost:3000).
  • Evidence: Tier‑1 — https://docs.elizaos.ai/quickstart
  • Why sufficient / why not (one line): there is a reproducible step‑by‑step guide “create → start → open the UI”.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): no Tier‑1 block with measurable quality metrics/benchmarks was found.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 1
  • Claim (one line): the platform components (CLI, web UI, architecture overview) and the launch procedure are described.
  • Evidence: Tier‑1 — https://github.com/elizaOS/eliza ; Tier‑1 — https://docs.elizaos.ai
  • Why sufficient / why not (one line): there is a tech description and the repository structure + docs navigation.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Solana + EVM (Ethereum/Base/BSC)
  • Addresses/identifiers: SPL: DuMbhu7mvQvqQHGcnikDgb4XegXJRyhUBfdU22uELiZA; EVM: 0xea17Df5Cf6D172224892B5477A16ACb111182478
  • Evidence: Tier‑1 — https://docs.elizaos.ai/tokenomics
  • Why sufficient / why not (one line): the Tier‑1 tokenomics provides the contract addresses and token standards.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 0
  • What useful logic is onchain: other than the token, no Tier‑1 confirmation of “useful logic onchain” was found.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): per the available Tier‑1 artifacts, the onchain part is expressed by the token.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the core functions of the framework (CLI/runtime/UI) can work without a blockchain; no Tier‑1 criticality test was found.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): there is no Tier‑1 claim that blockchain properties are critical for the core product.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, elizaOS, with addresses on several networks.
  • Evidence: Tier‑1 — https://docs.elizaos.ai/tokenomics
  • Why sufficient / why not (one line): Tier‑1 contains the contract addresses and supply.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): No Tier‑1 confirmation that “the token is used to pay for the product’s service” was found.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): the tokenomics page describes the addresses/supply and the release, but does not prove that payment for services with the token is mandatory.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 0
  • Claim (one line): No Tier‑1 confirmation of incentives/collateral/penalties via the token was found.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): a Tier‑1 document with the protocol/incentive economics is needed.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): No Tier‑1 confirmation of a governance function of the token was found.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): a Tier‑1 artifact/description of governance via the token is needed.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): no conclusion about the replaceability of the token is drawn without a Tier‑1 justification.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): a Tier‑1 utility model of the token is needed.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://github.com/elizaOS/eliza Tier‑1 description of the product: a framework/platform to build/deploy AI agents (CLI + web UI + plugins).
Tier‑1 https://docs.elizaos.ai/quickstart A reproducible Quickstart “create a project → start → open the web UI” (AI_2 demo sync).
Tier‑1 https://docs.elizaos.ai/tokenomics Token contract addresses (SPL/EVM) and total supply.
Tier‑1 — No Tier‑1 source for claim “the ELIZAOS token is mandatory/needed for payment/incentives/governance of the product” was found.

No comments to display

Back to top