Update for the community on why Cosmos Labs is considering shutting down ICS (Interchain Security).
Here are the main arguments shared by Robo during Cosmoverse in the official Cosmos Telegram group along with an analysis of how valid they really are.
The arguments from Robo
1. “Nobody wants to use it.”
This was mostly true for ICS v1. Adoption was low because it was:
- complex to integrate
- highly centralized (the Hub controlled governance)
- and costly compared to the benefits.
But newer models like Partial Set Security (PSS) and Opt-in Security directly fix this:
- Chains can choose which validators secure them
- and only pay for the portion they actually use.
So while the early version failed to attract users, the updated models have real potential and I want to remember that Public chains are using it. Stride, Intento, Elys, neutron, dungeon. Some of them left because of CL missalignement with their roadmap and lack support.
2. “It’s expensive for validators.”
True.
Under ICS v1, every validator on the Hub had to run every consumer chain which made it expensive and difficult to scale.
Partial Set Security changes this completely:
- Only validators who opt in to a specific consumer chain need to run it.
- The rest of the validator set stays lightweight.
- This means lower operational costs and better scalability.
Some validator is ready to run Stargaze software for free to bootstrap PSS.
3. “It’s a barrier to speeding up the chain.”
Valid, but mostly for the Hub, not for consumer chains.
The synchronization and governance dependencies between the Hub and consumers can slow upgrades or execution.
Since Cosmos Hub’s new vision is to become a service provider chain, being tied down by ICS logic does reduce flexibility.
So, this point makes sense from Cosmos Labs’ perspective
4. “Enterprises want full sovereignty.”
Absolutely true for many use cases.
Some organizations or projects need:
- full control over their validator set and governance
- no dependency on external chains for security
- and predictable upgrade autonomy.
That’s why they wouldn’t use ICS, they want sovereign infrastructure.
But this doesn’t mean ICS or shared security are useless; they’re simply better suited for smaller teams, new appchains, or interoperable ecosystems that can benefit from shared trust.
Summary
Robo’s arguments are valid for the original ICS model, but less so for the new Partial Set and Opt-in Security architectures, which are cheaper, more modular, and more flexible.
Personal Questions & AI Answers about PSS (Partial Set Security) and the Hub
Why would PSS slow down the Cosmos Hub if consumer chains are independent?
Your thought:
“Consumer chains under PSS are separate, so why would PSS impact Hub performance?”
Answer:
PSS is way lighter than the original ICS, so it doesn’t directly slow down the Hub’s block production or governance.
However, there are still operational and coordination frictions that the Hub must handle:
-
Even with a partial validator set, Hub governance still has to onboard and offboard consumer chains, BUT not true for Opt-in feature.
-
Validators who opt in still depend on the Hub’s validator registry and staking module.
-
Some cross-chain updates still require Hub-level proposals or coordination (especially validator changes or reward parameters).
So while PSS minimizes the burden, it doesn’t remove it completely, it still ties part of the Hub’s governance cycle to consumer management.
It’s much better than ICS v1, but not totally frictionless.
Couldn’t the Hub improve its performance without affecting PSS?
Your thought:
“If PSS is lighter, can’t the Hub just upgrade or optimize itself without impacting it?”
Answer:
Mostly yes, that’s one of the strengths of PSS.
Because validator participation is opt-in, the Hub can upgrade most of its modules without having to synchronize all consumers.
However, there are still some interdependencies:
-
PSS consumers depend on the Hub’s staking logic (validator set, slashing, rewards).
-
If the Hub makes deep protocol changes to these areas, consumers might need to adapt.
So while PSS greatly reduces coordination overhead, the Hub still carries the validator-set logic for those consumers, which means some coupling remains.
Is PSS a bad model, or just a bad fit for Cosmos Hub’s new direction?
Your thought:
“Maybe PSS itself isn’t bad, it’s just not aligned with what the Hub wants to be?”
Answer:
PSS is actually a strong model, flexible, scalable, and more practical than ICS v1.
But Cosmos Hub’s new roadmap aims to make it a “service provider chain”.
In that context, managing validator security for other chains, even partially, is not a strategic priority anymore.
It’s not that PSS doesn’t work; it’s just that it’s not the type of service the Hub wants to offer.
Isn’t being a “security provider” still a service?
Your thought:
“If the Hub provides security to other chains, isn’t that also a kind of service?”
Answer:
Yes, but not the kind Cosmos Labs wants the Hub to focus on.
Being a security provider is a low-level infrastructure service (consensus, validator set, slashing).
Being a service provider, in the new sense, means offering application-level, modular services via IBC, things like:
-
Eureka
-
skip.go ?
-
Fleet manager ?
-
Asset issuer ?
So, Cosmos Labs wants the Hub to move up the stack, from security infrastructure to application and coordination layer.
“Security is a service, just not the kind of service Cosmos Hub wants to specialize in anymore.”
| @RoboMcGobo I am right ? |
|---|