# 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). |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sunriselayer.io/learn/thesis/interoperability.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.