Proposal to recover user's funds stuck in expired IBC channel

Hi all,

I’ve been speaking with a user who reached out for help on Telegram because they have accidentally sent a non-insignificant amount of AKT via the Keplr wallet to IBC channel-0 which has caused their funds to get stuck.

How are they stuck?
So IBC works via Relayers which route transactions between chains. You can check here to see the current channels on Akash Network and which chain they connect to:

Front ends like Osmosis or Emeris take the hassle out of choosing a channel, however Keplr lets you manually set the channel for a transaction. This user has used channel-0 that seems to have shown up for them automatically, which is a channel that is so old that the client on both sides have expired. While IBC protocol has a function built in to refund transactions that go to Relayers that are not functioning well or don’t exist, expired channels are not currently supported (v1.0.1 has fixed this by not allowing transactions to go to expired clients but it is not live yet).

So how do we get recover the funds?
After talking to engineers at Interchain, it seems as though a governance proposal to recover the client would be needed in order to recover the funds, although I am still waiting on more information regarding the full process needed to get them back to our user.

If anyone is able to please assist in this exercise, then please get in touch with me and we can coordinate the steps in more detail and hopefully get these AKT back.

Thanks <3


Super wise decision to help the troubled users.
Any idea how much AKTs stuck in expired IBC channel?

Kind Regrads,
Martin (Min#6706)

Hey there! I am from the Interchain IBC team: I wrote up a document for you on the steps for the governance proposal submission:

Docs: ADR-026, IBC client recovery mechanisms


  • Chain updated with ibc-go v1.1.0
  • recovery parameters set to true for the Tendermint light client – this determines if a governance proposal can be used. If the recovery parameters are set to false, recovery will require modifying the migration code. In this case the easiest thing to do is probably just to mint back the tokens during migration in the next hub upgrade.
  • The client identifier of an active client for the same connection

The governance deposit

  1. Check if the client is attached to the expected chain-id. For example, for an expired Tendermint client on the Akash chain – the client state looks like this on querying the client state

{ client_id: 07-tendermint-146
@type’: /ibc.lightclients.tendermint.v1.ClientState
allow_update_after_expiry: true
allow_update_after_misbehaviour: true
chain_id: akashnet-2 }

The client is attached to the expected akash chain-id and the recovery is set to true

  1. If the chain has been updated to ibc-go v1.1.0, anyone can submit the governance proposal to recover the client by doing this via cli:

<binary> tx gov submit-proposal update-client <client_id> <active-counterparty-client in connection>

The should be the client identifier of a currently active client which is relaying from the chain containing the expired client you are trying to revive, in this case akash. This means, whichever recommended/relayed channel is used right now could be reused to update the client.

This is the best case scenario, it is just a question of who funds the deposit and if chain votes yes.

Please note that if the client on the other end of the transaction is also expired, this process would also have to happen for that client.