On the night of Sept. 22, a user sent an ATOM transfer. By the next morning, the transaction was still stuck in a pending state. The private key was intact, the wallet showed no signing issue, and multiple public RPC endpoints all pointed to the same problem: Cosmos Hub had stopped at block height 33,086,740. No new blocks meant there was nowhere for the transfer to be included. Only after the chain resumed block production about a day later did the transaction finally go through.
The piece frames that episode as a direct lesson in how blockchain consensus works in practice. Public blockchains are often described as systems that no central party can switch off. The article argues that reality is more complicated. A decentralized chain may have no single company with a literal pause button, yet it can still stop.
How a Neutron exploit spilled into Cosmos Hub
The article says Cosmos Hub was not the chain directly attacked. The incident began on Neutron.
On Sept. 22, a Neutron governance proposal titled 「AIATO: AI Agent Takeover」 passed. The attacker exploited chain-level governance authority and used privileged instructions built into the wasmd framework to change the contract administrators of applications including Astroport and Drop to addresses under the attacker’s control.
The article stresses that this was not a standard code bug or protocol flaw. It compares the setup to an application having its own lock while chain governance still holds a higher-level master key. Once the attacker controlled the governance outcome, that master key could be used to reassign administrators, migrate contracts, and move assets.
Cosmos Hub became involved through cross-chain fund transfers. According to a Cosmos Labs post-mortem cited in the article, before Neutron stopped operating, the attacker had already moved part of the assets across several networks. About 1.7 million ATOM was transferred into Cosmos Hub and began moving through interchain liquidity routes for swaps.
That distinction matters. The article says Cosmos Hub itself was not directly exploited, and ordinary Hub users did not lose funds because of the Neutron issue. But the stolen ATOM had already entered the Hub. To stop the remaining ATOM from moving out, some Cosmos Hub validators began shutting down their nodes.
By around 19:18 SGT on Sept. 22, the validators that had stopped represented more than one-third of total voting power. At that point, Cosmos Hub could no longer form new blocks and halted at 33,086,740.
The article highlights what that means: there was no company pressing a pause button, and there was no prior on-chain governance vote to freeze the network. The chain stopped because enough validators no longer participated in consensus.
The restart: a patch, a state change, and a multisig
Roughly four hours after the halt, validators received a full recovery plan. The proposal was to execute a one-time state modification at the halted height and move the remaining ATOM in the attacker’s address into a multisig controlled jointly by community validators.
Cosmos Labs then prepared a Gaia v28.3.0 patch based on the plan validators had already agreed to, tested it, and distributed it to validators. This version of Gaia would execute a one-time state change at the designated recovery height, moving 1,227,121 ATOM from the attacker’s address into a 4-of-6 multisig controlled by Nansen, Keplr, Enigma, Silknodes, Kiln, and Polkachu.
By early Sept. 23, validators that had confirmed installation of v28.3.0 represented more than 67% of total voting power. Cosmos Hub then coordinated a restart at 12:00 UTC that day. About six minutes later, the one-time state change was executed at block height 33,086,741, and normal block production resumed.
The article reduces the sequence to its core mechanics: validators first caused the network to lose liveness, then more than two-thirds of voting power accepted a new state transition rule, and that rule became the canonical state after recovery.
Why one-third can stop the chain
The answer, the article says, sits inside the word consensus itself. One of the most common misunderstandings in crypto is to treat decentralization as if it were the same thing as permanent uptime. Consensus mechanisms solve a different problem: how many independent nodes agree on transaction ordering and ledger state without a central bookkeeper.
Different chains solve that problem in different ways.
Bitcoin and probabilistic finality
Bitcoin’s classic model is proof of work. Miners compete to produce blocks, and when two valid branches briefly exist, nodes follow the one with the most accumulated work.
That means Bitcoin does not have a clean moment where a block becomes permanently finalized after a 67% vote. Its finality is probabilistic. The more blocks that build on top of a transaction, the more hash power would be needed to reorganize it. That is why users have long been told to wait for six confirmations on a Bitcoin transaction.
The article adds that this does not mean Bitcoin’s state is absolutely unchangeable under every condition. In theory, if the ecosystem accepted a new client and a new set of consensus rules, a hard fork could make a state transition valid even if it had been invalid under the old rules.
But the practical barrier is social and operational. Who can persuade enough miners, full nodes, exchanges, wallets, and users to adopt that new rule set? The article’s answer is essentially no one. It notes that developers cannot decide consensus rules for the whole Bitcoin network, and miners or trading platforms cannot easily do it either. It points to the period after Binance lost 7,000 BTC, when some suggested that CZ contact major miners, an idea that ultimately went nowhere.
Ethereum, Gasper, and inactivity leak
After moving to proof of stake, Ethereum adopted Gasper, which combines Casper FFG and LMD-GHOST. In the article’s description, one part determines which chain the network should follow, while the other gives blocks actual finality.
When validators representing at least two-thirds of staked ETH agree on the relevant checkpoint, blocks can move toward finality. If more than one-third of stake stops participating correctly for an extended period, the network may temporarily fail to finalize. Ethereum also includes an inactivity leak, which gradually reduces the effective weight of offline validators during long periods without finalization, giving the network a path to recover finality over time.
Changing that outcome in a deeper sense still requires changing protocol rules and client software. The article uses the 2016 The DAO incident as the clearest example. Ethereum’s community ultimately adopted a hard fork that executed what the Ethereum Foundation at the time explicitly called an irregular state change at block 1,920,000, moving the relevant ETH into a recovery contract.
Not everyone accepted that decision. Some miners and community members refused the upgrade and continued maintaining the original state, which led to Ethereum Classic, or ETC. The split between ETH and ETC showed that consensus rules are not accepted automatically by everyone.
Cosmos Hub and BFT trade-offs
Cosmos Hub uses CometBFT, which the article describes as closer to a classic Byzantine fault tolerant model. For a block to be committed, it needs Commit votes from more than two-thirds of voting power.
The benefit is clear finality. Once a block is committed with enough validator weight, there is no need to wait for more blocks the way proof-of-work systems rely on probability for confidence. The other side is just as clear: if one-third or more of voting power stops providing the votes needed for Commit, the remaining validators cannot reach the threshold.
In that situation, the safest option is to stop producing blocks, which is exactly what happened here. From a distributed systems perspective, the article says, the temporary Cosmos Hub halt is not mysterious at all. Once a group of validators with enough voting power stops participating, the protocol follows its own rules and gives up availability rather than confirming new blocks without sufficient agreement.
The article ties that to two concepts that ordinary users often blur together:
- Safety: different nodes must not finalize two conflicting states at the same time.
- Liveness: the network must keep moving forward and processing new transactions.
In a BFT system, when too few nodes remain in consensus, pausing can be the price paid to preserve safety. Put plainly, the ledger would rather stop than let the remaining participants each write their own version of the book.
Bitcoin, Ethereum, Solana, and the real boundary of risk
The article then places the Cosmos event alongside earlier incidents from other chains.
In 2013, Bitcoin suffered a well-known chain split. Bitcoin 0.8 switched its underlying database from Berkeley DB to LevelDB. A block with a large number of transaction inputs then appeared. Newer nodes processed it normally, but some older nodes treated it as invalid because of Berkeley DB lock limits.
The result was awkward and serious at the same time: everyone was running Bitcoin, but old and new clients gave different answers on whether the block was valid. The network split into two chains. The newer 0.8 side briefly had about 60% of hash power, which meant the issue could not quickly resolve itself through ordinary mining competition. Large mining pools eventually coordinated a return to the older version, restoring more hash power to the old-rule side and allowing the network to converge again. Bitcoin later reviewed the incident in BIP 50.
The 2016 DAO fork on Ethereum pushed the question in a different direction. As noted earlier, the Ethereum community used a hard fork at block 1,920,000 to carry out an irregular state change and move the affected ETH into a recovery contract.
But that remedy was not universally accepted. Some miners and community members rejected the state change and continued with the original rules, which is why Ethereum Classic still exists. The article treats the DAO fork as a classic reminder that when extreme events hit, code consensus is not the whole story. Social consensus also matters, and if agreement breaks down badly enough, one chain can become two.
Solana in 2021 showed a different failure path. In September of that year, according to the article, a flood of bot transactions hit the network, exhausted validator memory, caused many nodes to crash, and left the network unable to maintain agreement on current state. New block confirmations stopped for about 17 hours before validators coordinated a restart.
Placed side by side, these incidents are not the same event wearing different clothes. The article breaks them down this way:
- Bitcoin in 2013 involved different clients enforcing different validity rules.
- Solana in 2021 involved large numbers of validators failing to keep participating in consensus, which cost the network liveness.
- The DAO case on Ethereum was closer to a community decision on whether protocol rules should be changed to alter state.
- This time on Cosmos Hub, validators first coordinated a deliberate loss of liveness to stop the movement of attack-related assets, then a sufficiently large share of voting power accepted new software and a recovery state so the network could converge again.
For that reason, the article argues that it is less useful to reduce these episodes to slogans such as “blockchains can be switched off” or “decentralization is fake.” A more accurate conclusion is that consensus is not a machine that never breaks. It is a decentralized rule set.
Those rules determine who decides the correct chain when disagreement appears, how much participation is needed for finality, whether the network keeps running or stops during a fault, and what kind of collective action can change the rules of operation in extreme cases.
Private keys are not the same as consensus power
The article closes with a line familiar to most crypto users: not your keys, not your coins.
It says the phrase still holds, but only within its proper scope. It speaks to control over assets. If you hold your private keys, a wallet, exchange, or other third party cannot sign a transfer on your behalf. That assumes the blockchain you are using is able to process the signed transaction in the first place.
On the day Cosmos Hub stopped producing blocks, users still held their private keys and their assets did not vanish. But even a correctly signed transaction had no new block available to accept it.
The recovery process adds another point. If enough consensus participants accept a new state rule, the on-chain state of a specific account can change even without a signature from the original address. The article says that does not invalidate “Not your keys, not your coins,” but it does show that private key sovereignty and control over base-layer consensus are not the same thing.
The same distinction applies to wallets. A wallet can keep private keys and signing authority in the user’s hands. It can detect chain-level anomalies quickly, display transaction status accurately, build RPC and node redundancy, and confirm final outcomes once the network recovers.
What it cannot do is restore consensus for a public blockchain, guarantee that the underlying network will never be interrupted, or ensure that on-chain rules and state will never change at the consensus layer.
The article ends on a narrower but sharper point. A mature decentralized system may not need to promise that nothing can ever be changed. It may need to make its boundaries explicit instead: who can pause consensus, how much weight is required, and under what conditions emergency intervention is allowed. The key question is not whether accidents can be eliminated, but whether people can still tell who made the decision, under which rules, and with what level of consensus when the ledger has to move forward after a crisis.