# Interoperability

Sovereign rollups mark a significant evolution in Layer 2 design. Instead of delegating cross‑chain validation to a settlement‑layer bridge contract, a sovereign rollup *runs its own light‑client verification* of counterpart chains and therefore decides—at the application level—*how* and *with whom* it communicates.\
This architecture preserves rollup autonomy while still allowing trust‑minimised data availability (DA) and settlement on an external layer.

***

## Traditional Smart‑Contract Rollups

In a classical optimistic/ZK rollup, every cross‑chain action must pass through **one hard‑coded “enshrined” bridge** that lives on the Layer 1 settlement chain.

**Execution path**

1. **Rollup contract on L1** – stores state roots and bridge logic.
2. **Proof/optimistic window** – rollup posts proofs or roots; the bridge contract adjudicates fraud/ZK proofs.
3. **Outbound transfers** – users lock assets inside the bridge; withdrawal proofs are verified by the contract.
4. **Upgrade friction** – any change to bridge semantics requires an L1 contract upgrade (often via governance hard fork).

**Limitations**

* **Single‑point trust** – the bridge contract becomes systemic risk.
* **No heterogeneous bridges** – applications cannot add new channels without L1 governance.
* **Wrapped assets** – most bridges mint IOU tokens instead of native transfers.
* **Throughput bottleneck** – all messages queue in the same contract; gas spikes propagate to rollup users.

***

## Sovereign Rollups

A sovereign rollup publishes its data (blobs, state roots) to a DA layer but *self‑verifies* other chains via on‑chain light clients or validity proofs.\
Bridges become regular modules that can be permissionlessly deployed and upgraded.

### Technical Properties

| Capability                      | Implementation Detail                                                                                                |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Self‑sovereign verification** | Embedded light client or ZK verifier for each remote chain; no dependency on an external bridge contract.            |
| **Multiple protocols**          | Support for IBC, custom SNARK bridges, or token‑specific channels in parallel.                                       |
| **Native asset movement**       | Light‑client verification lets the rollup unlock *original* tokens, avoiding wrapped IOUs.                           |
| **Composable channels**         | Each application can instantiate independent channels with custom fee logic, rate limits, or middleware.             |
| **Decoupled upgrades**          | Bridge logic is a rollup module; upgrading does **not** require L1 governance—only rollup governance or code update. |

***

## IBC — De‑Facto Standard for Sovereign Interoperability

The **Inter‑Blockchain Communication (IBC)** protocol (originating in the Cosmos SDK) provides:

* **Client–Connection–Channel abstraction** – layered handshake that cleanly separates authentication (light clients) from application semantics.
* **Commit‑only light clients** – each chain stores the other chain’s header commitments and verifies Merkle proofs on‑chain.
* **Permissionless relayers** – off‑chain processes broadcast packets; any actor can relay without gaining trust power.
* **ORDERED / UNORDERED channels** – deterministic packet sequencing suited for both fungible tokens (ICS‑20) and arbitrary data (ICS‑27, ICS‑721, etc.).
* **Timeout & upgrade paths** – channels can close on misbehaviour; light clients autonomously upgrade using on‑chain proof of new client state.

Because sovereign rollups already own their state transition function, integrating IBC requires only:

1. Importing an IBC *core* module (client, connection, channel logic).
2. Supplying a light‑client implementation for each counterparty (e.g., Tendermint‑BFT, zk‑based header proof, Ethereum‑SSZ).
3. Defining application modules (token transfers, cross‑rollup DEX, etc.) that marshal packets.

***

## Comparison: Traditional vs. Sovereign Interoperability

| Feature              | Traditional Rollups         | Sovereign Rollups                        |
| -------------------- | --------------------------- | ---------------------------------------- |
| Bridge Authority     | L1 settlement layer         | Self‑sovereign verification              |
| Bridge Customisation | Limited or none             | Fully customizable                       |
| Protocol Support     | Proprietary, single bridge  | Multiple (IBC, ZK bridges, custom)       |
| Asset Types          | Often limited to tokens     | Tokens, NFTs, arbitrary data packets     |
| Security Model       | Inherits L1 bridge contract | Choice of light‑client or validity proof |
| Upgrade Path         | Dependent on L1 governance  | Independent—rollup‑level governance      |

***

## Sovereign Rollup Tooling & Ecosystem

| Framework / Component    | Interoperability Features                                                                                                                                                                  |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Rollkit**              | Plug‑and‑play modular rollup framework; native IBC wiring; supports Tendermint, Celestia, and Sunrise DA back‑ends.                                                                        |
| **Sovereign SDK**        | Rust toolkit for zero‑knowledge or fraud‑proof sovereign chains; ships generic IBC light‑client traits and relayer hooks.                                                                  |
| **Sunrise DA**           | Provides data availability with Proof of Liquidity (PoL); exposes an IBC interface so sovereign rollups built on Sunrise inherit connectivity to the broader IBC mesh.                     |
| **Application Patterns** | *Cross‑Chain DeFi* (omni‑liquidity pools), *Interoperable Gaming* (asset portability), *Multi‑Chain Identity* (DID packets), *Chain‑Agnostic DAOs* (governance spanning multiple rollups). |