What happens to staked crypto when a blockchain halts?

A halt is when a blockchain’s validators (the computers that secure the network and confirm transactions) stop producing new blocks. Nothing moves, including staked funds (tokens you’ve locked with a validator to help secure the network and earn rewards). Nobody can unstake, delegate (assign tokens to a validator to earn rewards), or collect rewards until the network resumes, and there’s no fixed timeline: it lasts as long as it takes to diagnose and fix whatever caused it. A halt in August 2026, triggered by a bug shared across several Cosmos SDK chains (blockchains built with the Cosmos software toolkit), is a concrete example of what that looks like in practice.

What happened: the Cosmos EVM exploit

The bug lived in cosmos/evm, a shared open-source module that lets Cosmos-based blockchains run Ethereum-style smart contracts (code that executes on the Ethereum Virtual Machine, or EVM). According to the GitHub Security Advisory GHSA-7g4w-cg88-2cq2, the flaw was an unchecked subtraction (“underflow”) in the module’s internal account balance tracking: delegating an amount that exceeded what was actually available from a vesting account (one with both locked and unlocked funds) could make the balance wrap around to a number close to the maximum a computer can represent (roughly 2^256), creating a huge, fake balance that didn’t really exist. The advisory lists affected versions as anything before 0.6.2, and 0.7.0 up to (but not including) 0.7.2; a patch shipped in both fixed versions on 19 August 2026.

The official Cosmos Labs post-mortem, published 28 August 2026, lays out the timeline. The bug was first reported through a bug bounty program back on 25 April 2026, but was assessed at the time as carrying no real risk. A fix was merged to the main branch on 15 May, and the retro-ported patch went out on 19 August. Hours after that public patch, a pull request exposed the exploitation path, and the first attack hit MANTRA on 20 August 2026 at 19:06 UTC. TAC and KiiChain were exploited two days later, on 22 August. The exploitation window closed on 25 August.

The financial damage, per the same post-mortem, totaled roughly $5.7 million across six chains (the sum of the two figures it reports, and the total The Block cited): about $2.87 million converted through decentralized exchanges and about $2.85 million sold on centralized exchanges (those accounts were subsequently frozen). Three of the affected chains (MANTRA, TAC and KiiChain) were named publicly; the post-mortem states the ecosystem-wide impact spanned six chains without naming the other three.

The Block’s reporting from 29 August 2026 breaks the loss down by chain: MANTRA lost roughly $3.6 million (720.9 million tokens drawn from a burn address and an inactive multisig), TAC lost about $950,000 (1.2 billion tokens sold on BNB Chain), and KiiChain lost about $1.6 million (64.6 million KII tokens sold). As of 28 August 2026, MANTRA said none of its drained tokens had been recovered, while Cosmos Labs estimated that roughly 54% of the KII taken from KiiChain remained recoverable onchain if that network were restored. MANTRA’s token also fell about 18.5% (from roughly $0.00506 to a record low of about $0.00413) as the chain halted, according to CoinDesk.

Why one bug hit several unrelated chains

MANTRA, TAC and KiiChain are separately operated blockchains with different teams, tokens, and communities. What they had in common was a piece of shared, reused code: the cosmos/evm module. As the Cosmos Labs post-mortem puts it, “the Cosmos ecosystem spans over 115 different known public blockchains” (many of them built by assembling the same open-source modules rather than writing their own EVM compatibility layer from scratch). That reuse is normally a strength: it means less code to audit per chain, and a fix benefits everyone who adopted the module. It is also the failure mode here: a single flaw in one dependency became a simultaneous incident on every chain that shared it, whether or not that chain’s own code had a single bug of its own. Beyond the six exploited chains, the Cosmos Labs post-mortem describes coordinating mitigation with thirteen additional networks running the module, and CryptoTimes reported that Cosmos Labs said on 26 August it was continuing to provide mitigation information to affected chains, and asked teams without a registered security contact to reach out directly.

It isn’t the first time a single flaw in shared Cosmos code reached many chains at once: in October 2022, a vulnerability nicknamed Dragonberry, in code used by IBC (the protocol Cosmos chains use to communicate with each other), affected every IBC-enabled Cosmos chain, and developers distributed a patch privately to validators before disclosing it publicly, with no funds lost, according to the Cosmos retrospective.

What a halt actually means if you have crypto staked

This is the part that matters if you delegate or stake on any Cosmos SDK chain, whether or not it was one of the three named above. The exploit hit MANTRA at 19:06 UTC on 20 August, per the Cosmos Labs post-mortem, and roughly four hours later (around 7:13 p.m. ET, or 23:13 UTC) MANTRA’s validators stopped producing blocks entirely, and normal operation did not resume until 03:38 UTC on 22 August, roughly 28 hours later, per the Cosmos Labs post-mortem; no rollback was performed, per The Block. With no new blocks, no transaction of any kind (no transfer, no staking, no unstaking) could be processed on the chain for the duration of the halt. MANTRA released a hotfix at 02:28 UTC on 21 August, per the Cosmos Labs post-mortem.

If you had tokens delegated to a validator on one of the affected chains, such as MANTRA, during that window, the practical experience was:

