Cosmos Interchain Security: Provider Chains, Validator Duties, Rewards, and Slashing

Interchain Security (ICS) connects separate Cosmos chains through the Inter-Blockchain Communication (IBC) protocol. A provider chain manages a validator set, while a consumer chain uses eligible provider validators to produce and confirm its own blocks. The chains still run separate state machines, keep separate ledgers, and may have different fees, tokens, governance, and application rules.

“Shared security” describes the relationship between the networks, not a transfer of the delegator’s coins into the consumer chain. A delegator’s ATOM remains bonded under provider-chain staking rules. The consumer chain receives validator participation backed by that provider stake, and its protocol can report certain validator faults back to the provider. A wallet balance, a consumer-chain token, and provider-chain bonded stake are therefore different things.

ICS is also not just an IBC token bridge. IBC supplies authenticated communication between chains, but ICS uses a dedicated cross-chain validation application to relay validator-set changes and evidence. A token-transfer route can use ICS-20 without sharing a validator set. Conversely, a consumer chain’s security relationship does not make every application or token on it safe.

Cosmos Interchain Security overview · Interchain Security terminology

The provider does not necessarily copy its entire validator set to every consumer. With Partial Set Security (PSS), a consumer can select a subset. A Top N configuration selects validators by a configured share of provider voting power. An opt-in configuration asks eligible validators to volunteer for that consumer. These are distinct participation rules, and a chain’s current configuration determines which one applies.

Power-shaping settings can further narrow or rebalance the consumer set. Depending on the chain’s configuration, they can cap the number of validators, limit one validator’s share of consumer voting power, or apply allowlists and denylists. Such settings change the consumer’s own validator set; they do not rewrite the provider’s bonded stake distribution.

Some consumer launches require provider governance, while current documentation also describes permissionless launches for opt-in chains. Do not infer the launch path from the phrase “Cosmos chain.” Check the consumer’s chain ID, launch status, Top N or opt-in rules, power-shaping parameters, and the provider’s current governance process. The site’s documentation is versioned and these features can change.

Partial Set Security · Power shaping · Permissionless Interchain Security

A provider validator that participates in a consumer usually operates a separate consumer-chain node, follows that chain’s software and launch instructions, and keeps its signing infrastructure available. Consumer-specific consensus keys can be assigned instead of reusing the provider key. Separate keys reduce the chance that a compromise of one consumer node exposes the provider signing key, but they do not remove operational, software, or signing risk.

The chain’s participation rule affects who must run a consumer node. A Top N chain can make participation depend on provider voting power and its threshold. An opt-in chain generally relies on validators choosing to participate. Power caps or other shaping rules can alter the final consumer set. Validators should check eligibility, key assignment, binary hashes, spawn time, and monitoring requirements for the specific consumer.

Delegators do not usually start a consumer node themselves. Their provider-chain stake can support a validator that takes on this extra work, and consumer-chain penalties may flow back to that provider stake. Validator identity and uptime on the provider are therefore not the whole due-diligence question: consumer-specific participation and fault rules matter too.

Validator guide and startup sequence · Key assignment

When provider stake or eligibility changes, the consumer’s validator set may need an update. ICS sends validator-set changes through a Cross-Chain Validation (CCV) channel. A relayer transports messages between chains, while each chain verifies protocol-defined state and applies its own changes. The relayer is not the consumer-chain validator and does not decide which signatures count.

This coordination can make participation and exit timing more involved than on a standalone chain. The older CCV design specification describes validator-set-change packets and maturity notifications as part of protecting unbonding operations across chains. Current implementations have evolved, including changes to unbonding coordination. A consumer’s exact behavior depends on its protocol version and parameters, so a generic ICS article cannot promise that a provider undelegation will take a particular extra amount of time.

Before changing or withdrawing a delegation, read the current provider and consumer documentation, inspect pending unbonding records, and distinguish the chain’s normal staking period from any additional ICS-specific coordination. A relayer delay or an out-of-date client can also affect packet progress without changing the underlying rules.

CCV overview in the IBC specification · Validator guide

A consumer can report validator misbehavior to its provider. Current Interchain Security documentation separates downtime from equivocation such as double signing. Depending on the consumer’s configured infraction parameters and the evidence accepted by the provider, an event can lead to jailing, a stake slash, or both. The effect is applied through provider-chain rules, so a fault on one consumer can affect a validator’s provider position and eligibility on other consumers.

