Three blockchain networks suspend operations amid security incidents

Written by: Liam ‘Akiba’ Wright

Compiled by Saoirse, Foresight News

Within four days, three blockchain networks sequentially halted block production. Each network outage invoked entirely different emergency powers, with only Cronos rewriting part of the official chain history.

Cronos stated that after the Tectonic protocol suffered a vulnerability exploit, the validator nodes used the consensus mechanism to shut down the network, rolled back the chain to its state prior to the attack, and resumed block production from block height 90,896,189. This action not only halted block production but also directly rewrote the chain state. All transactions and state changes generated after the recovery point are no longer part of the restored main chain.

Ontology and ICON adopted another set of emergency measures. Ontology suspended block production before confirming the malicious activity; its update on September 1 stated that the malicious activity did not result in any loss of user assets. ICON first paused the compromised smart contract and then shut down the entire network; the foundation stated that during the migration phase, it had control over the network, and most of the stolen ICX had already been transferred to exchange custodial accounts.

Blockchain downtime is merely a first-layer control measure. The deeper issue is: who has the authority to order a network shutdown? Can they rewrite the confirmed chain state? What losses become irreversible when funds are transferred across chains or deposited into centralized custodians?

Permissions for disclosing emergency measures triggered by network events have been restored; risk of CronosTectonic vulnerability attack led to network shutdown and restoration to the chain state prior to the vulnerability, with validator consensus verified; announcement of restart invalidated all on-chain activity after the tally data and voting threshold checkpoint; funds transferred to Ethereum are outside Cronos’s control; final loss statistics for the Tectonic protocol are still pending; Ontology’s routine inspection identified potential risks, later confirmed as malicious activity, prompting preventive suspension of block production without rollback; core development team, technical team, and validator nodes participated; emergency response trigger thresholds were not disclosed; transactions could not be executed during repair and network upgrade; no user asset losses were found; ICON migration contract had a replay vulnerability—contract was paused first, then the entire network was shut down; during migration, the network was under foundation control with a reduced number of core validator nodes; losses were borne by the foundation; whether ICX held on exchanges can be recovered depends on the custodian, legal procedures, and law enforcement agencies.

Comparison of emergency response methods for the Cronos, Ontology, and ICON blockchains

Cronos: From Downtime to Rewriting Chain State

Cronos referred to the incident response as a “Validator Consensus Emergency Action.” The restart announcement on August 31 stated that, at 23:49:01 UTC on August 30, the network resumed block production from block height 90,896,189, with the chain state rolled back to before the Tectonic vulnerability attack.

The downtime operation for Cronos entails making decisions on profit distribution for the recovery point. After the checkpoint, on-chain states related to the vulnerability, along with all unrelated transactions during that period, are erased from the official chain. The restart announcement did not include a list of transactions, validator node statistics, voting weight thresholds, or a list of participating nodes. Cronos has committed to releasing a post-incident review report that fully explains the handling process and the technical scope of impact.

The actual scale of assets protected by this intervention remains uncertain. TRM Labs estimates that approximately $75 million in assets were lent out after the TONIC token price was manipulated; of this, about $6 million flowed to Ethereum, and approximately $68.7 million was rolled back within the Cronos chain. Bitquery’s statistics, however, indicate a higher total outflow, with approximately $8.3 million flowing to Ethereum and a total of 10,961 blocks discarded.

The two statistical methods track different entities, and Tectonic’s official final loss figures have yet to be released. However, one point is already very clear: Cronos’s rollback can only restore states that remain on its own chain; assets on the Ethereum chain are completely beyond its control.

Tectonic’s asset disposition plan still leaves unresolved user account issues. The protocol stated it would prioritize enabling withdrawals and loan repayments, while suspending deposits and new borrowing. This plan provides users with a path to exit and deleverage, but it remains unconfirmed whether fund providers can fully redeem their assets. Tectonic’s upcoming post-incident report must clarify the vulnerability’s mechanism, total funds outflow, bad debt size, recovered assets, and remaining outstanding liabilities.

The recovery progress of various infrastructure components is not synchronized with the restart of the chain consensus. Cronos reminds users that protocols, cross-chain bridges, block explorers, and RPC services will require additional time to fully recover. Alchemy’s status page also separately documents this outage and subsequent restoration. While the chain network can be declared officially restarted, dependent services may not yet be fully operational.

Ontology: The downtime is solely to secure time for resolution and does not cancel the transaction.

The action taken regarding Ontology occurred prior to the confirmation of malicious activity. The network stated that the core development team identified potential security vulnerabilities during routine inspections, immediately halted block production, and handed the matter over to the technical team and validation nodes for a system review.

