# Fetchhub-3 IBC migration

## Introduction

With the migration from fetchhub-3 to fetchhub-4, the existing IBC channels need to be upgraded.
This can be done through relayer software commandline using the `UpdateClient` and `UpgradeClient` commands (see [1]).

## IBC migration

The `3Tekos` and `Cros-nest` teams are working together to migrate their IBC channels to fetchhub-4.

Form migration to be possible, a channel must not be expired or frozen.

We need to query the `state` of each channel's client to know if it can be migrated or not.
We are interested in two parameters:
- trusting_period : The time in seconds the client will be valid without any update or transaction.
- latest_height : The counterparty block height of the last update. (we will query the time in seconds since this block)

Time elapsed since last_height must be smaller than the trusting_period

Fetch.ai <> Osmosis
`hermes query client state fetchhub-3 07-tendermint-0`
- trusting_period => 777600 (9days)
- latest_height => 3814639 (5 days ago)

`hermes query client state fetchhub-3 07-tendermint-1`
- trusting_period => 864000 (10 days)
- latest_height => 3401037 (1 months ago)

Fetch.ai <> CosmosHub
`hermes query client state fetchhub-3 07-tendermint-2`
- trusting_period => 1209600 (14 days)
- latest_height => 9491412 (1 months ago)

Fetch.ai <> Juno
`hermes query client state fetchhub-3 07-tendermint-3`
- trusting_period => 1209600 (14 days)
- latest_height => 2467141 (9 days ago)

Fetch.ai <> Umee
`hermes query client state fetchhub-3 07-tendermint-4`
- trusting_period => 777600 (9 days)
- latest_height => 171754 (1 months ago)

Fetch.ai <> Sifchain
`hermes query client state fetchhub-3 07-tendermint-5`
- trusting_period => 1209600 (14 days)
- latest_height => 5727224 (1 months ago)

Fetch.ai <> Gravity-Bridge
`hermes query client state fetchhub-3 07-tendermint-6`
- trusting_period => 86300 (24 hours)
- latest_height => 1521091 (1 days ago)

Fetch.ai <> Gravity-Bridge
`hermes query client state fetchhub-3 07-tendermint-7`
- trusting_period => 86300 (24 hours)
- latest_height => 1514474 (1 days ago)

### 1/ observations

Only 2 channels are not expired (Osmosis and Juno)
Juno is currently stuck and we don't have any ETA for the restart.

### 2/ actions

We need to update the client on the osmosis side.
With the migration to a new chain-id, we are not totally sure of the actions to take.
A ticket is open with IBC experts to know the exact steps to follow.
It might be necessary to open a governance proposal on Osmosis to migrate the client to new chain-id

## solutions for the expired channels

An expired channel can be swapped with a new one via a governance proposal. The channel parameters cannot however be modified.
The Gravity-Bridge channel with only 24h of trusting_period is very dangerous (high risk of expiration).

### unfreeze channels

To unfreeze a channel, a governance proposal must be deposited to swap the existing expired channel with a new one.
This option must be chosen if the channel is valuable (great number of tokens sent over IBC).
Sending through a different channel will create a different denom which is non-fungible with the existing one.

### create new channels

For channel without high value, a new channel can be open with correct parameters.

## Channel value

### balances on Fetch chain

We need to know the token present on the Fetch chain:

`fetchd q bank total`

supply:
- amount: "1085754012246102179709738759"
  denom: afet
- amount: "80"
  denom: ibc/3554989531C7DB295D548F373FE93205215CAC2820A62D748E5A3703044D481E
- amount: "30"
  denom: ibc/64ADA1661E3C1A4293E3BB15D5BD13012D0DB3D9002C117C30D7C429A32F4D51
- amount: "50002"
  denom: ibc/ED07A3391A112B175915CD8FAF43A2DA8E4790EDE12566649D0C2F97716B8518
- amount: "100000000000000000"
  denom: nanomobx
- amount: "1000000000000000000"
  denom: nanonomx
- amount: "100000000000000"
  denom: ulrn

IBC Hash must be translated to human denom
`fetchd query ibc-transfer denom-trace 3554989531C7DB295D548F373FE93205215CAC2820A62D748E5A3703044D481E`

denom_trace:
  base_denom: ugraviton
  path: transfer/channel-6

`fetchd query ibc-transfer denom-trace 64ADA1661E3C1A4293E3BB15D5BD13012D0DB3D9002C117C30D7C429A32F4D51`

denom_trace:
  base_denom: ugraviton
  path: transfer/channel-7

`fetchd query ibc-transfer denom-trace ED07A3391A112B175915CD8FAF43A2DA8E4790EDE12566649D0C2F97716B8518`

denom_trace:
  base_denom: uosmo
  path: transfer/channel-0

=> 50002 uosmo from channel-0
=> 80 ugraviton from channel-6
=> 30 ugraviton from channel-7

### balances on Osmosis chain

The same exercice must be done on Osmosis chain to know the number of FET sent.

=> 12 610 000 000 000 afet from channel-175 => 12 FET

### balances on Juno chain

=> 1 afet from channel-55

### balances on Gravity-Bridge chain

=> 70 afet from channel-30

### balances on CosmosHub chain

=> No token exist on CosmosHub

### balances on Umee chain

=> No token exist on Umee

### balances on SifChain chain

=> No token exist on SifChain

# Conclusion

It does not exist high value channel on FET.
The decision can be taken to open new IBC channels with correct parameters.

[1](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/upgrades/quick-guide.md#step-by-step-upgrade-process-for-relayers-upgrading-counterparty-clients) Step-by-Step Upgrade Process for Relayers Upgrading Counterparty Clients
[2](https://docs.fetch.ai/ledger_v2/networks/#mainnet-archives) fetchhub-3 archive node