Advance notice: Gaia v28.0.0 ICS provider module removal

Gaia v28.0.0-rc0 is scheduled to run on the Cosmos Hub public testnet ahead of an upcoming mainnet software upgrade proposal. The release removes the Interchain Security (ICS) provider module from Gaia. The upgrade handler will also align the staking module’s `max_validators` parameter with the provider module’s `max_provider_consensus_validators` parameter. The upgrade handler will transfer the full remaining balance of the legacy `ConsumerRewardsPool` module account to the community pool. These legacy consumer-chain rewards would otherwise be lost because these are denoms that have been “stuck” in the consumer rewards pool account because they were never registered in a distribution allowlist. Moving them to the community pool preserves the balances, but does not distribute them to validators or delegators. Validators or other independent community members can calculate historical allocations and submit a separate governance proposal if they choose. The changelog also notes an API-breaking behavior change: queries for historical ICS messages, including `MsgAssignConsumerKey`, `MsgCreateConsumer`, and `ConsumerAdditionProposal`, will return empty stubs instead of historical…

Excerpt (1199 of 1392 characters). Read the whole post on the forum ↗

Thanks for the advance notice. From a wallet and support perspective at Gem Wallet, could you clarify whether the empty historical ICS responses affect only the module-specific query endpoints, or whether historical ICS transactions and events will also become unavailable through standard transaction searches or indexers?

If clients receive an empty stub, will there be a reliable way to distinguish “this query is no longer supported” from “no historical activity exists”? That distinction could help wallets and explorers avoid presenting a misleading empty history after the upgrade.

Hi! ICS events can be searched by messages, but the contents of the message will no longer be decoded by the binary. For example, comparing Gaia v27 and v28 builds: ` ``` gaiad-v27.6.0 q txs --query "message.action='/interchain_security.ccv.provider.v1.MsgOptIn'" -o json | jq '.txs[0].tx.body.messages[0]' { "@type": "/interchain_security.ccv.provider.v1.MsgOptIn", "chain_id": "", "provider_addr": "cosmosvaloper1w3mu723wf4sf2pmn8y847gd32ncp42sp9z8f9n", "consumer_key": "{\"@type\":\"/cosmos.crypto.ed25519.PubKey\",\"key\":\"hLJaXG/JJWeSzj5X2wkcQzUhzhggzqL4FChd+bvmko0=\"}", "signer": "cosmos1w3mu723wf4sf2pmn8y847gd32ncp42spqknufq", "consumer_id": "148" } gaiad-v28.0.0-rc0 q txs --query "message.action='/interchain_security.ccv.provider.v1.MsgOptIn'" -o json | jq '.txs[0].tx.body.messages[0]' { "@type": "/interchain_security.ccv.provider.v1.MsgOptIn" } ``` The event contents remain available though: ` ``` gaiad-v28.0.0-rc0 q txs --query "message.action='/interchain_security.ccv.provider.v1.MsgOptIn'" -o json | jq '.txs[0].events[] | select(.type=="opt_in")' { "type": "opt_in", "attributes": [ { "key": "module", "value": "provider",…

Excerpt (1189 of 1565 characters). Read the whole post on the forum ↗

Thanks, that distinction is clear. So the transactions remain searchable and the event attributes remain available, while the removed message types retain only their @type and are no longer decoded by the Gaia v28 binary.

That should help clients avoid interpreting an empty message body as missing transaction history. Appreciate the concrete v27/v28 comparison and testnet reference.

Thanks for the advance notice.

It was smooth upgrade on testnet