Security Architecture: From Assumptions to Guarantees

Stage 0: Current Security Assumptions

We are currently live with an architecture optimised for high performance and developer agility, but with some meaningful trade-offs in trust and verification. These trade-offs are common across early-stage rollups and include:

• Sequencer fallback: There is currently no fallback mechanism for the sequencer. If the sequencer is down or censoring, users have no recourse to submit transactions directly.

• Proposer availability: State root publication is permissioned. Only a whitelisted proposer can publish roots to Ethereum. If the proposer fails or acts maliciously, withdrawals are halted.

• Lack of fraud or validity proofs: At present, the system allows invalid state roots to be submitted without on-chain challenge. Execution correctness is not verifiable on L1.

• No user-exitable window: Protocol contracts are upgradeable without enforced delay. This means users don't have a guaranteed exit window in case of controversial changes.

• Custom permissioned bridge: Our Canonical Bridge is governed by a 3-of-5 multisig. It does not support arbitrary message passing, and withdrawals are explicitly approved by the committee. There is a 7-day withdrawal delay.

• Full contract upgradeability: The bridge, sequencer registry, and treasury contracts are all upgradeable by the multisig, with no mandatory timelocks.

These assumptions place trust in Eclipse Labs and the multisig operators to behave correctly and act in the users' best interest.

Stage 1: Shifting Toward Verification and Permissionless Control

The system is undergoing a phased transition to a more verifiable and decentralized trust model. The following improvements are underway:

• Fraud proof integration via Kailua (RISC Zero): zkVM-based fraud proof system is being implemented for the GSVM. Using Kailua, state transition proofs will be generated and submitted in response to invalid state roots. These proofs will enable Ethereum to reject fraudulent state commitments.

• Staged security adoption in the Canonical Bridge: The Syzygy Canonical Bridge introduces a modular security framework. Applications can opt into specific levels of security, including mandatory fraud proof validation or enforced timelocks, depending on their needs.

• Introduction of timelocks: Key administrative actions, such as contract upgrades and pausing mechanisms, will be governed by timelocks. This gives users visibility and time to react to protocol changes.

• Granular access control: The bridge and associated contracts already support role-based access controls and emergency pause logic. These mechanisms limit sensitive permissions and enable selective response during incidents.

This stage introduces the foundation for fault-proof-based correctness, better upgrade hygiene, and composable security guarantees tailored per app.

Summary

Eclipse is evolving from a coordinated, governance-dependent system into a modular rollup with verifiable security. Each app will be able to choose its own security envelope, ranging from low-latency experimentation to strong correctness guarantees enforced by fraud proofs. The rollout of Kailua-backed verification, application-specific staging, and infrastructure-level hardening marks a critical step toward a permissionless and resilient L2.