Skip to main content

IoTeX

IoTeX (IOTX) — 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).

IoTeX — an L1 blockchain that is positioned in the official documentation as infrastructure for DePIN and real‑world AI applications. The native token of the network is IOTX.

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 L1 blockchain and a set of infrastructure modules for applications around devices/data (DePIN).
  • Who it’s for: dApp/DePIN developers, ecosystem users, delegates/validators and stakers.
  • Why onchain/token: onchain records transactions and the state of smart contracts, while IOTX is needed for fees, staking and participation in governance.
  • What you can actually touch (Tier‑1): QuickSilver (docs + application) with step‑by‑step tutorials “create your first agent” / “interacting with agents”.

How it works (very briefly)

  1. The user does: sends transactions and interacts with smart contracts.
  2. The system does: blocks are finalized via Roll‑DPoS (DPoS + PBFT + VRF).
  3. The user gets: confirmed onchain state and contract events.
  4. Where the blockchain is: transactions/smart contracts/consensus of the IoTeX network — onchain.
  5. Token role: IOTX — gas/fees, staking and voting for delegates.

Quick links: AI thesis fit

Project passport

Field Value
Project name IoTeX
Also known as (aliases) IOTX
Logo (logo) ../assets/34_iotex_logo.svg
Token symbol (ticker) IOTX
Category AI/Other | Infra
Primary chain (chain) IoTeX
Type EVM
Network status mainnet
Consensus (consensus) Roll-DPoS (DPoS + PBFT + VRF)
Launch date (launch_date) 2019
Project status (status) active
Token (standard) native
Token contract —
Token model (token_type) utility (gas + staking + governance)
Max supply 10,000,000,000 IOTX (max supply)
Issuance inflationary + burn (described in docs/tokenomics)
Tokenomics (tokenomics, brief) IOTX is used for fees/staking/validation and voting; IoTeX 2.0 describes the goal of balancing inflation and usage‑based burn
Governance —
Admins/keys —
Audit —
Bug bounty yes
Team (team) —
Funding (investors/funding) —
AI component (ai_component) real-world data context for AI apps
Use‑case (use_case) DePIN L1 + verifiable computing modules
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 3 / 3 / 3
Last verified 2026-02-11

General project overview

IoTeX is an L1 blockchain that is positioned in the official documentation as infrastructure for DePIN and real‑world AI applications: the idea is that events and data from the physical world (devices/networks) are linked to onchain logic and economics. The documentation lists at least four “pillars”/constituents: IoTeX L1, the ioID identity, the W3bstream computation/attestation layer and the QuickSilver AI interaction/context layer.

Features/modules

  • IoTeX L1: smart contracts and transactions on its own network.
  • Roll‑DPoS: consensus with DPoS + PBFT + VRF (a random committee and fast finality).
  • IOTX token: fees (gas), staking and participation in governance (voting for delegates).
  • DIMs (DePIN Infra Modules): infrastructure modules around real‑world data (the docs mention W3bstream, ioID, QuickSilver, etc.).

Typical scenarios

  • Scenario 1: a user calls a dApp smart contract → pays the fee in IOTX → the transaction is finalized by the network.
  • Scenario 2: a staker locks IOTX/delegates and votes for delegates → receives rewards (the mechanics are described in the docs).
  • Scenario 3: a developer builds a DePIN/IoT application and uses the IoTeX infrastructure layers (per the documentation).
  • Scenario 4 (AI/agent demo): a developer sets up an agent in QuickSilver and interacts with it (the “interacting with agents” example) with a link to the onchain context of the ecosystem.

Getting started (wallet/network)

  • What you need: an EVM wallet/tools for interacting with smart contracts and access to an RPC/explorer.
  • Network/chain: IoTeX (mainnet).
  • Fees: gas in IOTX for transactions and contract calls.

Architecture/tech (non‑AI)

  • Components: L1 network nodes, smart contracts and infrastructure DIM modules around the network.
  • Participant roles: users, developers, delegates/validators, stakers/voters.
  • Where logic runs: the base logic of transactions/consensus/contracts — onchain; services around the network (indexing/infra) — offchain.

Token/economics (expanded, no forecasts)

  • Token utility: IOTX is paid for transactions/smart contracts; it is used for staking/rewards and voting for delegates.
  • Issuance/burn: the tokenomics describe the goal of balancing inflationary rewards and deflationary burn mechanisms as usage grows; the utility also describes a Burn‑Drop mechanism (in the context of device registration).

Governance

The official documentation explicitly lists IOTX as the token that is staked for participation in governance (including via voting for delegates).

Security and incidents

  • Bug bounty: a public program (link in links_*).
  • Audits/incidents: Tier‑1 reports/post‑mortems have not been established; if necessary — check further via security advisories and the repositories.

Project status and timeline

  • Current status: mainnet.
  • Key milestones: IOTX is listed in the docs as the token introduced in 2019 for IoTeX L1.
  • Roadmap: there is a Tier‑1 publication with a roadmap for W3bstream (see links_*).

Ecosystem/integrations

  • Integrations: ecosystem dApps and DIM modules around IoTeX (a separate selection of specific examples is needed).

