App-chains and shared security: Cosmos, Polkadot, and superchains

From point-to-point bridges to whole ecosystems

Picture an archipelago. In the earlier guides of this rung you stood between two islands and built rope bridges one at a time: you learned lock-and-mint to carry a token across, you mapped the trust models that hold each rope up, and you read the post-mortems of the ones that snapped — Ronin, Wormhole, Nomad. Then you generalized from moving coins to passing arbitrary messages. Every guide ended at the same uncomfortable place: each new pairwise bridge is a new thing that can break.

The arithmetic is brutal. Connect n chains pairwise and you may need up to n(n−1)/2 bridges — 10 chains is 45 ropes, each a honeypot holding locked collateral. The ecosystem builders looked at that and made a different bet: instead of n chains each defending themselves and bolting bridges on afterward, design the chains from the start to share one security base and one native messaging layer. Interop and safety become properties of the foundation, not afterthoughts.

Two questions slice the entire design space. First: who provides each chain's security — does it recruit its own validators, or borrow someone else's? Second: how sovereign is each chain — can it set its own rules, validator set, and upgrade path, or must it conform to a shared parent? Cosmos, Polkadot, rollup superchains, and restaking are four different answers, and they trade shared security against sovereignty in opposite directions. Hold those two axes in your head; they are the spine of this whole guide.

Cosmos: a galaxy of sovereign chains stitched by IBC

Cosmos puts sovereignty first. A chain built with the Cosmos SDK runs Tendermint/CometBFT and is fully its own master: its own validator set, its own staking token, its own governance, and its own state-transition rules. The mantra is "one app, one chain." Nobody upstream can force an upgrade on you or include a transaction you don't want.

These sovereign chains talk through IBC, the Inter-Blockchain Communication protocol. The previous guide walked the channel handshake; the part that matters here is why it is trust-minimized. Chain B does not trust a multisig to relay from chain A — it runs a light client of A inside its own state machine and verifies a Merkle proof that A actually committed the packet. A relayer just ferries bytes; it cannot forge anything. So an IBC link is only as strong as the two chains' own consensus, and it is permissionless any-to-any: the Cosmos Hub is one convenient router, not a required intermediary.

// Chain B accepts a packet from Chain A. No multisig, no oracle:
// B verifies A's own committed state with a light client.
func recvPacket(packet, proof, proofHeight):
    client = clients["chain-A"]                  // light client of A, run by B
    root   = client.consensusState[proofHeight]  // a header root B already trusts

    // Membership proof: A's commitment tree really contains this packet
    assert verifyMembership(root, proof,
                            commitmentPath(packet),
                            hash(packet.data))

    // Only now does B act on it (e.g. mint a voucher token)
    runModuleLogic(packet)
    writeAck(packet)

// Security = min(consensus of A, consensus of B). A relayer that lies
// simply fails verifyMembership; it can stall, never forge.

Sovereignty has a sharp edge, though: you must bootstrap your own security. A brand-new app-chain whose token is worth $5M can be cheaply attacked — buy or rent enough stake to control a third of its validators and you can halt it; control two-thirds and you can finalize lies. The chain's safety is bounded by its own staked value, and a young token is thin. This is the dark side of "one app, one chain": the bootstrapping problem and the ever-present cheap-attack risk.

Cosmos's answer is replicated security (Interchain Security), which launched with the Neutron chain in 2023. A "consumer" chain rents the entire Cosmos Hub validator set instead of recruiting its own: Hub validators run the consumer chain's blocks and can be slashed on the Hub for misbehaving on it, while the consumer pays them fees and rewards. That is shared security, Cosmos-style — bolted on as an option, not baked into the architecture. It trades a slice of sovereignty for instant, deep security, and later designs (mesh and partial-set security) let a chain mix its own validators with rented ones.

Polkadot: pooled security under one relay chain

Polkadot starts from the opposite default: shared security is mandatory, not optional. At the center sits a relay chain that provides consensus, finality, and security for everything. The application chains — called parachains — plug into it like cards into a motherboard. A parachain does not have a validator set of its own at all.

Here is the mechanism that makes that safe. The relay chain has several hundred validators staking DOT. For each parachain block, a small group of them is randomly assigned to back the block — they re-execute it against that parachain's registered runtime (a Wasm state-transition function) and vouch for it. Then a larger random set of approval checkers re-verifies it, and the block's data is kept retrievable via erasure coding so anyone can challenge. Because the assignment is random and the whole staked set stands behind it, you cannot cheaply attack one parachain without attacking all of Polkadot at once. Every parachain inherits the full economic security of all staked DOT.

Parachains message each other with XCM (cross-consensus messaging). Because the relay chain already validated both ends, an XCM message is trust-minimized by construction — no external bridge sits in the middle. An XCM "program" is a little list of instructions the destination executes:

// XCM: move 1 DOT to an account on the destination parachain,
// paying execution fees out of the same assets. Instructions run top-down.
[
  WithdrawAsset([{ id: DOT, amount: 1_000_000_000_000 }]),   // 1 DOT (12 dp)
  BuyExecution({ fees: { id: DOT, amount: 100_000_000_000 }, // 0.1 DOT for weight
                 weightLimit: Unlimited }),
  DepositAsset({ assets: All,
                 beneficiary: { parents: 0,
                                interior: AccountId32(0x9c3a...f1) } })
]
// The relay chain secured both chains, so no lock-and-mint bridge is needed:
// this is native, validated cross-chain execution.

