Cosmoshub IBC Reactivation via Client Unfreeze

Proposer: fragwuerdig
Authors: fragwuerdig / Rex Harrison (Rexyz)

Declarative Biases

fragwuerdig: owns LUNC and staked LUNC.
Rexyz: owns LUNC and staked LUNC. Is a senior partner of TerraCVita, operates a
validator (TerraCVita) on the Terra Classic chain and is a trustee of the Terra Classic
Community Foundation.


Through accepting this proposal it is proposed to unfreeze the expired IBC Tendermint client
07-tendermint-71 which interconnects the Cosmos SDK blockchains columbus-5 and

Technical background

IBC is a three-layered network protocol which interconnects blockchains. Applications on the
chain use the high-level IBC channels to interchange information (e.g. transferring funds).
Channels are the blockchain application-end interface to enable access to IBC as a whole.
Channels are built upon IBC connections which control and secure data flow between
chains. Connections in turn are built upon the so-called Tendermint clients, which handle the
consensus states on the both interconnected chains. On each of the both interconnected
chains one client that references the other chain is necessary to make the protocol work.

Current Situation

In order to be trustworthy, the state of these clients needs to be periodically updated by IBC
relay operators. In case the relay operators seize their work, the clients can become expired
and will be frozen. After having been frozen a state update of the client is not possible
anymore. This is exactly what happened, when the Terra Luna price crashed back in May
'22. As a result the communication between both chains was not possible anymore.


The ibc-go implementation of the IBC protocol in the Terra Classic blockchain exposes a
type of governance proposal, which enables a community to reactivate an expired/frozen
Tendermint client. When such a proposal passes, then the state of another (but active and
updateable) Tendermint client which is available on both chains gets copied into the expired
client, thus reactivating the expired one. It is to establish this reactivation function that this
governance proposal is about.

Results of Voting

Yes = The canonical Tendermint client 07-tendermint-71, which interconnects columbus-5
(Terra Classic blockchain) and cosmoshub-4 will get updated with the state of Tendermint
client 07-tendermint-128. The updated client was created and is currently
maintained/updated by the authors of this proposal.
NB, Unfreezing an expired client does not necessarily mean that you can transfer funds or
exchange IBC packets between both chains again. The Tendermint client on the
cosmoshub-4 chain that references columbus-5 might be frozen as well. However, voting
“yes” represents the intend of the community to reactivate the IBC connection.

No = The Tendermint client 07-tendermint-71 remains expired/frozen. This shows the intent
of the community, that it does not want to IBC between Terra Classic and Cosmoshub

Risk and Opportunities


There are no significant risks to this proposal being accepted.

In the case that this proposal passes and the connection between Terra Classic and
Cosmoshub gets reactivated, there is also no significant risk of diluting the Terra Classic on-
chain overall-supply. The amount of LUNC trapped on Cosmoshub is ~36,100 (as queried
on 23rd October ‘22).

It must be noted that using IBC as a whole may involve risks - as learned from the BSC
debacle. Activating the client on “TerraClassic” may not lead to a functional connection
between the chains because on the Cosmoshub the corresponding client might be frozen as
well. In such instances we would need a similar proposal on Cosmoshub and the community
there might say no.


Reactivating the IBC’s across connected chains might have a great marketing effect through
signalling that it shows that the community makes sensible decisions and takes action.

It also publicises that IBC on Terra Classic can be enabled should the community decide it
(except for a few cases - e.g. Osmosis – where the community has to wait for other core
developers to reopen channels).

Reactivating IBC’s could release ’trapped’ LUNC.

Reactivating IBC’s brings interoperability meaning that funds on other chains can be used to
generate yield from liquidity pools over there.

The proposal is open for discussion.


Thanks for posting this. Very well written

It would be great if you provided more details on who worked or is working on this, if it is part of the TR official roadmap for the chain, etc. Basically, add some referral links to extra info, discussions/threads, etc.

1 Like

Thanks for this very well explained proposal! When do we vote it’s a yes for me let’s move forward. Opening IBC brings back huge potential for the chain.


If I understand that correctly, passing the
Proposal will “overwrite” the current software and unfreeze the IBC?

This proposal was worked out in the TerraCVita community



“update” refers to the internal state of the client being updated. Not a piece of software. It is needed to share consensus across the chains being interconnected.

This proposal is NOT about unfreezing IBC as a whole. It refers only to the connection to Cosmoshub

Let me explain the technical part in a different way: If you think of two chains being the participants in the telephone call, then IBC “channels” are somewhat the participants mouth and ear (to speak and hear). In this model the IBC “connection” would be related to the speakers of the telephone (makes sure spoken word gets onto the wire in ordered manner). The “client” would be the wire. An expired client means that the wire has been cut. If you do not maintain the cable then it will eventually break.

The only difference in this model is that you actually need two wires - one hosted by one chain A, the other hosted by chain B.

Now, we need to fix the wires by the power of a government proposal (participant A and B must both agree to let the technician in to fix the wire).


Awesome thank you. So it’s fair to say that this is part one of “fixing” the issue. Once the state is set to on, ATOM will need to do the same on their side.

Subsequently there will need to be a further update on our side to the Client?

Or will this proposal be sufficient (should cosmos governance agree too)

1 Like

