
Eclipse: The first SVM Layer2 combining Ethereum's security, Solana's high performance, and Celestia's DA narrative
TechFlow Selected TechFlow Selected

Eclipse: The first SVM Layer2 combining Ethereum's security, Solana's high performance, and Celestia's DA narrative
Eclipse paves the way for Solana to communicate with Cosmos via Inter-Blockchain Communication (IBC).
Author: YBB Capital Researcher Ac-Core

Eclipse Background

Image source: Eclipse official website
Eclipse founder Neel Somani previously worked as a software engineer at Airbnb and a quantitative researcher at Citadel. He founded Eclipse, a Solana-based startup, in 2022, receiving support from Solana co-founder Anatoly Yakovenko and Polygon, among others, aiming to build compatible rollup blockchains for Solana and Polygon. According to a CoinDesk report on September 28, 2022, Eclipse successfully raised $6 million in a pre-seed round led by Polychain and $9 million in a seed round co-led by Tribe Capital and Tabiya, totaling $15 million in funding. Additionally, Eclipse received a development grant from the Solana Foundation to support SVM-powered rollups.
Leveraging his network and proximity to Solana's Chicago headquarters, Eclipse founder Somani utilized the Solana Virtual Machine (SVM) to create a unique blockchain. The vision is to enable developers to deploy SVM-powered rollups, with plans to launch a public testnet on the Cosmos ecosystem in early 2023 and future support for Aptos' Move language.
Solana co-founder and Eclipse angel investor Anatoly Yakovenko commented: "Eclipse paves the way for Solana to communicate with Cosmos via Inter-Blockchain Communication (IBC)."
Polychain Capital partner Niraj Pant stated: "As large enterprises and governments begin entering the blockchain space, Eclipse serves as critical infrastructure enabling their use cases—such as Web2-scale consumer and financial applications."
Eclipse Architecture
According to official documentation, Eclipse Mainnet is Ethereum’s first general-purpose L2 built around SVM, combining key components of modular stack architecture to become the fastest and most general-purpose Layer2 powered by SVM. The project uses Ethereum as its settlement layer with an embedded verification bridge; Celestia as the data availability (DA) layer; RISC Zero for generating zero-knowledge fraud proofs; and ultimately leverages Solana’s SVM as the execution module in this modular Layer2 design. Below is a detailed breakdown based on official explanations.
Settlement Layer — Ethereum: Eclipse settles transactions on Ethereum (via an embedded verification bridge on Ethereum), uses ETH for gas consumption, and submits fraud proofs on Ethereum;
Execution Layer — Solana Virtual Machine (SVM): Eclipse runs the high-performance SVM as its execution environment—a fork of the Solana Labs client (v1.17);
Data Availability Layer — Celestia: Eclipse publishes data to Celestia for scalable data availability (DA);
Proof Mechanism — RISC Zero: Eclipse uses RISC Zero for ZK fraud proofs (without intermediate state serialization);
Communication Protocol — IBC: Bridges connections with non-Eclipse chains using Cosmos’ Inter-Blockchain Communication standard (IBC);
Cross-chain Protocol — Hyperlane: Eclipse collaborates with Hyperlane to bring Hyperlane’s permissionless interoperability solution to SVM-based blockchains.

