Updated architecture docs are now live!

System Composition

How These Three Components Work Together

Eclipse’s system flows from execution to data availability, and from settlement to exit verification:

spinner

We can break this down further:

  1. User Transaction: Begins on Eclipse and is picked up by the sequencer.

  2. Data Availability: The Celestia publisher compresses and posts the block data to Celestia, receiving span_sequence commitments.

  3. DA Commitment Anchoring: The Gateway takes the Celestia span_sequence data and submits BatchHeaders to Ethereum.

  4. Withdrawals:

    • Initiation: Users request withdrawals through a trusted withdrawal relayer

    • Authorization: The withdrawal relayer calls authorizeWithdraw on the Canonical Bridge

    • Claim Period: Users call claimWithdraw 7 days later to complete the withdrawal

  5. Data Availability Challenges (Separate Optimistic Process):

    • Anyone can submit DA proofs to challenge unavailable data

    • Not required for normal operation (optimistic system)

    • Only needed if there's a dispute about data availability

  6. Finality: The Bridge processes authorized withdrawals after the delay period.

Each module is independently upgradable and maintains strict boundaries, but their collaboration underpins Eclipse’s modular rollup design.

The Publisher handles DA at scale using Celestia. The Gateway anchors DA commitments and facilitates messages. The Canonical Bridge finalizes user exits by validating Merkle proofs before authorizing Treasury transfers.

Each module is decoupled, yet interdependent, and the entire system is designed to evolve, enabling upgrades like fraud proofs, decentralized sequencing, and dynamic withdrawal verification.

Visualizing Deposit vs Withdraw Flow

To better illustrate how deposits and withdraws flow:

spinner

This visual helps delineate between forward-facing execution logic (e.g. messages coming in) and backward-facing verification logic (e.g. data leaving Eclipse).

Last updated

Was this helpful?