Disclaimer: This analysis reflects a personal perspective on the potential evolution of shared security within the Cosmos ecosystem. It does not represent any official position, nor that of the Hub team or any specific organization.
Introduction:
Partial Set Security (PSS) is the direct successor to Interchain Security (ICS), whose decline seems confirmed with Neutron’s departure. PSS can be defined as a free-market mechanism between Cosmos Hub validators and consumer chains, allowing the latter to replicate the economic security of validators (staked in ATOM) on their own networks.
Today, it is increasingly necessary to deeply rethink PSS to make it more market-aligned and ecosystem-relevant.
The limitations of ICS quickly became apparent, especially in terms of economic yield for validators and network liveness. PSS emerged from these shortcomings, offering a more liberal approach to validation, based on the expectation of profitability.
Two models were proposed:
- PSS Opt-in, where validators choose whether to participate in securing a consumer chain.
- PSS Top-N, where only the top validators based on delegated ATOM are selected.
For more information on these models, see ICS 2.0 Economics : Partial Set Security (PSS) Financial Model
However, in practice, PSS has failed to convince most chains, which have preferred to launch their own tokens, used as slashing collateral in their own consensus models. This is exactly what Neutron chose when leaving ICS: instead of relying on PSS, they decided to use their native token as their economic security base.
The Arrival of ICL: A New Direction for the Hub
The development of @InterchainLabs opens a new perspective. This model moves away from strict shared security and positions the Cosmos Hub more as a router-focused network, centered on IBC services and native smart contract execution. The goal is to enable permissionless deployment of multiple virtual machines (EVM, CosmWasm, etc.) directly on the Hub.
Interchain Labs aims to integrate blockchain applications natively within the Hub, without the overhead of launching costly L1 chains. The objective for me is clear: fill Cosmos Hub blocks with useful applications before reconsidering the relevance of PSS.
Replicated security becomes relevant only when there is a true need for sovereign execution or additional blockspace, which is not the case for DEXs, lending protocols, or typical DeFi apps, all of which can operate as smart contracts.
This observation questions not only the current utility of PSS but also the economic model of many Cosmos L1s, which struggle to justify their existence within an expensive and often underutilized blockspace environment. As time passes, launching new chains merely to sell blockspace appears increasingly irrationalexcept perhaps for airdrop farmers, VC backed projects, or founders looking to sell overvalued tokens. When this speculative cycle ends, many chains will be unable to sustain token demand based solely on commoditized blockspace.
Amid this turbulence, does shared security still make sense? Can its utility be reimagined and positioned as a core strategic asset of the Cosmos Hub?
In practice, shared security can serve two distinct purposes: on the one hand, blockspace replication, and on the other, enterprise-grade sovereign blockspace. Thus, we must distinguish two separate use cases and therefore two separate products within shared security: Replicated Blockspace (RB) and Private Blockspace (PB).
Replicated Blockspace (RB): A Scaling Tool for the Cosmos Hub
With the imminent deployment of permissionless virtual machines (EVM, CosmWasm, etc.) on the Cosmos Hub via ICL, blockspace saturation becomes a plausible future.
In such a scenario, blockspace scarcity would mechanically drive up transaction fees, as demand exceeds available capacity.
This is where a specific implementation of replicated security, geared toward internal scaling, becomes relevant. RB offers a flexible solution by dynamically launching mirrored chains to absorb excess demand.
RB: Auxiliary Chains, Same Contracts, Same UX
These replicated chains would operate with the same technical stack as the main chain (the Hub), using the same smart contracts, VMs, interfaces, and Cosmos Hub addresses. For end users, no distinction would be visible they interact with their dApps as usual, unaware that they’ve been redirected to a Replicated Blockspace (RB).
RB deployment could be triggered automatically based on congestion thresholds or governance-controlled, depending on network elasticity needs. (There are also likely parallels to be drawn with the previously proposed “megablock” concept discussed on the forum.)
In this implementation of replicated security, the Hub retains sole ownership of the replicated chains, which function as temporary modular extensions of Hub blockspace, not as sovereign external chains.
Challenges to Anticipate
While this vision enables fine-tuned supply-demand balancing of blockspace, it comes with technical challenges:
- Need a smooth deployment and shutdown of RB chains without user disruption.
- Increased validator workload, as they need to track RBs alongside the main chain.
- Mechanisms for seamless user and asset migration between the main chain and RBs via IBC upon shutdown.
- Block utilization remains a key challenge if adoption fails to saturate the Hub, there’s no need to scale this way.
In short, this technology is not yet essential. Adoption is still limited, blocks remain underutilized, and there is no justification for immediate scaling but I’m hoping that with ICL, we are, in some sense, moving toward saturating the chain. Yet many L1 projects continue to compete for a slice of the pie one wonders how they manage to sell such empty blockspace.
In this version of Replicated Security, the Hub remains sovereign over the RB chains. In many ways, this model resembles PSS Top-N, but with a more flexible, focused use case: blockspace management.
However, beyond scaling, replicated security can address a second use case, this time targeting economic actors seeking dedicated consensus and autonomous governance. This is where the concept of Private Blockspace (PB) comes into play.
Private Blockspace (PB): A New Enterprise Oriented Use of PSS
Unlike public smart contract execution on the Hub, Private Blockspace (PB) caters to concrete and operational use cases, offering enterprises, associations, and institutions a self-managed, sovereign blockspace.
This model closely aligns with the PSS Opt-in approach, where validators and chains freely choose their validation relationships.
PB must be accessible, simple, and plug-and-play any organization should be able to launch its own chain in just a few clicks, selecting parameters tailored to its needs:
- Privacy levels,
- Governance and decision-making models,
- Block production frequency,
- Automated accounting frameworks,
- Simplified tax integration (e.g., automated tax payments, IBAN/RIB setup),
- Validator reward schemes (fixed margin or percentage-based),
- Bundled services (website hosting, dashboards, enterprise tools).
In short, PB aims to be an all-in-one solution, a “Forge Endgame” enabling any organization to own and manage its own Web3 infrastructure to sell real products and services, without deep technical expertise.
Reducing Validation Costs: A Core Challenge for PB
A key obstacle remains: validation costs, often disproportionate to the economic value generated, limit PB adoption.
To address this, PB must be redesigned as an ultra-low-cost operational system. A promising approach would include:
- Implementing lazy consensus models, with highly spaced block production,
- Compensating slow block times with pre-validation via zero-knowledge proofs provided by the Hub or a specialized consumer chain.
This significantly reduces validator workload, maintains cryptographic integrity, and ensures validator profitability without overburdening the consumer chain.
Although still a forward-looking vision, Private Blockspace paves the way for a new era of Web3 in which organizations and enterprises truly own their infrastructure, manage payments, accounting, logistics, and liquidity directly, while remaining fully interoperable through IBC and seamlessly connected to the broader DeFi ecosystem for lending, liquidity, and financial services.
PB represents a pragmatic, sovereign, modular, enterprise-centric Web3, where the blockchain becomes an integrated business management tool.
Conclusion
Replicated security is not dead. While the industry currently favors launching native tokens, this model may not remain sustainable. Eventually, the ecosystem will realize that blockspace is infinite, and it is extremely difficult to monetize it with a token that may never deliver true profitability.
In this context, the Cosmos Hub is well-positioned to offer secure blockspace services, backed by professional validators and ATOM collateral. RB and PB thus becomes a coherent way to offer protected, need-based blockspace, ensuring both Hub profitability and reliable services for enterprises.
These enterprises create value through real economic activity (e-commerce, logistics, etc.), not speculative farming. The Hub can become a critical infrastructure provider to this real economy, by offering sovereign, secure, and tailored blockspace aligned with real-world use cases.
This vision remains, for now, a theoretical proposal that I could further develop. However, in practice, the likelihood of seeing concrete developments around a new model of replicated security is relatively low, mainly due to the Cosmos Hub’s current focus on IBC services and permissionless smart contract platforms.
Nonetheless, I firmly believe that the concept of replicated security offers a healthier and more sustainable alternative to centralized L1 blockchains, often built around VC-backed tokens with limited decentralization.
In the long run, I am convinced that developments aligned with this vision will eventually emerge, likely driven by the gradual decline and fatigue surrounding the proliferation of layer 1 tokens in today’s market.
Given the technical depth of my essay and the assumptions I’ve made, I would greatly appreciate feedback from experts like @thyborg or @jtremback regarding the ideas developed around Replicated Blockspace (RB) particularly the complexity such an approach would entail.
I would also be very interested in their insights on the Private Blockspace (PB) concept, as well as on the technical challenges of implementing a lazy blockspace model compensated by zero-knowledge proofs (ZKPs). These elements, in my view, are essential to rethinking the future of replicated security and building sustainable and economically viable models.
Thanks for reading !