The cost is sovereignty. A parachain must conform to the relay chain's validation cadence and to a limited supply of execution "cores." Historically you had to win a parachain slot in a DOT auction (with crowdloans of locked DOT); in 2024 Polkadot replaced auctions with agile coretime — you buy blockspace in bulk or on demand, like cloud compute. And you cannot swap in your own finality gadget or fork away on a whim: the relay chain's rules are the rules. You get bank-vault security; you give up being your own bank.

Rollup superchains: many L2s sharing Ethereum

The Ethereum-native version uses neither a Hub nor a relay chain — the shared base is Ethereum itself, acting as a settlement layer. From the scaling rung you already know how a single rollup borrows Ethereum's security: it executes off-chain but posts its data and a state commitment (plus a fraud or validity proof) back to L1, so anyone can reconstruct and challenge it. A superchain is many rollups doing this together, sharing one settlement contract, one bridge, and one upgrade framework.

The clearest example is the OP Stack Superchain: OP Mainnet, Base, and others run identical OP Stack software, share a standard bridge and a shared registry, and settle to Ethereum — increasingly enforcing correctness with permissionless fault proofs. Because they share a design, a single security upgrade or a new fault-proof system benefits every member chain at once, instead of each re-auditing its own bespoke bridge. Polygon's AggLayer pushes a complementary idea: a unified bridge across many chains backed by a pessimistic proof, which guarantees no connected chain can ever withdraw more than was deposited into it — even if that chain's own prover is buggy — giving near-instant cross-chain movement without a separate trusted bridge in between.

Within a superchain, each rollup keeps execution sovereignty — its own sequencer, fee token, even its own VM — while inheriting Ethereum's security through the settlement layer. Contrast this with a sovereign rollup, which posts its data to a separate availability layer and enforces its own rules: more sovereignty, but it does not inherit Ethereum's settlement security, so a contested state has no L1 to appeal to. Be honest about today's reality, though: most superchain rollups are still "Stage 0/1" — upgradeable by a multisig security council and run by a single sequencer — so the "full Ethereum security" is partly aspirational, and shared sequencing (one sequencer ordering many chains for atomic cross-rollup actions) is still emerging.

Restaking: security as a rentable commodity

The newest twist turns shared security into a market. Restaking, pioneered by EigenLayer, starts from a simple observation: the enormous pool of ETH already staking Ethereum is doing exactly one job — securing the base chain. Restaking lets that same stake opt into securing additional services too, reusing one capital base many times.

The mechanism: an operator holding restaked ETH opts into an AVS — an actively validated service such as a data-availability layer, an oracle network, a bridge, or a brand-new chain. The AVS defines its own slashing conditions. If the operator misbehaves on the AVS, its restaked ETH is slashed by the AVS's rules. So a young service can rent a slice of Ethereum's gigantic security budget on day one instead of bootstrapping a fresh validator set and token — the same problem that haunts a new Cosmos chain, solved from the other direction.

// Restaking: one stake, reused to secure extra services.
operator.restake(stakedETH)              // ETH already securing Ethereum L1
operator.optIn(daLayerAVS)               // take on EXTRA duties + EXTRA risk
operator.optIn(oracleAVS)

// Each AVS enforces its OWN slashing logic on the SAME collateral:
if daLayerAVS.provedFault(operator, evidence):
    eigenlayer.slash(operator, amount)   // burned from the shared restaked ETH

// Upside: a 1-day-old service rents Ethereum-grade security.
// Downside: one stake backs many services -> CORRELATED slashing risk.

Be clear-eyed about the danger. Because one stake backs many services, restaking introduces correlated and cascading slashing risk: a single bug, or a coordinated fault across services an operator opted into, could trigger mass slashing and ripple back into Ethereum's own validator set. Vitalik Buterin warned in 2023 against "overloading" Ethereum's social consensus by making it the backstop for too many external responsibilities. Restaking is genuinely powerful — it makes security a tradeable commodity — but a commodity market also imports market-style systemic risk.

The sovereignty–security spectrum (and the modular endgame)

Line the four designs up on one axis and the pattern is clear. At the full-sovereignty end sits a Cosmos zone with its own validators: maximum control over rules and upgrades, but you own the bootstrapping problem and live with a thin security budget. At the shared-security end sit a Polkadot parachain, an OP Stack rollup, and a restaked AVS: strong inherited security from day one, but you accept someone else's validators, cadence, or upgrade keys. Replicated security and restaking are the middle ground where you rent security à la carte.

1. Security budget vs your token's market cap. If your own staked value can't deter a 51% attack, inherited or rented security is not a luxury — it is survival.
2. How much sovereignty you actually need. A custom VM, a custom fee token, or governance that can't be overruled may be worth bootstrapping for; if not, conform and inherit.
3. Liveness coupling and shared blast radius. If the relay chain, shared sequencer, or restaked service halts or is slashed, do you halt with it? Shared security shares failures too.
4. Exit and migration cost. Sovereign chains can fork away cleanly; a parachain tied to coretime or a rollup tied to one settlement contract cannot leave on a whim.
5. Messaging trust. Native light-client messaging (IBC, XCM) is trust-minimized; an external bridge between siloed chains re-introduces exactly the honeypot you spent this rung learning to fear.

Step back and these stop looking like rival religions and start looking like a menu. The modular blockchain thesis says exactly this: stop building monolithic chains and instead pick your execution, your settlement, your data availability, and your security source separately, mixing and matching to taste. The goal of the whole rung — true omnichain interoperability — is a world where a user moves value and calls contracts across all of it without ever feeling the seams.