It is actually a very special kind of governance proposal provided by the ibc-go module of the blockchain core software. Unlike a text proposal it does not need any software updates of the core software running on validator nodes. If passed, state update will happen automatically on-chain.


Great! Let’s do this!

1 Like

I am, of course, all for opening IBC right now.

As far the Risks go, this is just for Cosmoshub and no other ones, correct? eg Osmosis.

1 Like

It’s only Cosmoshub. You are absolutely right.


Aha I see. Apologies at work IRL earlier and clearly didn’t read the proposal properly!

So this special proposal we’ll set the state to on. Then it’s all down to cosmos hub to see whether it’s also on there.

Apologies for perhaps questioning the glaringly obvious but should both TC and Cosmos set there states to on, would that Enable the bridge between TC and osmosis?

Assuming participant A is (Terra Classic) and already agreed to fix the wire. Shouldn’t participant A ask participant B first to be sure that they are also in agreement to fix the wire so that all work will be done together MHO!


yes yes yes and yes, we are on the right track, soon we will be interoperating with cosmos again and many dApps will be able to enter the ecosystem, what we experience in the coming weeks could be totally crazy


I know what you mean.

Thing is: From a technical perspective there is no consensus-safe cross chain governance proposal to “ask” stakers of another chain to agree on something.

Besides: The client 07-tendermint-71 is “property” of the Terra Classic chain. It was created here and it’s destiny is determined by it’s community. We get to decide what happens with this client

By proposing the very same thing on the Cosmoshub (asking them to unfreeze their client) the Cosmoshub community gets to decide what happens with their part of the interconnection. By then voting on this, they show us their intentions regarding reactivation of IBC between the both chains.

I think this is totally sufficient in terms of agreement between the both participants.

Are you referring to a software upgrade proposal (or something else)? If you are referring to the software upgrade proposal then I will pass along some information.

I hope you are doing well :slight_smile:

1 Like

Since this IBC reactivation is pretty technical, I think this “discussion” will be more of a FAQ… So, @fragwuerdig please keep around and answer our questions please =)

My question is regarding Osmosis: in their v9 upgrade (in June this year), they said in their Twitter:

Reopening the Terra Classic<>Osmosis IBC channel requires a software update on both Osmosis & Terra Classic The necessary Osmosis-side update was completed in the v9 upgrade Now it is fully up to the @terra_money devs/validators to coordinate the necessary Terra-side upgrade

This means that a proposal of this kind, if targeting the Osmosis-chain, can immediately reactivate the IBC between the two chains?

My other question is why is this being proposed only now? I mean, IBC is an obvious step in the recovery plan, and the chain is stable for some time now (since staking was reenabled). I guess it has something to do with the relay operator, right? What are the costs involved in maintaining an IBC channel?


Yes! Perfect

The type of governance proposal I am talking about is the following:


This type of proposal is provided by the ibc-go module Terra makes use of.

It is NOT a software update proposal to deploy software changes automatically on-chain using CosmoVisor.

1 Like

This means that a proposal of this kind, if targeting the Osmosis-chain, can immediately reactivate the IBC between the two chains?

No. Thank you for asking that question. It’s a really smart one. In case of Osmosis TFL made a
software change to the core software that actively and forcefully shuts down the channel grade connection between Terra and Osmosis on Blockchain level (or SDK level as I like to say)

In our analogy with the two participants in a phone call that is like taping the ears and mouth of the participants so they can’t talk anymore. But the speakers and wire were not touched.

In order to talk to Osmosis again we need to perform the following software update on the core software:

However, the “channel grade” connection between two chains is the more high level layer of IBC, meaning that a channel between two chains cannot exist without a underlying Tendermint client. But a Tendermint client does not need a channel to come into existence.

This means that we just go ahead making a governance proposal to unfreeze the Tendermint client that references Osmosis. But transferring funds would require GitHub PR 34 to happen (see link above)

My other question is why is this being proposed only now?

I don’t know exactly. I think educational-wise the community is pretty much unaware of the fact that MOST connections to other chains could simply be reactivated by the power of governance. There is no magical IBC switch that was turned off by TFL back in the days in May.

That’s one aim of the proposal: Teaching that the community has the power over IBC reactivation (Osmosis being a big exception). Not Terra Rebels or any other core developers do have the control over that.

What are the costs involved in maintaining an IBC channel?

You are raising the really good questions :white_check_mark:

Costs are huge, in fact. As a relay operator you need to commit state mutating changes to both chains. That’s gonna cost gas fees. No one is gonna pay the relay operator for that. And me personally, I certainly do not have the bag to do so.

I made some experiments on my own transferring LUNC over a NEWLY created connection to Cosmoshub.

Every transaction was about .5 to 1$ in gas fees. Scale that up and you got the relay operating costs.

So in case of this proposal passes, there might be still a chance we have working Tendermint clients but nobody willing to operate a relay, because there is no incentive. That’s why I made another Agora proposal which was somehow spelled into the void:

After successful client update, I will certainly sit there and constantly update the Tendermint clients so they won’t expire (or in other words: I will hold the foot in the door so it doesn’t get closed anymore). But that’s actually not the way decentralization should work (me being a single point of failure)

We kinda have to wait for active relay operators to jump in to be able to see cross chain transactions again…