<aside> <img src="/icons/info-alternate_gray.svg" alt="/icons/info-alternate_gray.svg" width="40px" /> Interchain Security is the shared security solution within Cosmos. This effectively allows chains to be secured through the ATOM token and the relatively high market cap of the Cosmos Hub.

In this article for technical decision makers you'll find a brief explanation about how it works and why it might make sense for your chain to launch with Interchain Security.

</aside>

Overview

Cosmos has emerged as the leading platform for building blockchains devoted to a single application. Cosmos chains provide more scalability, configurability, and sovereignty than deploying a contract on a smart contract platform such as Ethereum.

However, Cosmos chains have historically had a major challenge to overcome: they must be secured by a decentralized validator set, with a valuable staking token. This has been a hurdle for many projects that would otherwise benefit from running on a Cosmos chain. Putting together a validator set can be a distraction from building a community of engaged users, and building in a staking token can complicate a project’s tokenomics. Furthermore, the chain’s security is directly tied to the market cap of the staking token, which may take time to increase in value, thereby subjecting the project to numerous security risks along the way to maturity.

With Interchain Security, developers will be able to launch a chain running their EVM, CosmWasm, or Cosmos SDK application. This chain will be secured by the validator set of the Cosmos Hub and the full market cap of the ATOM. This is known as a consumer chain, since it “consumes” security from the Hub (the provider chain).

Sovereignty and Incentivization

It is important to note that each consumer chain’s transactions are not being executed on the provider chain. Each chain retains its sovereignty because both the execution layer and the data layer are independently hosted on-chain. This means that the Cosmos Hub maintains enough blockspace to keep executing its core functions, and that netto blockspace for the total Interchain Secured network is effectively increased. To achieve this, validators are obligated to run a separate validator node for the consumer chain, once this chain has been approved through an on-chain governance process.

As you might imagine, the validators and ATOM delegators who get to vote on such a governance proposal would rightfully ask what is in it for them, because running a validator node for a new chain comes with additional costs. This mechanism is intentionally designed to incentivize consumer chains to design their applications to benefit ATOM holders, through either providing native token rewards or additional value to the ATOM token that would otherwise not be generated on the Cosmos Hub itself.

How it works

At its core, Interchain Security is an implementation of the Cross Chain Validation (CCV) specification. Using the Inter-Blockchain Communication (IBC) protocol, packets are relayed to make sure the consumer chain knows which validators are securing the Cosmos Hub and how much voting power they have. At the same time, the consumer chains need to tell the provider chain when there is evidence of misbehavior so that validators can get slashed on their ATOM tokens on the Cosmos Hub - an essential mechanism under Proof-of-Stake.

The IBC protocol is comprised of several Interchain Standards (ICSs) that make up the protocol. The specification for Cross Chain Validation is known as ICS-028.

Each chain that is part of the Interchain Secured network contains either a provider or consumer CCV module which takes care of the following tasks:

• Channel Initialization: After a governance proposal to add a consumer chain passes, the provider chain creates a light client of the consumer chain which relayers use to initiate the connection. Once the consumer chain starts running at the spawn_time, validators are expected to have their nodes up and running on the consumer chain. Relayers then create the channel which is dedicated to Cross Chain Validation.
• Validator Set Changes: If a validator on the Cosmos Hub changes its voting power through a change in delegations or through being jailed, this change needs to be communicated to all consumer chains. The provider CCV module sends what is called a Validator Set Change (VSC) using the IBC protocol. The consumer CCV module applies these changes to its consensus engine and communicates that the changes have been applied to the provider chain, which then registers its success in its own CCV module.
• Consumer Initiated Slashing: If a validator misbehaves on the consumer chain, the provider chain needs to be informed so that it can slash a portion of the staked ATOM. Once the evidence has been submitted to and accepted by the consumer chain, it then uses the CCV channel to transfer a SlashPacket to the Cosmos Hub, which then executes a slashing operation on the staked ATOM. In some cases, a (temporary) jailing of the validator can also occur. This effectively means that if a validator misbehaves and gets jailed on one consumer chain, it will be affected on all consumer chains, as well as the Cosmos Hub.
• Reward Distribution: Similar to other Cosmos SDK chains, consumer chains can have a native token that gets paid out as a block reward for validators and delegators. At each block, a fraction of the block rewards is transferred to the consumer’s CCV module. These tokens are then transferred to the distribution module on the Cosmos Hub at regular intervals through an IBC token transfer. The distribution module then distributes the tokens to validators and delegators as it ordinarily would for ATOM tokens.

If you would like to learn more about how these tasks are executed, you can find a detailed explanation in the specification.

Why use Interchain Security?