The Foundation's March 26, 2026 announcement says ICON entered economic shutdown: staking rewards and new emissions ended while the chain remained available for migration. It describes maintenance operation by seven core nodes. This supersedes evergreen pages advertising ordinary staking yields or a broad rewarded validator economy. The distinction matters for anyone encountering an old tutorial through search. A functioning explorer or transferable balance is not evidence that the earlier incentive system still exists or that the network is pursuing indefinite independent growth.

The May retirement notice announces December 31, 2026 as both the final migration deadline and the planned permanent chain halt, with a read-only archive intended afterward. It explains the Foundation's view that maintaining a separate L1 now divides resources from its cross-network products. This is a published lifecycle decision, not a claim that shutdown has already happened. As of the September review, ICON remains a network in transition, and the existence and completeness of the promised archive must be checked when that later milestone arrives.

The mainnet announcement records genesis on January 24, 2018 at 18:25 UTC. It follows the project's earlier formation and describes further monitoring before the public wallet opening. This makes genesis a more precise network milestone than treating every mention of a 2017 launch as the start of public block production. The original ambition was broad connectivity between communities and applications. The announcement also acknowledged how much remained to build, which is more informative than retrospectively portraying the full interoperability stack as complete on day one.

ICX initially existed as an ERC20 token before a 2018 swap to the native blockchain asset. The technical introduction describes its historical roles in transaction fees, delegated governance and applications such as lending or collateralized stablecoins. Those uses explain why ICX belongs to ICON's own history rather than being a generic cross-chain dollar. Its later exchange for SODA is another asset transition, not proof that an old Ethereum representation, native ICX and a Sonic token are the same contract or require the same transaction fuel.

The November development retrospective dates the completed ICON 2.0 mainnet upgrade to November 4, 2021. It describes a Go-based engine and preparation for Java contracts, while separately stating that Java support and a revised fee policy still required activation work. Preserving that distinction avoids assigning every advertised capability to the engine's launch date. The same report discusses integrations at different testing stages. A testnet connection to another chain was a development milestone, not automatically an operational public bridge.

The execution documentation describes Java and an older, deprecated Python environment. It also explains state through both a Merkle Patricia Tree and an object graph. This is ICON's own execution architecture, not an EVM chain simply because it communicates with Ethereum-compatible networks. Developers interacting across chains must accommodate different contract environments and transaction formats. The ability to send a message between systems does not mean a contract's compiled code can be copied unchanged from one to the other.

STEP is a unit of computational effort rather than a second freely traded network token. A transaction's operations consume steps, and the step price expresses the payment in ICX. The fee guide describes governance's ability to adjust that price. This separates the amount of work from the market value of the asset paying for it. A quoted historical fee should therefore not be treated as an immutable fiat price, particularly when contract complexity and approved parameters differ between examples.

The legacy xCall fee guide separates relay compensation from the protocol fee and describes an additional return-direction charge when rollback is requested. It also documents an administrator's role in setting the protocol component. Its burn mechanism belongs to the economic design described at that time; it is not evidence that today's SODAX fees follow the same ICX path. For a historical account, the important point is that communication has several costs and authorities, rather than a single universal fee paid identically on every connected network.

The February 2024 engineering update explicitly distinguishes xCall's common message interface from the protocols carrying those messages. It reports adapters for Wormhole and LayerZero, alongside work using IBC and BTP. A builder could reuse an application interface while choosing underlying connections, potentially combining them. That modularity is useful, but it should not collapse the security assumptions of all transports into one claim. A shared API does not make every relay, verification rule or remote chain identical.

The message-lifecycle guide describes separate initiation, relay, destination execution and error handling. An application sends a call, responds to an event on the destination and may request a return path for rollback after failure. This is an asynchronous process spanning independent systems. Seeing the first transaction succeed is not the same as seeing the target application's action complete. Applications need to follow the relevant events and handle failures rather than treating cross-chain execution like an ordinary single-chain atomic call.

ICON's consensus introduction describes delegated proof of stake: elected delegates propose blocks and other validators evaluate them. That gives token voters an indirect route into choosing infrastructure operators. It does not mean every holder directly participates in every consensus round. This description explains the network's earlier operating model; the later maintenance set belongs to a different lifecycle phase. Historical decentralization claims should be assessed against the operator set at the relevant date rather than carried forward automatically.

The validator guide distinguishes the wallet managing a validator from the node key used for signing. It also describes chain registration and explicit node-public-key registration. These operational boundaries show that possessing delegated voting power is not enough: someone must synchronize, secure and maintain the actual machine. Public registration data can identify a validator's declared role, but not independently establish whether several validators share infrastructure or management.

The guide remains useful for understanding historical operations without being a recommendation to launch a new rewarded validator during retirement.

The network-proposal schema includes revisions, step prices, reward allocations and designated system-contract updates. It also includes freezing a malicious SCORE contract and disqualifying a validator. These are substantial governance powers, not merely opinion polls. Understanding their existence helps explain both the capacity to respond to faults and the trust placed in the decision process. A formal proposal type does not tell us which particular motion passed; that requires its own voting and execution record.

