# Revive an expired IBC client

**URL:** <https://forum.cosmos.network/t/revive-an-expired-ibc-client/15144>\
**Category:** Miscellaneous\
**Created:** [February 4, 2025, 7:46pm UTC](https://forum.cosmos.network/t/revive-an-expired-ibc-client/15144 "2025-02-04T19:46:49Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![kp\_fm](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/kp_fm/32/7986_2.png) [@kp\_fm](https://forum.cosmos.network/u/kp_fm)\
**Post date:** [February 4, 2025, 7:46pm UTC](https://forum.cosmos.network/t/revive-an-expired-ibc-client/15144/1 "2025-02-04T19:46:49Z")

</div>

Hello! I’m attempting to revive an expired IBC client that I have setup with the Cosmos Go Relayer.

I attempted to update the client with the following command.

`rly tx update-clients my-path`

but unfortunately it seems to throw an error with the following message for the expired client.

Error building or broadcasting transaction {“provider\_type”: “cosmos”, “chain\_id”: “pio-testnet-1”, “attempt”: 4, “max\_attempts”: 5, “error”: “rpc error: code = Unknown desc = rpc error: code = Unknown desc = failed to execute message; message index: 0: cannot update client (07-tendermint-80) with status Expired: client state is not active [cosmos/ibc-go/v8@v8.3.2/modules/core/02-client/keeper/client.go:67] with gas used: ‘77585’: unknown request”}

Any suggestions on how I could go about renewing/reviving the IBC client would be greatly appreciated.

---

<div class="post-metadata">

**Author:** ![cosmosrescue](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/cosmosrescue/32/7556_2.png) [@cosmosrescue](https://forum.cosmos.network/u/cosmosrescue)\
**Post date:** [February 4, 2025, 8:17pm UTC](https://forum.cosmos.network/t/revive-an-expired-ibc-client/15144/2 "2025-02-04T20:17:47Z")

</div>

hey, in short, to revive an expired ibc client you’d need to:

1. create a new identical ibc client
2. create a governance proposal that substitutes expired client with the new client
3. once governance proposal passes → client will be revived

relevant docs can be found here: [Governance Proposals | IBC-Go](https://ibc.cosmos.network/v8/ibc/proposals)

you can create a new client with [hermes](https://hermes.informal.systems/documentation/commands/path-setup/clients.html#create-client) or rly (use correct params for your case):

```auto
hermes create client --host-chain pio-testnet-1 --reference-chain <other-chain-id> --trusting-period 10000000ms --unbonding-period 1814400000ms ...

```

```auto
rly transact client <path-name> --client-tp "10000000m" --client-unbonding-period "1814400000m" ...

```

* * *

**update-clients** command is used to keep the clients alive and prevent expiration, but it can’t revive a client once it is expired already

---

<div class="post-metadata">

**Author:** ![reasonant](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/reasonant/32/7558_2.png) [@reasonant](https://forum.cosmos.network/u/reasonant)\
**Post date:** [February 5, 2025, 2:57pm UTC](https://forum.cosmos.network/t/revive-an-expired-ibc-client/15144/3 "2025-02-05T14:57:15Z")

</div>

Why are IBC clients required to be gov props? These go down all the time and the gov process is slow and annoying. Why not allow permissionless IBC client creation and then frontends select which ones to include? I’m sure there’s a reason, but it’s confusing to me.

---

<div class="post-metadata">

**Author:** ![freak12techno](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/freak12techno/32/2991_2.png) [@freak12techno](https://forum.cosmos.network/u/freak12techno)\
**Post date:** [February 5, 2025, 4:24pm UTC](https://forum.cosmos.network/t/revive-an-expired-ibc-client/15144/4 "2025-02-05T16:24:44Z")

</div>

> [@reasonant](#):
>
> Why not allow permissionless IBC client creation and then frontends select which ones to include?

Actually creating IBC clients or channels is permissionless. Problem is, if you relay your tokens via two different IBC channels, it’s gonna be 2 different tokens, and to relay them back, you need to relay it via the same channel you’ve relayed it with previously.

---

<div class="post-metadata">

**Author:** ![reasonant](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/reasonant/32/7558_2.png) [@reasonant](https://forum.cosmos.network/u/reasonant)\
**Post date:** [February 5, 2025, 6:46pm UTC](https://forum.cosmos.network/t/revive-an-expired-ibc-client/15144/5 "2025-02-05T18:46:57Z")

</div>

Ok so basically the govprop ensures everyone is using the same ibc client and therefore the same token, and therefore instantiating a new one creates new tokens which is why we want to revive existing ones?

---

<div class="post-metadata">

**Author:** ![Syed](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/syed/32/6968_2.png) [@Syed](https://forum.cosmos.network/u/Syed)\
**Post date:** [February 6, 2025, 4:40pm UTC](https://forum.cosmos.network/t/revive-an-expired-ibc-client/15144/6 "2025-02-06T16:40:38Z")

</div>

Yep, exactly!

And generally speaking, so long as IBC transactions are flowing through a channel, it doesn’t expire

---

<div class="post-metadata">

**Author:** ![jacobgadikian](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/jacobgadikian/32/6994_2.png) [@jacobgadikian](https://forum.cosmos.network/u/jacobgadikian)\
**Post date:** [February 7, 2025, 2:19pm UTC](https://forum.cosmos.network/t/revive-an-expired-ibc-client/15144/7 "2025-02-07T14:19:54Z")

</div>

Specifically the gov prop manually sets the counterparty client state.

This can be used for fraud (bigly) so that’s why governance handles it.

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex031/uploads/cosmos1/original/2X/2/2a3beb3e0f97ddad3b51a8d0d4a22abaa95604d8.png) [@system](https://forum.cosmos.network/u/system)\
**Post date:** [February 21, 2025, 2:20pm UTC](https://forum.cosmos.network/t/revive-an-expired-ibc-client/15144/8 "2025-02-21T14:20:54Z")

</div>

Closed on February 21, 2025, 2:20pm UTC

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