Image source: Eclipse official
Settlement Layer: Leveraging Ethereum’s Security and Liquidity
Like other Ethereum rollups, Eclipse uses Ethereum as its settlement layer. This involves directly integrating Eclipse’s verification bridge into Ethereum. Nodes must verify the correctness of the bridge and proper transaction ordering, ensuring users benefit from Ethereum-level security.
L2BEAT defines Layer2 as “a chain that fully or partially derives its security from Ethereum Layer1, so users don’t have to rely solely on Layer2 validators’ honesty to secure their funds.” The Eclipse verification bridge enables final validity and censorship resistance under certain failure conditions—even if the sequencer goes down or censorship begins on L2, users can force their transactions through the bridge while burning ETH as gas on Ethereum.
Execution Layer: Harnessing Solana’s Transaction Speed and Scalability
To improve efficiency, Eclipse Mainnet adopts Solana’s execution environment, leveraging SVM and Sealevel (Solana’s horizontal scaling technology—its ultra-parallelized transaction processing engine designed to scale across GPUs and SSDs). Unlike EVM’s single-threaded execution model, this approach allows parallel execution without overlapping state transactions, avoiding sequential processing.
Regarding EVM compatibility, Eclipse Mainnet partners with Neon EVM to allow developers to utilize Ethereum tools and build Web3 applications on Solana. Official data indicates throughput can reach up to 140 TPS—significantly higher than single-threaded EVM. EVM users interact natively with applications on Eclipse Mainnet via MetaMask wallet’s “Snaps” plugin.
Data Availability: Utilizing Celestia’s Bandwidth and Verifiability
Eclipse Mainnet leverages Celestia for data availability and has established a long-term partnership, primarily because Ethereum cannot currently meet Eclipse’s target throughput and fee requirements—even after the EIP-4844 upgrade, which provides approximately 0.375 MB of blob space per block (with a maximum limit of about 0.75 MB per block).
Official figures suggest that ERC-20 transactions on rollups, assuming 154 bytes per transaction, equate to a combined total of roughly 213 TPS across all rollups. For compression swaps (~400 bytes per transaction), aggregate TPS drops to around 82. In contrast, Celestia offers 2MB blocks, with Blobstream expected to increase to 8MB once network proofs stabilize and more DAS (Data Availability Sampling) light nodes come online.
Eclipse believes that, given the trade-off between cryptoeconomic security and highly scalable DA throughput, Celestia represents the optimal choice today. While some argue that only Ethereum-based DA qualifies a true Layer2, the team continues monitoring Ethereum’s DA scalability post-EIP-4844. If Ethereum can offer larger-scale, high-throughput DA, Eclipse will reassess the possibility of migrating.
Proof Mechanism: RISC Zero Fraud Proofs (No Intermediate State Serialization)
Eclipse’s proof method resembles Anatoly’s SVM fraud proof SIMD (see GitHub extension link 2), aligning with John Adler’s insight to avoid the high cost of state serialization. To prevent reintroducing Merkle trees (hash trees) into SVM, early attempts involved inserting Sparse Merkle Trees into SVM—but updating the Merkle tree with every transaction significantly impacted performance. Without Merkle trees for proofs, existing general-purpose rollup frameworks (like OP Stack) cannot serve as a foundation for SVM rollups, necessitating a more creative fault-proof architecture.
Fraud proof requirements: input commitments for transactions, the transaction itself, and proof that re-executing the transaction results in output differing from the on-chain specified result.
Input commitments are typically achieved by providing the Merkle root of the rollup state tree. Eclipse’s executor publishes a list of each transaction’s inputs and outputs—including account hashes and relevant global states—as well as the transaction index producing each input, then posts the transaction to Celestia. Any full node can follow along, extract input accounts from their own state, compute output accounts, and confirm the commitment on Ethereum is correct.
Two major types of errors may occur:
Incorrect Output: A verifier provides a ZK proof on-chain showing the output is invalid. Eclipse uses RISC Zero to generate ZK proofs for SVM execution—extending prior work proving BPF bytecode execution (see GitHub extension link 3). This allows the settlement contract to ensure correctness without re-executing the transaction on-chain.
Incorrect Input: A verifier publishes historical data on-chain showing the input state does not match the claimed state. Eclipse’s settlement contract then uses Celestia’s Quantum Gravity Bridge to verify fraudulent data withholding.
Eclipse’s Connection with Ethereum and Celestia

Image source: @jon_charb
Data availability (DA) is one of the main cost drivers for rollups. Currently, Ethereum L2s mainly use two DA methods: Calldata and DAC (Data Availability Committees).
● Calldata: Layer2 solutions like Arbitrum or Optimism publish transaction data directly on-chain as calldata within Ethereum’s highly censorship-resistant blocks. Ethereum prices calldata alongside computation and storage under one unit: Gas—this is one of the primary costs Rollups incur when posting to Ethereum. To improve efficiency, the EIP-4844 upgrade introduced Blobspace to replace calldata, offering all Rollups a target of 375 KB per block;
● DAC: Compared to publishing calldata directly on-chain, DACs offer much higher throughput, but require users to trust a small committee or group of validators to avoid malicious data withholding. DACs—including restaking-based solutions—introduce significant trust assumptions for L2s, forcing reliance on reputation, governance mechanisms, or token voting to deter or punish data concealment. Thus, external DA often requires DAC usage.
It should be noted that Eclipse uses Celestia’s Blobstream proof-of-stake consensus network, allowing Layer2 access to Celestia’s Blobspace—supporting up to 8 MB blobs, equivalent to roughly 9,000–30,000 ERC-20 transfers per second depending on compression. However, Layer2s using Blobstream depend on Celestia validator proofs. Light clients can detect malicious behavior if 2/3 of Celestia validators withhold data and initiate slashing. Objectively, DACs still fall short of native chain DA in terms of trustworthiness—but from an innovation and market narrative perspective, such shortcomings are unavoidable.

