What has to happen to IBC tokens before a Cosmos chain halts for good
Two threads here this month made me look at the same problem from both ends. In one , a holder has ATOM on UX Chain, which halted in July, and RoboMcGobo explained why the Hub can’t just release it: the escrow only opens when the other chain burns the voucher, and that chain makes no blocks. In the other, Akash’s proposal 346 (voting until 2 November) starts a migration that ends with akashnet-2 halting 90 days after a later cutover. So I went through ibc-go (v10.7.0, the version Gaia v29.0.1 runs; akashnet-2 runs v10.5.0, and the transfer code I cite is the same there) to list what has to happen before the last block, because after it nobody can fix anything from the other side. This is not about whether any chain should leave. It’s only about the tokens. Why tokens get stuck • When a token leaves its home chain, it goes into that chain’s escrow for the channel and the other side mints a voucher. The escrow releases it only when a packet shows the voucher was burned, and that packet has to come from a live chain. • Transfer channels can’t be closed. The transfer module rejects `ChanCloseInit`, so there is no close-and-settle step. • Every packet, ack and timeout is…
Excerpt (1193 of 4782 characters). Read the whole post on the forum ↗
Really useful breakdown, thanks. The pass-through case is one most holders would never think of.
From the wallet support side, the other half of this is reaching people in time. A lot of holders only open their wallet occasionally and never see governance proposals or X posts, which is how deadlines get missed, like the UX Chain case here.
Would it help if chains publishing a plan like this also shared a short, plain-language notice that wallets and explorers could pass on to users? Something like the chain, the affected tokens, what to do, and the deadline. That would make it much easier for us to warn people before the last block.
For transparency, I’m with Gem Wallet in BD and support.
Yes, that would help, and the part wallets need most is the denom list. On chain every IBC voucher is ibc/ plus a hash of its full path, and that’s what a wallet matches against, so a notice should list every affected denom on every chain, not only the tokens on the chain that halts. The two hop ATOM on Osmosis is the case: its path runs through Akash, but nothing a holder sees on Osmosis says Akash, so a notice that only lists akashnet-2 balances misses it.
I’d also give the deadline as a block height with an estimated date, since the last block is what counts, and the channel to send each denom back on. For the chain itself, the Chain Registry already has a status field (live, upcoming, killed) that wallets and explorers read, but it has no date, so it can only mark the end, not warn before it.
Thanks, that’s really helpful. Listing every affected token on every chain, plus a block-height deadline, makes a lot of sense. I’ll share this with our team.
Zealynx:If you hold ATOM, or anything else, on or through a chain that announces a wind-down: send it back the way it came while transfers are still open. After the halt the Hub can’t help, as RoboMcGobo explained.
This is very helpful, @Zealynx
I think we can turn this into a documentation page to explain the options users/vals can go through to prepare against a scenario like this, and a “good practices” guide for the chains themselves.
I like the dashboard suggestions as well. CC. @Dan_Bryan I know you have had ideas around related topics.
Happy to help with it. For the chains’ guide, the step that’s easiest to get wrong is refusing late transfers: with receive_enabled off the transfer module writes an error ack and the sender is refunded once it’s relayed, while filtering MsgRecvPacket in an ante handler leaves a timeout as the only refund, and a timeout set after the last block never fires. For users the page can open with one rule, send it back the way it came, hop by hop, before the halt height. If someone starts a draft I can check it against ibc-go.
Much appreciated! Will ping