• You could not withdraw. Unbonding requests (the process of unlocking staked tokens), new delegations, redelegations: none of it executes while there are no blocks being produced.
• You earned nothing. Staking rewards accrue per block. No blocks, no rewards, for the entire duration.
• You had no say in when it ended. The halt ends when validators (not you, not even the affected chain’s founding team acting alone) finish coordinating and applying a fix. There is no published countdown the way there is for a scheduled unbonding period.
• The underlying exploit was a separate problem. The halt itself didn’t cause the $5.7 million loss; the loss happened because the bug was exploited before the halt, in the hours and days after the patch was made public on 19 August. The halt was the emergency response, not the harm, but it’s also the thing every delegator on the chain experienced directly, whether or not their own funds were touched by the exploit.

How this differs from the staking risks you may already know

If you stake or delegate crypto, you’ve probably already run into three other kinds of risk. A halt is a fourth, and it’s easy to conflate with the others because all four end with “I can’t get my money right now.”

Risk	What triggers it	Is it planned?	Does it burn your funds?
Lock-up / unbonding	You choose to unstake	Yes (a fixed, published waiting period)	No (funds are released in full when the period ends)
Slashing	Your validator double-signs (signs conflicting blocks) or goes offline for too long	No, but the penalty and its cause are protocol-defined	Yes, a percentage of the validator’s stake, including delegated funds, is burned
Exchange custody risk	The exchange holding your crypto is hacked, mismanaged, or insolvent	No	Depends on the exchange’s solvency and security, which you don’t control
Network halt	A bug (often in shared infrastructure) or an active exploit forces validators to stop	No (unplanned and open-ended)	Not directly. Funds can be lost separately by whatever caused the halt, and access is frozen for the duration

A lock-up is a known, scheduled cost: you know going in that unstaking takes time, and the protocol guarantees the funds are released when the period ends. Slashing punishes specific validator misbehavior and is, in a sense, the system working as designed (it protects the network by making bad behavior costly). Leaving crypto on an exchange is a custody trade-off you’re accepting knowingly. A halt is different from all three: it isn’t a cost you signed up for, isn’t a punishment for anyone’s misbehavior, and isn’t a custody decision you made. It’s an infrastructure failure that can freeze anyone’s funds no matter how carefully they chose a validator.

What to check before delegating to a chain

None of this means staking is inherently unsafe. It means infrastructure risk is a separate category that needs to be checked, alongside the questions most people already ask about APY (annual percentage yield) and lock-up length:

• Does the chain build on shared, widely reused modules, and if so, does the team publish which ones and their versions? A chain that’s transparent about its dependencies is easier to evaluate than one that isn’t.
• Has the chain halted before, and if so, how was it communicated and resolved? A team’s track record during an incident (clear updates, a public post-mortem, no attempt to minimize what happened) tells you more than any marketing claim about how solid the infrastructure is.
• How concentrated is the validator set, since a halt requires enough of the active set to coordinate a fix together? The same concentration questions that matter for choosing a validator generally apply here too.
• Where would you hear about an incident first? You can’t audit a module’s code yourself, but you can follow the chain’s official announcement channels and the security advisories of the modules it builds on (the one behind this incident was published on GitHub). That won’t prevent a halt, but it means you learn about it from the source rather than from a frozen wallet.

A halt is also best kept separate from slower-moving risks like a gradual decline in staking rewards as more people stake the same asset: that’s a return-on-capital problem you can see coming and react to, while a halt is a sudden, all-or-nothing freeze on access.

For a broader look at how a specific chain’s staking mechanics (APR, unbonding period, slashing rules) compare, RUNEBond’s Cosmos staking profile and the THORChain vs. Cosmos comparison lay out the trade-offs side by side. RUNEBond compares staking options across chains; THORChain is one of the chains it covers.

Where THORChain fits

THORChain is a separate Layer-1 blockchain built on the Cosmos SDK (the same technical family as MANTRA, TAC and KiiChain) that focuses on swapping native assets across different chains without wrapping them. It does not use the cosmos/evm module at the center of the incident described in this article. The cosmos/evm project’s own documentation lists the chains that have adopted it (MANTRA and TAC among them), and THORChain isn’t on that list. Instead, THORChain’s connections to EVM-compatible chains like Ethereum, Avalanche and BSC run through external chain clients inside its Bifrost subsystem (a mechanism for observing and interacting with other blockchains), a design documented in THORChain’s developer docs, rather than an EVM module embedded directly in its own consensus layer.

That’s a different dependency footprint, not a promise that it is immune to every bug. No protocol (THORChain included) is free of code risk, and this incident is a reminder that infrastructure failures aren’t hypothetical. It’s simply an example of one chain that doesn’t share this particular piece of infrastructure with the three chains this exploit hit.

For anyone already comfortable with the idea of delegating crypto to earn yield, THORChain’s bond providers work similarly to Cosmos-style delegation: you delegate RUNE (THORChain’s native token) to a node operator instead of running infrastructure yourself, and you earn a share of that node’s rewards. It carries its own, separately documented risks, including slashing for operator misbehavior, churn-out periods where a node temporarily leaves the active set, and a permissioned whitelist model rather than fully open delegation. It’s one more way to delegate for yield, not a risk-free one, and it’s best evaluated with the same questions raised above.

Compare active THORChain nodes and their bond levels on RUNEBond if you want to see how that specific delegation model works in practice.