The precise response is not one universal percentage. Consumer-specific settings define slash fractions and jail durations, and protocol versions determine what evidence can be submitted and how it is handled. For example, missing enough blocks to cross a downtime threshold may trigger a provider-side jail; a valid double-sign proof can lead to a more severe response. These are rule paths, not predictions about a particular validator or chain.

A validator’s self-bond and delegators can share the economic effect when provider stake is slashed under the staking rules. Jailing can also remove the validator from the provider’s active set and, as a result, from consumer validator sets. Review the actual chain parameters and incident process instead of assuming that consumer faults affect only consumer-token rewards.

The current official guides do not describe downtime penalties uniformly: the validator overview says a Hub downtime infraction causes provider-side jailing without a slash, while the consumer-slashing feature page describes jailing and slashing under consumer-specific parameters. Treat this as a version and configuration question; verify the live provider implementation, parameters, and evidence path for the chain you are assessing.

Consumer-initiated slashing · Interchain Security overview

A consumer can choose to send a configured portion of its block rewards or fees to the provider as payment for security. The consumer periodically transfers those rewards through an IBC token-transfer channel. On the provider, only accepted reward denominations are distributed, and eligibility depends on the consumer’s rules. Current documentation notes that validators must be opted in and may need to validate continuously for a configured number of epochs before receiving rewards; their delegators can then share under provider distribution rules.

Consider a deliberately simplified example: a consumer records 12,000 units of eligible fees and inflation rewards for a period, and governance has set a 25% share for provider rewards. The arithmetic gives 3,000 units sent toward the provider reward pool before any implementation-specific processing. It does not tell you the value in dollars, a validator’s final allocation, the timing of a distribution, or a future rate. If voting-power caps apply, distribution weights can be based on the shaped consumer set rather than raw provider voting power.

A reward token may also be volatile, illiquid, or costly to claim. A displayed annualized figure can combine assumptions that change: consumer activity, reward share, eligible validators, commissions, provider distribution, denom registration, and the time a validator stays opted in. Treat consumer rewards as a variable protocol flow, not a guaranteed APY or a return that offsets slashing risk.

Reward distribution rules · Consumer validator rewards

Using provider validators can make it harder to attack a consumer than relying on a small new validator set alone. It does not make the consumer identical to the provider. The consumer has its own application software, governance, economic design, IBC clients and channels, operational dependencies, and any smart contracts or other modules it runs.

The validator set is only one part of the security model. A consumer’s configured subset may have different concentration and liveness properties than the provider’s full set. A client or relayer issue can delay coordination; a bug in consumer software can affect the consumer even if provider validators behave correctly; governance can change parameters; and a token may lose value independently of the validation mechanism.

“Secured by the Cosmos Hub” is therefore a description to investigate, not a complete risk rating. Ask which provider is involved, which validators participate, how their voting power is shaped, what evidence is slashable, which rewards are sent, and what the chain’s exit or changeover process is. Security is tied to a concrete configuration and operating period.

Terminology and security variants · Consumer governance

Start with the consumer’s exact chain ID and provider. Confirm whether it uses Top N or opt-in participation, whether power caps or lists modify the set, and whether the published validator list reflects the latest update. A count of validators alone does not show how voting power is distributed.

For a validator or delegator, verify whether the validator must opt in, which consensus key it uses for that consumer, whether it is running the correct binary, and how downtime or equivocation is handled. Read the current jail and slash parameters. If you are delegating, distinguish your bonded provider stake from any consumer rewards displayed by a wallet.

Finally, check the reward-denom allowlist, the number of epochs needed for eligibility, distribution and commission rules, consumer governance powers, relayer/client status, and the current undelegation or changeover procedure. Compare those details with provider-only staking and with a token transfer. They answer different questions and should not be collapsed into a single “shared security” label.

[Cosmos Hub staking: delegation and slashing](/learn/cosmos-staking-delegation-unbonding-slashing-validator-commission-explained) · [IBC packet transfers and relayers](/learn/cosmos-ibc-transfer-clients-channels-packet-timeouts-relayer-risks-explained) · Crypto staking vs. DeFi lending

Primary references: Interchain Security overview; terminology; Partial Set Security; power shaping; reward distribution; consumer-initiated slashing; validator guide; IBC cross-chain validation overview.