Raullen Chai's retrospective dates IoTeX's beginnings to 2017 and its mainnet start to April 22, 2019. The original ambition joined blockchain with trusted computing so machines could exchange information and value. That history explains why sensors, device ownership and data provenance recur throughout the project. It does not mean every later application runs entirely on the blockchain. The ledger is one component in systems that also depend on physical hardware, software services and the reliability of whatever observations they receive.

Mainnet General Availability followed on June 1, 2020. The launch FAQ describes moving staking and voting from Ethereum onto IoTeX itself, alongside native staking and reward tooling. This is an important identity boundary: IoTeX is not an Ethereum rollup merely because an early token and voting system used Ethereum. Historical ERC20 representations, native network balances and later bridged representations belong to different operational contexts. A token name without the chain and contract is inadequate evidence of what a wallet actually owns.

Roll-DPoS combines delegate selection with randomized committees and Byzantine fault tolerant voting. Token-weighted participation helps choose the candidate pool; committee members then propose and approve blocks. The consensus documentation describes finalization after a supermajority agrees. Random selection changes who performs the next round of work, but it does not eliminate the consequences of concentrated stake, shared infrastructure or coordinated operators.

Its security argument should be evaluated through the actual participants and software rules, not the word decentralized in isolation.

Staking gives holders a route into delegate elections and network governance. The documented arrangement connects participation with rewards, but a reward is compensation under protocol and delegate rules, not a fixed savings rate. Choosing a delegate also makes an operational judgment: someone must maintain a node, respond to upgrades and remain available. The existence of many staking accounts does not itself demonstrate many independent operators. Conversely, holding liquid IOTX without staking is different from taking part in an election.

IOTX is the native asset used to pay for transactions and smart-contract execution. It also provides stake for validator participation and delegate voting. Those uses explain a connection between the asset and the network, without establishing a guaranteed relationship between application announcements and its market price. The token documentation warns that its economics are being updated and contains a broken onward link. Consequently, its static supply table is not treated here as a fresh circulating-supply measurement or an audited accounting statement.

An NFT can represent a staking deposit, recording ownership and lock characteristics in a transferable asset. The documentation describes converting native staking buckets into that format and using them in other applications. Transferability offers a way to sell a position before its original lock expires, if a buyer exists. It does not force an exchange to provide liquidity or promise that the NFT sells for the full underlying amount. A staking right, the IOTX beneath it and a DeFi position using that right remain separate risks.

IoTeX accounts include key-controlled accounts and contract accounts. Its account documentation also describes an ERC-4337 implementation that lets a smart-contract wallet define authentication and execution rules. That makes features such as automated actions technically possible without making every user account autonomous. The wallet's actual permissions remain decisive. An application that can submit a transaction still needs authorization, and a helpful interface should make clear which key or contract can move assets or change future access.

ioID adds an identity framework specifically for machines and agents. The documentation combines an NFT-bound wallet on-chain with decentralized identifiers and verifiable credentials off-chain. This can connect a device's identity with payments or application participation. Identity and physical truth are different questions, however. Demonstrating that a particular machine signed a message does not independently prove that its sensor was correctly installed, its input was representative or its owner had permission to gather the data.

Applications still need a credible process around measurement.

Pebble Tracker illustrates the hardware side of the thesis. Its documentation describes GPS, environmental, movement and light observations that developers can feed into applications or supply-chain workflows. Device owners register hardware and connect it with an account; developers can adapt firmware and consume the resulting records. The useful distinction is between a signed observation and a business conclusion drawn from it.

A location report can be evidence in a delivery workflow without, by itself, proving ownership, contractual performance or the condition of everything inside a shipment.

Quicksilver supplies a different layer: a framework for agents using language models, external APIs and blockchain actions. The official guide describes publishing agents, charging for their use and connecting tools that retrieve data or trigger transactions. It also identifies conventional model providers and vector databases. This is an integration framework, not proof that the language model's answer is a consensus-verified fact. The trust boundary includes the model, tool access, data supplier and permissions of any action the agent is allowed to execute.

The March 2026 Anti-Roadmap acknowledges that proving a concept is different from proving a business. The team proposes beginning with camera-based perception and measuring whether customers pay for useful answers. It also says the core team's continued importance to upgrades remains a decentralization problem. These admissions make the document more useful than a checklist of distant launches. They describe management's chosen tests for progress, not proof those tests have already been met or that every registered device generates recurring revenue.

The June Trio announcement identifies two available perception products, Retina and Lumen, while explicitly placing prediction and action later in the sequence. Its examples include warehouses and other camera-equipped operations. Some worked scenarios describe the full desired system, so they should not override the page's more specific statement about which stages are shipping. The account here treats Trio as a product direction with released perception tooling, not as verified commercial deployment of every autonomous safety intervention pictured in the announcement.

