Local spec copy saved as: research/crypto/whitepapers/interchain-security-ics-028-spec.md
Key takeaways from primary sources
ICS is a formal shared-security protocol, not just a branding label for launching near the Cosmos Hub. The clearest sources describe it as an open-source IBC application with a spec, production implementation, and ordered provider-consumer channels.
The most important mechanism is validator-set export plus provider-side enforcement. Consumer chains receive validator updates over IBC, but slashing and jailing still happen against stake on the provider chain.
Partial Set Security matters because it turns shared security into a configurable product. A consumer chain can compel the top share of provider voting power to participate or run as a fully opt-in market for validator attention.
Permissionless ICS reveals a key governance boundary: opt-in chains can launch by transaction, but Top-N chains still require governance because they force validator participation. That means “permissionless shared security” is real only for one branch of the design.
Power Shaping is one of the strongest reasons to keep ICS in the corpus. The docs show that allowlists, denylists, validator caps, power caps, minimum stake, and inactive-validator eligibility all shape the practical security profile. The control surface is therefore more about validator-set policy than the simple headline that a chain “inherits Hub security.”
The docs explicitly say governance can be separated from block production. That makes ICS a useful comparison class for restaking and shared-security systems that blur governance and security more tightly.
Specific source signals worth retaining
hub/latest/interchain-security/README: cleanest high-level statement that Hub validators validate consumer chains and that consumer chains share revenue with Hub token holders.
introduction/overview: best source for why teams might use ICS, especially the separation of governance from block production, instant sovereignty framing, and provider-side slashing model.
features/partial-set-security: clearest articulation of Top-N versus Opt-In security modes and the tradeoff between guaranteed provider stake share and permissionless launch.
features/permissionless: especially useful for owner / governance distinctions, consumer IDs, launch phases, and the fact that Top-N still routes through governance even in the permissionless era.
features/power-shaping: strongest source for the real control surface — power caps, set-size caps, allow/deny lists, minimum stake, inactive-validator support, and priority rules.
ICS-028 spec: best source for treating ICS as a concrete cross-chain protocol rather than a product page.
Why this entry belongs in the corpus
ICS earns a place because it provides a canonical shared-security mechanism with unusually legible governance and validator-selection surfaces.
It is a strong comparison class for Babylon, EigenLayer-adjacent systems, and staking middleware because it makes clear which chain owns bonded stake, who can compel validator participation, and where slashing actually lands.
The reusable insight is that a chain can rent block-production security while keeping separate governance and app logic, but the real centralization risk then shifts into launch permissions, validator-selection rules, and provider-governance control over the shared security marketplace.
Whitepaper / docs status
No classic standalone whitepaper surfaced in this pass.
The best primary materials were the official docs, production repo, and formal ICS-028 Cross-Chain Validation specification.
Local spec path: research/crypto/whitepapers/interchain-security-ics-028-spec.md