The IISS 4 discussion makes the social side visible. The proposed policy tied rewards more closely to active validation and contemplated stronger penalties. Geo_Dude and Robi7 objected to discretionary confiscation, arguing that political decisions could exceed what objective protocol faults justified. Others distinguished existing disqualification powers from proposed monetary penalties. This is a historical disagreement about governance legitimacy, not evidence that every suggested penalty was activated.

The thread is valuable precisely because contributors disagreed about which protections should be implemented in code.

The Contribution Proposal System was designed to make grant applications and validator decisions publicly inspectable. Its guide describes a wallet-based application process and payments denominated in bnUSD instead of exposing every approved budget directly to ICX price movements. A stable denomination can help planning, but it is not a guarantee of a token's peg or successful project delivery. The guide's old issuance percentages are historical context, not a current funding schedule after emissions ended.

HX57, announced in September 2021, offered bounties for explanations, tutorials, graphics and other original community material. The Foundation selected winners, and promotion involved Eye on ICON and ICON Pinas. This provides concrete evidence of a culture that rewarded communication as well as software development. It also explains why some enthusiastic material should be understood as commissioned ecosystem promotion. The existence of a historical bounty program does not establish that its website or reward schedule remains active today.

The May 2025 SODAX proposal described shifting the hub infrastructure to Sonic, combining DeFi functions and concentrating economic activity in a new token. Its stated rationale was to reduce the cost of running an independent L1 and focus resources on applications and liquidity. That is the Foundation's strategic argument, rather than proof the new arrangement must outperform the old one. It changes the object of the investment thesis: success would depend on execution and demand for a cross-network service, not simply more activity on ICON's original chain.

A September 2025 proposal sought one authorization to escrow and migrate network-owned liquidity in phases, instead of a separate vote for each tranche. The stated aim was an orderly move with enough liquidity for partners. It also leaves timing and batch sizes to operational judgment. The record therefore shows a governance tradeoff between repeated approvals and delegated execution. The proposal itself does not reconcile the final balances or certify that every asset moved exactly as planned.

The September 15, 2025 test-migration announcement describes moving from ICX on ICON to SODA on Sonic, initially in both directions. It explicitly says staking and liquidity pools were not yet available in that early phase. This dated account is useful for the sequence of rollout, but its reverse-migration instructions have been superseded. It also shows why wallet support and network selection mattered independently of an exchange ratio: the destination balance was held on a separate blockchain with its own native transaction asset.

The initial governance proposal requested authorization for SODA issuance and a five-member board overseeing contract upgrades, distributions and migration actions. It separately outlined exchange-specific processing. This record establishes the proposed governance structure and its scope; it should not be read as proof that every exchange adopted the migration. Centralized custody involves the platform's own operational choices, whereas a self-custody contract transaction follows the supported on-chain route.

Neither a forum announcement nor a token listing substitutes for checking the actual service involved.

The March 2 roadmap separated the end of Balanced savings incentives, liquidity incentives and ICX emissions from the intended start of successor rewards. It also described removing the validator bond requirement. These were different transitions, not one instant renaming of all balances and income streams. The document explicitly warned that target dates could change. Its old statement that migration would remain two-way until further notice must be read as a time-limited announcement, not a permanent contractual promise.

The September 24 update brought the two-way cutoff forward to September 25, replacing the earlier September 30 date. It retained December 31 for the one-way migration deadline and planned shutdown. The Foundation cited thin ICX liquidity, volatile pricing and the aftermath of an exploit as its rationale. These are the publisher's explanations, not independent market-impact estimates. The article records the updated schedule rather than reproducing obsolete reverse-conversion steps or implying a centralized exchange will necessarily handle a holder's transition.

The December 2021 issuance postmortem reported that an ICON 2.0 bug produced roughly a month's intended issuance in one day. According to the team, the excess remained in the treasury and was not claimable through normal reward conversion. Revision 16 activated the correction on December 25, with subsequent issuance adjusted toward the expected total. This was a protocol-accounting failure with a documented correction, rather than evidence that every holder received an unexplained windfall.

The Foundation's August 2026 postmortem reports replayed migration withdrawals caused by inconsistent handling of a message serial number. It distinguishes 119.866 million gross ICX released from its reported confirmed net loss of about 150.2 ETH and 31,204 USDC; other amounts were recovered or remained subject to exchange freezes and investigation. It says the assets were Foundation-held, with user positions not accessed. ICON was nevertheless halted and resumed August 28 after roughly 25 hours.

The publisher acknowledges an audit had missed the defect and that alerts did not produce fast enough intervention. These are attributed findings, not an independent certification of final recoveries or universal user safety.

ICON's own security guide cautions that an audit cannot discover every weakness and that fixes depend on correct implementation. It recommends review, analysis and repeatable development practices rather than treating an audit as a warranty. That remains a useful lesson when reading the network's history. A source can document careful engineering and still coexist with a later incident. The proper question is what a review covered, what was deployed and which assumptions remained outside its scope.