Decentralization has never meant the network is always online. Whether a chain runs depends on whether enough participants reach consensus.
On the evening of September 22, a user sent an ATOM transfer.
Overnight, the transaction remained stuck at "awaiting confirmation."
The private key was not lost, and the wallet showed no signing anomaly. Checking again the next day, multiple public RPCs all showed that Cosmos Hub had stopped at block height 33,086,740.
With no new blocks being produced, there was naturally nowhere for this transaction to be included.
Only about a day later, when Cosmos Hub resumed producing blocks, did this ATOM transfer — which had been waiting all along — finally succeed.
For ordinary users, this may be the most intuitive lesson in understanding blockchain consensus.
We are used to saying "no central institution can shut down a public chain," but reality is clearly far more complicated. A sufficiently decentralized blockchain usually does not have a "shutdown button" sitting in a server room, but it can still stop.
This pause of Cosmos Hub happened to expose, in full, the mechanism that usually stays hidden beneath the surface, right in front of ordinary users.
First, we need to clear up an easily confused point: the direct target of this attack was not Cosmos Hub.
On September 22, a Neutron governance proposal called "AIATO: AI Agent Takeover" was passed. The attacker exploited a loophole in chain-level governance permissions, using privileged instructions natively provided by the wasmd framework to change the contract administrators of applications such as Astroport and Drop to addresses controlled by the attacker.
This is not the kind of "code vulnerability" or "protocol flaw" we usually understand.
To put it simply, the applications themselves have their own "door locks," but Neutron's chain-level governance also holds a higher-privilege "master key." When the attacker controlled the governance outcome, it was equivalent to obtaining this key — they could reassign administrators, migrate contracts, and further move the assets within.
What actually dragged Cosmos Hub into this was the subsequent cross-chain transfer of funds.
Cosmos Labs' post-mortem showed that before Neutron stopped running, the attacker had already moved part of the assets to multiple networks, of which roughly 1.7 million ATOM were transferred into Cosmos Hub and began being swapped through cross-chain liquidity.
In other words, Cosmos Hub itself was not directly attacked, and ordinary Hub users' funds were not directly stolen because of the Neutron vulnerability.
But the ATOM obtained from the attack had already entered the Hub. To prevent the remaining ATOM from continuing to flow out, some Cosmos Hub validators began stopping their nodes.
By around 19:18 (SGT) on September 22, the validators that had stopped running already represented more than one-third of the total voting power. Cosmos Hub was therefore unable to continue forming new blocks, ultimately stopping at 33,086,740.
It means that Cosmos Hub does not have a "Pause" button that some company can directly click, nor did it first go through an on-chain governance vote. What actually stopped the network was that enough validators no longer participated in forming consensus.
But what deserves even more attention is the recovery process that followed.
About four hours after the chain halted, validators received a complete recovery plan: execute a one-time state change at the halt height, transferring the remaining ATOM in the attacker's address to a multisig address jointly managed by community validators.
Subsequently, Cosmos Labs produced the Gaia v28.3.0 patch based on the plan the validators had already agreed on, tested it, and distributed it to validators.
This version of Gaia would execute a one-time state change at the designated recovery height, transferring 1,227,121 ATOM from the attacker's address to a 4-of-6 multisig address composed of six parties: Nansen, Keplr, Enigma, Silknodes, Kiln, and Polkachu.
By the early hours of September 23, validators confirmed to have installed v28.3.0 already exceeded 67% of the total voting power. Therefore, at 12:00 UTC that day, Cosmos Hub coordinated a restart. About six minutes later, this one-time state change was executed at block height 33,086,741, and the network resumed normal block production.
Ultimately, throughout the entire process from Cosmos stopping block production to resuming operation, validators first caused the network to lose Liveness, and then more than two-thirds of the voting power accepted a new set of state transition rules, finally making those rules the canonical state after recovery.
At this point, a seemingly simple question emerges: Since it is a decentralized public chain, why could just over one-third of the validation power stop it, while restoring the network required enough validators to jointly accept and run the same software?
The answer, in fact, lies in the two words "consensus."
One of the most easily misunderstood things about blockchain is equating "decentralization" with "never going down."
In reality, the problem that consensus mechanisms truly solve is how many nodes can agree on transaction ordering and ledger state without a central bookkeeper.
It's just that different public chains implement this in different ways.
Bitcoin's most classic approach is PoW — proof of work. Miners compete to produce blocks through computing power. When the network briefly has two legitimate branches, nodes choose one to continue building on based on cumulative work.
So Bitcoin does not have a clear moment of "after 67% votes, this block is Finalized forever." It is closer to probabilistic finality: the more subsequent blocks there are, the higher the computing-power cost required to reorganize earlier transactions.
This is also why people used to say a Bitcoin transaction should ideally wait for six block confirmations — after all, no matter how high the computing power, one cannot simply bypass the consensus rules that nodes are executing.
Of course, this does not mean Bitcoin's state is "absolutely unmodifiable" under any circumstances. In theory, if the entire ecosystem accepts a new client and new consensus rules, a Hard Fork can likewise make state changes that were invalid under the old rules become valid.
But the question is: who has the ability to get enough miners, full nodes, exchanges, wallets, and users to accept such a new set of rules together?
The development team cannot decide consensus rules on behalf of the entire Bitcoin network, and neither can miners or exchanges easily, because the consensus threshold it must cross is extremely high. When Binance was hacked for 7,000 BTC, someone suggested CZ contact major miners to intervene, but it ultimately came to nothing.
After transitioning to PoS, Ethereum now uses the Gasper consensus, composed of Casper FFG and LMD-GHOST. Simply put, one part of the mechanism is responsible for determining "which chain to follow right now," while the other is responsible for giving blocks genuine Finality.
When validators representing at least two-thirds of staked ETH reach agreement on the corresponding checkpoint, blocks can move further toward finalization. Conversely, if more than one-third of the stake fails to participate in correct voting for a long time, the network may temporarily be unable to form Finality. However, Ethereum also designed the inactivity leak, which gradually reduces the effective weight of offline validators during prolonged failure to finalize, giving the network a chance to eventually restore Finality.
To truly change such an outcome likewise requires changing the protocol rules and clients.
Just as in the 2016 The DAO incident, the Ethereum community ultimately carried out a Hard Fork, executing at block 1,920,000 a special state change that the Ethereum Foundation at the time directly called an irregular state change, transferring the relevant ETH into a recovery contract.
It's just that some miners and community members who refused to upgr