IoTeX's February 23 report attributes the February 21 ioTube exploit to compromise of an Ethereum-side validator-contract owner account. The attacker upgraded that contract, bypassed verification and gained control over minting and reserves. The publisher reported about $4.4 million in reserve assets drained and 410 million unauthorized CIOTX minted. These are different measures and should not be added as though the entire face value of the minted tokens was an independently realized cash loss. The report separates this bridge failure from compromise of the L1 consensus mechanism.

That separation does not mean normal chain service continued throughout. The restart announcement states that mainnet resumed on February 24 at 06:06 UTC after delegates adopted v2.3.4. The patch blacklisted identified attacker addresses and froze associated funds at the network level. Coordinated intervention helped contain the incident, but it is also material evidence about administrative and social control. A reader assessing censorship resistance should understand both the stated emergency purpose and the fact that the network adopted special rules affecting particular addresses.

The compensation plan promises full reimbursement to eligible affected holders, with immediate treatment for smaller claims and quarterly distribution of larger remaining balances. Its eligibility rules exclude attacker-linked and specified exploit-related activity. The plan is evidence of the Foundation's commitment and proposed process; it is not an independent reconciliation of every claimant's payment. The page also mixes a March publication date with earlier February scheduling language.

Later operational statements are therefore preferable when determining whether the portal had actually opened.

The March 28 review says the claims portal opened March 2 and payouts were commencing. It also reports CIOTX deprecation across several external networks and describes a proposed ZK bridge as under community review. These specific statements are narrower than the same article's sweeping assertion that everyone was made whole. This account does not certify completion of all deferred compensation or a deployed replacement bridge. It preserves the distinction between an open claims process, reported protective measures and architecture still being developed.

The v2.4.0 release notes package the Yap changes: selected Ethereum Pectra features and a candidate exit queue. The queue requires requests, scheduling and confirmation rather than allowing every candidate to disappear immediately. It is meant to make exits visible and limit simultaneous withdrawals of operating stake. The implementation also uses IoTeX-specific execution parameters, including its calldata cost floor. EVM compatibility consequently means testing against the implemented rules, not assuming every parameter is identical to Ethereum's.

The later v2.4.1 maintenance release identifies concrete bugs in that new exit-queue code, including an archive-node panic and incomplete event handling. This illustrates why a successful feature announcement is not the end of protocol maintenance. Operators need follow-up fixes, while indexers and applications depend on reliable access to the resulting state and events. A release note documents what maintainers shipped and why; it does not prove every privately operated node has upgraded or every historical query has been independently checked.

Version 2.5.0 was published on September 28, 2026. Its Zanzibar notes describe protocol-native voter reward distribution under IIP-59, with testnet activations already recorded and mainnet activation scheduled later. The reviewed notes estimate October 19 and explicitly acknowledge a reschedule. As of this article's September review, those mainnet rules are future work. A voter should not infer that publication of the binary or earlier approval automatically changed how today's rewards reach a wallet.

The same design includes an opt-in path and a one-time migration for delegates using designated Hermes vaults with complete reward-portion metadata. Other configurations are treated differently. This matters because automatic distribution is not a universal promise that every existing delegate arrangement is migrated identically. The relevant evidence is the activation height, delegate configuration and resulting on-chain accounting. A proposed improvement in reward transparency still requires correct setup and successful operation to deliver the intended benefit.

The IIP process invites technical specifications, rationale, community discussion and documentation of dissent. Its governance guide points to versioned proposals and Snapshot voting. These are useful public records, but the stages should remain distinct: an idea can be discussed, a vote can approve it, maintainers can implement it and a chain can activate it at different times. A self-assigned number in a forum title is especially weak evidence of adoption. The content and status of the actual proposal need examination.

Marshall DAO is described as a proposed mechanism for allocating incentives to ecosystem initiatives. The current guide still labels it forthcoming. That is a limit on what this source establishes, not proof that no related experiment exists elsewhere. Its stated ambition is to let stakeholders compare projects and direct resources toward useful work. An incentive allocation should be judged by its actual funding decisions and outcomes, rather than treating the phrase meritocratic as evidence that every recipient has independently demonstrated value.

The April 2026 post-quantum update describes research, standards proposals and an SPP wallet on testnet. Its main theme is cryptographic agility: making a future transition possible without unnecessarily breaking existing applications. That is materially different from proving that every production IoTeX account, bridge or device is already resistant to every quantum attack. Research recognition and a usable test environment are milestones, but production security also requires deployed implementations, tested integrations and a credible migration process for existing users.