Advance notice: Gaia v28.0.0 ICS provider module removal

Conversation Hub Unit
1

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 data.

The release can be found here.
The changelog can be found here.

Feedback from validators, node operators, and Cosmos Hub users is welcome before the mainnet proposal is submitted.

4 Likes
Hub Weekly Update #12: August 13, 2026
2

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.

2 Likes
3

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",
      "index": true
    },
    {
      "key": "consumer_id",
      "value": "148",
      "index": true
    },
...

We upgraded the testnet today, feel free to test the queries there!

3 Likes
4

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.

2 Likes
5

Thanks for the advance notice.

1 Like
6

It was smooth upgrade on testnet

1 Like