AI component of the project

  • What is real AI here? The documentation has positioning for real‑world AI and the QuickSilver AI layer; Tier‑1 confirms reproducible demo steps (creating an agent and interacting with agents), but the extracted Tier‑1 contains no quality metrics/versions of a specific AI model of the project.
  • What is truly onchain? the L1 network (consensus/smart contracts/transactions) and the IOTX economics.
  • Why is a token needed? IOTX is needed for fees, staking and governance participation.
  • Red flags (based on the information found): AI‑washing (AI is declared broadly, but without metrics/artifacts of “AI quality”); what to double‑check — the specific technical details of QuickSilver/W3bstream and examples of “verifiable AI context” on working dApps.

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): AI modules are described in the docs as part of the product, not only as intent.
  • Evidence: Tier‑1 — https://docs.iotex.io/
  • Why sufficient / why not (one line): we apply AI_0 only when AI is exclusively a roadmap without working descriptions.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): the docs position IoTeX as a base for real‑world AI applications and describe the QuickSilver AI layer.
  • Evidence: Tier‑1 — https://docs.iotex.io/
  • Why sufficient / why not (one line): there is Tier‑1 wording about the AI layer/context, but without specifics of the model.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): QuickSilver has public instructions for creating and testing an AI agent and interacting via chat/the portal.
  • Evidence: Tier‑1 — https://docs.iotex.io/quicksilver/getting-started/create-your-first-agent, https://docs.iotex.io/quicksilver/getting-started/interacting-with-agents
  • Why sufficient / why not (one line): Tier‑1 describes a reproducible workflow “create → publish → interact with the agent”.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://docs.iotex.io/
  • Why sufficient / why not (one line): there are no quality metrics of the AI layer/models in the extracted Tier‑1.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): there is no extracted technical description of specific AI models/versions of the project.
  • Evidence: Tier‑1 — https://docs.iotex.io/
  • Why sufficient / why not (one line): without a version/architecture/artifacts — 0.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: IoTeX
  • Addresses/identifiers: public explorer of the network: iotexscan.io
  • Evidence: Tier‑1 — https://iotexscan.io/ ; https://docs.iotex.io/
  • Why sufficient / why not (one line): the network and onchain artifacts are accessible via the docs and the explorer.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: L1 consensus/blocks/smart contracts, not only token issuance.
  • Evidence: Tier‑1 — https://docs.iotex.io/blockchain/learn-iotex/core-concepts/consensus-mechanism
  • Why sufficient / why not (one line): the docs describe the operation of the consensus and the L1 logic.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without a blockchain, trustless finalization/execution of smart contracts and public verifiability of state are lost.
  • Evidence: Tier‑1 — https://docs.iotex.io/blockchain/learn-iotex/core-concepts/consensus-mechanism
  • Why sufficient / why not (one line): IoTeX is the network itself; replacing it with a DB breaks the meaning of an L1.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the IOTX token exists as the native currency of the IoTeX network.
  • Evidence: Tier‑1 — https://docs.iotex.io/blockchain/learn-iotex/the-iotx-token
  • Why sufficient / why not (one line): the docs describe IOTX as the native token of the network.
  • Conflict note (if any): —

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): IOTX is paid for transactions and smart contract calls (fees).
  • Evidence: Tier‑1 — https://docs.iotex.io/blockchain/learn-iotex/the-iotx-token
  • Why sufficient / why not (one line): the Transaction fees section describes fees in IOTX.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): IOTX is used for staking/rewards and includes Burn‑Drop mechanics.
  • Evidence: Tier‑1 — https://docs.iotex.io/blockchain/learn-iotex/the-iotx-token
  • Why sufficient / why not (one line): the token utility lists rewards/staking and burn‑drop.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): token holders stake IOTX to vote for delegates (governance).
  • Evidence: Tier‑1 — https://docs.iotex.io/blockchain/learn-iotex/the-iotx-token
  • Why sufficient / why not (one line): the token utility includes “Delegate Election… vote for delegates”.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): as the native gas/staking/voting token, it is not replaceable without changing the protocol.
  • Evidence: Tier‑1 — https://docs.iotex.io/blockchain/learn-iotex/the-iotx-token
  • Why sufficient / why not (one line): the token utility is built into the operation of the network.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.iotex.io/blockchain/learn-iotex/core-concepts/consensus-mechanism the Roll‑DPoS consensus and the onchain design of the L1
Tier‑1 https://docs.iotex.io/blockchain/learn-iotex/the-iotx-token max supply and the utility of IOTX (fees/staking/governance/burn‑drop)
Tier‑1 https://docs.iotex.io/readme/tokenomics IoTeX 2.0 tokenomics: balancing inflation and usage‑based burn
Tier‑1 https://docs.iotex.io/quicksilver/getting-started/create-your-first-agent QuickSilver: step‑by‑step launch of an agent (sign-in, creation, testing, publishing)
Tier‑1 https://docs.iotex.io/quicksilver/getting-started/interacting-with-agents QuickSilver: ways of interacting with agents (global chat / agent-specific chat)
Tier‑1 https://hackenproof.com/iotex/iotex bug bounty program

No comments to display

Back to top