Image source: Eclipse official - Eclipse Modular Interaction Logic
As explained in official documentation and illustrated above, Eclipse has tested running data provenance via Celestia’s Blobstream (an Ethereum modular DA solution based on DAS expansion), allowing the bridge to verify data security for fraud proofs using signed data roots from Celestia. Users deposit funds into Eclipse via the native Ethereum bridge, following this process:
1. User calls the Eclipse deposit bridge contract on Ethereum (contract address in extension link 1);
2. Eclipse executes within the SVM executor (computes SVM results and outputs to new Eclipse state nodes); the relay (ETH-Eclipse channel) handles cross-chain data exchange between sender and recipient addresses;
3. The relay invokes the SVM bridging program to send the user’s deposit to the target address;
4. The relay verifies the deposit transaction via zk-light client (pending implementation);
5. Finally, the block containing the subsequent deposit transaction is finalized and published via Solana’s Geyser plugin.
During this process, the SVM executor uses Geyser to publish each Eclipse slot to a message queue. Slots are published to Celestia as data blocks, where Celestia validators commit to the submitted blocks to prove transaction inclusion in the Eclipse chain and correspondence with the data root. Each Celestia data block is then relayed via Blobstream to the Eclipse bridging contract on Ethereum.

Image source: Eclipse official: Interaction between Celestia and SVM Executor
Similarly to other fraud-proof-based Layer2s on Ethereum, withdrawals from Eclipse to Ethereum require a challenge window, allowing verifiers to submit fraud proofs if a state transition is invalid.
● The SVM executor periodically posts a commitment for an epoch of Eclipse slots (processed in predetermined batch sizes) to Ethereum along with a bond;
● Eclipse’s bridge contract performs basic checks to ensure the posted data format is valid (see reference article [2] fraud proof design section);
● If the batch passes basic checks, a predefined window opens during which, if the batch commitment implies an invalid state transition, verifiers may submit a fraud proof;
● If a verifier successfully submits a fraud proof, they win the executor’s stake, the batch is rejected, and Eclipse L2’s canonical state rolls back to the last valid batch commitment. Eclipse administrators then have the authority to select a new executor;
● If the challenge period expires without any fraud proof, the executor retrieves their stake and receives rewards;
● Finally, the Eclipse bridge contract finalizes all withdrawal transactions included in the batch.
Summary
Eclipse remains in the early testnet development phase and is Ethereum’s first SVM-powered Layer2. Its testnet is already live, with the mainnet scheduled for release in Q1 2024. Ethereum continues to view rollups as its core development path. Setting aside debates over legitimacy, this effectively delegates the broader definition of Layer2 to the market—meaning overt empowerment also conceals intense competition among various forms. Eclipse capitalizes on this opportunity by combining modularity to weave together Ethereum’s security, Solana’s high performance, and Celestia’s DA into a compelling market narrative.
Looking back at Ethereum’s evolution, an interesting observation is that the previous bull market was fueled by DeFi Summer hype, leading to an explosion of “DeFi matryoshka” and “DeFi Lego” innovations and composability, driving exponential ecosystem growth. This cycle, driven by LSD and restaking combinations, has seen a surge in “staking matryoshka” and “staking Lego” constructs, pushing EigenLayer, Blast, and Merlin in the BTC ecosystem to repeatedly achieve record-high TVLs in short periods. If matryoshka and Lego represent the dominant themes of market sentiment, then modularity may soon compose its own unique melody of stacking and nesting.
The appeal of modularity lies in the decoupling benefits of components, enabling innovation at every layer of the stack. Optimization in any single module can amplify improvements across others. Perhaps, in the future, both developers and users will face a wide array of competitive choices shaped by modular progress.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News