The September 1 update announcement confirmed the presence of a malicious attack; the mainnet will remain offline while vulnerability fixes and network upgrades are carried out. The attack did not compromise user assets. Ontology aims to restore normal operations within 24 hours, provided all security checks, vulnerability repairs, upgrades, and testing are completed successfully.

Ontology’s downtime preserves all confirmed on-chain states and only halts the confirmation and settlement of new transactions. The announcement does not specify a recovery point or disclose the set of transactions that need to be invalidated.

The disclosed permission information is incomplete. The announcement mentions that the core development team, technical team, and network validation nodes were involved in the response, but it does not identify who holds the final binding decision-making authority, nor does it specify any digital emergency response thresholds. The Ontology VBFT documentation describes the standard consensus mechanism, including node generation of confirmed blocks and management of consensus node sets for contract updates, but it only covers normal operational scenarios; the emergency suspension rules used on August 31 were not publicly disclosed.

Even without causing asset losses, downtime still incurs real costs. Ontology informed users that on-chain transactions would be unprocessable and advised against performing time-sensitive operations; it later stated that network restart depends on vulnerability fixes, upgrades, and testing. Users were unable to adjust positions or execute transfers on-chain, and all external services integrated with this chain could only wait for network signals.

The criteria for resuming operations are security-focused, but specific details are limited. Ontology states that it aims to restore services within 24 hours once repairs, upgrades, testing, and verification are all completed; however, it has not disclosed who determines whether these conditions have been met or what the triggering thresholds are.

This creates uncertainty at the governance level: while the announcement identifies the parties involved in the review, it does not clearly specify which entity holds the final authority to restart services. For users, the current risk stems from service disruption rather than confirmed asset loss or chain reorganization.

ICON: Why Blockchain Downtime Is Already Too Late

The ICON incident fully demonstrated the entire process of alerting, response, and asset脱离链管控.

According to the foundation’s post-incident review report, between 02:01:02 and 02:21:12 UTC on August 27, the attacker replayed 1,492 instances of two historically valid signed withdrawal messages. A precision flaw resulted in 1,490 of these calls succeeding, transferring 119,866,000 ICX and 531,600 bnUSD from the foundation’s asset pool.

At 02:08, the monitoring system triggered an alert, and technical staff began their investigation afterward; the affected contract was suspended at 03:53. Major exchanges gradually halted ICX deposits and withdrawals starting at 05:54, and the full network shutdown officially took effect at 06:18:54. ICON resumed operations around 07:51 on August 28, after approximately 25 hours, during which the underlying vulnerability was patched.

The post-mortem report identified the root cause as the incident response process, not insufficient detection capabilities. Alerts were triggered within seven minutes, but such alerts were frequently confused with unrelated RPC anomalies, and the system failed to notify on-call personnel. Technical investigations did not begin until approximately 03:40, shortly after which the contract was paused.

The custody boundary directly determines loss attribution. ICON states that all affected assets belong to the foundation, and ordinary users’ deposits, balances, and holdings have not been touched. The report indicates that 531,600 bnUSD and 1.366 million SODA have been fully recovered; of the 113,634 USDC lent out, 82,430 USDC have been recovered. The confirmed net loss is approximately 150.2 ETH plus 31,204 USDC. The vast majority of involved ICX were only frozen or tracked on the exchange and have not been truly recovered.

ICON’s governance structure also differs from the other two cases. The post-mortem report states that the network was under the control of the foundation during the token migration; the migration guide mentions that consensus operated in maintenance mode with only seven core nodes. Thus, this outage relied on a clearly foundation-controlled special operational architecture.

Emergency permissions are also essentially powers at the balance sheet level.

Every blockchain downtime essentially shifts risk to different areas.

• Cronos modifies the official chain history: it can protect assets still under the chain’s jurisdiction, but simultaneously invalidates legitimate on-chain activities outside the vulnerability, and is powerless over assets on Ethereum.
• Ontology converts risk into time cost and loss of service availability; transactions cannot be settled during the investigation, and no asset book losses are recognized.
• ICON completed the contract and network isolation only after the assets had already been transferred out of chain custody; the loss is confirmed to be borne by the foundation, and the recovery of frozen ICX depends on the exchange and judicial authorities.

A simple decentralized score would obscure these vastly different outcomes. A more practical evaluation criterion is: Are emergency response rules publicly disclosed? What are the thresholds that trigger a response? Does it merely halt new blocks, or does it rewrite already confirmed chain states? When intervention occurs, who controls assets that fall outside the chain’s jurisdiction? Who commits to absorbing the remaining losses?

Full post-mortem reports for Cronos and Tectonic are still pending. Ontology must disclose details of the attack and its emergency authorization rules, and later confirm whether the criteria for upgrade and restart have been met. What truly warrants comparison is the risk boundary each network defines—what historical data, timeframes, and funds are exposed to risk.

Source: www.kucoin.com