# 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
Last changed by  
 
Galadrin
117

Read more

Testnet OKP4

As a major player in the Cosmos ecosystem, the French company OKP4 has invited us to participate in its incentive test network. Code name Nemeton. OKP4, Open Knowledges Protocol For OKP4 is a blockchain dedicated to sharing data with minimal trust. The blockchain orchestrates the assets shared by participants in the Dataverse: data, algorithms, software, storage and computation to enable a new generation of applications. Any contributor earns rewards from these new value chains. OKP4 will allow anyone to create and share an infinite number of dataspaces. A dataspace is a digital community that fosters the knowledge economy by allowing data to be shared in confidence between dataspace members.

12/19/2022
The life of a blockchain

Validator role A validator is an entity running one or multiple nodes on a blockchain network. Its role is to ensure that the blockchain works efficiently and with the maximum safety for the users. A validator can be a precious ressource for core developer teams who need trusted entities to operate a blockchain in the most decentralized way possible. Validators can have multiple roles during all the phases of development of a blockchain project which we will highlight below. Before the testnet During the development phase, the validator can take an advisory role and provide insight to help the developer team make the right decisions. They can provide some infrastructure to run devnet or early private-testnet to test a first scale increase. Their knowledge and experience with multiple blockchain networks is a precious source of information to avoid mistakes like transaction floods and huge block size.

12/14/2022
Osmosis IBC relayer list

If this list is outdated or incomplete please add comment Ordered alphabetically Validator Contact Info 3Tekos Twitter @3Tekos

3/22/2022
Juno network recovery

Introduction This document describes how to install and use the recovery tool to recover funds. The tool is to be used in a specific circumstance, when: The seed phrase of the user was leaked and the stake is bonded The tool needs the following information: A 12 or 24 word seed phrase The new address of the owner

1/17/2022
Read more from Galadrin
Published on HackMD