What is Eclipse Blockchain? The First SVM Rollup on Ethereum Explained

Eclipse is arguably the most architecturally ambitious Layer 2 blockchain in existence today. It is the first network to combine the Solana Virtual Machine (SVM) for execution with Ethereum as its settlement layer — giving developers Solana-level throughput while inheriting Ethereum's battle-tested security. This guide explains exactly what Eclipse is, how it works, what makes it different from both Solana and EVM rollups, and what risks to watch out for in 2026. For educational purposes only.

What is Eclipse? Origin and Funding

Eclipse is a Layer 2 blockchain founded in 2022 by Neel Somani, headquartered in San Francisco. The company has raised over $65 million from leading investors including Placeholder, Hack VC, Polychain Capital, and Samsung Next.

Eclipse mainnet launched in late 2024, making it the first SVM rollup to go live on production for the general public. Eclipse's core thesis is "the best of both worlds" — Solana's performance characteristics on top of Ethereum's security foundation.

The name Eclipse alludes to overshadowing the limitations of legacy blockchains that forced a tradeoff between performance and security — a fundamental tension in the blockchain trilemma.

What is SVM and Why Did Eclipse Choose It?

SVM stands for Solana Virtual Machine — the execution environment of the Solana blockchain, analogous to how EVM is Ethereum's execution environment. The design philosophy differs significantly between the two.

Key advantages of SVM that motivated Eclipse's choice:

1. Native Parallel Processing: SVM was designed from day one for concurrent transaction execution via the Sealevel runtime. It analyzes which transactions access different state and executes them simultaneously, fully utilizing multi-core CPUs.

2. Accounts Model: SVM separates code (programs) from data (accounts), a design that naturally enables higher parallelism compared to EVM's interleaved state model.

3. High Throughput: Solana mainnet handles up to 65,000 TPS on SVM. Eclipse inherits this execution capacity.

4. Low Latency: SVM was engineered for sub-second finality — critical for trading and gaming applications where every millisecond matters.

Eclipse chose SVM over EVM because it wanted a higher performance ceiling than EVM rollups like Arbitrum or Optimism, which still inherit EVM's sequential execution constraints even with parallelization upgrades.

How Does Eclipse Work? Hybrid Architecture

Eclipse uses a modular architecture that separates responsibilities into four distinct layers:

1. Execution Layer — SVM: Every transaction is processed by the Solana Virtual Machine on Eclipse nodes. Transactions execute in parallel, enabling high throughput.

2. Settlement Layer — Ethereum: After execution, Eclipse posts a state root (a cryptographic hash summarizing the entire state) to Ethereum mainnet for verification and finalization. Ethereum serves as the ultimate source of truth.

3. Data Availability — Celestia: Instead of posting raw transaction data to expensive Ethereum calldata, Eclipse uses Celestia as a dedicated DA layer. This dramatically reduces costs while maintaining verifiability.

4. Proof System — RISC Zero: Eclipse is developing a ZK proof system using RISC Zero to efficiently verify SVM execution on Ethereum, which will make Eclipse a full zkVM rollup in the future.

Transaction flow on Eclipse:

User submits tx → Eclipse sequencer receives → SVM executes in parallel → State root posted to Ethereum → Data posted to Celestia → Ethereum verifies and finalizes

Eclipse vs EVM L2s: Arbitrum, Optimism, Base

To understand Eclipse's market position, here's a direct comparison with leading EVM rollups:

Execution VM:
• Eclipse: SVM — parallel by design
• Arbitrum / Optimism / Base: EVM — sequential by default

Theoretical Throughput:
• Eclipse: 50,000+ TPS (SVM ceiling)
• Arbitrum: ~4,500 TPS
• Base: ~2,000 TPS

Developer Language:
• Eclipse: Rust + Anchor (Solana SDK)
• Arbitrum / Optimism / Base: Solidity / Vyper — vastly larger developer base

Settlement:
All four settle on Ethereum mainnet, sharing its security.

Data Availability:
• Eclipse: Celestia (cheaper)
• Arbitrum / Optimism: Ethereum calldata (more expensive)
• Base: Ethereum Blobs (EIP-4844)

Bottom line: Eclipse trades developer accessibility (Rust requirement) for a significantly higher performance ceiling. Best suited for high-frequency, latency-sensitive applications.

Eclipse vs Solana: Key Differences

Despite sharing SVM, Eclipse and Solana differ in important ways:

Security Model:
Solana has its own validator set of ~2,000 validators secured by SOL staking.
Eclipse settles on Ethereum with 800,000+ validators and hundreds of billions in staked ETH — giving Eclipse stronger economic security than Solana in this regard.

Native Token:
Solana: SOL for gas and staking.
Eclipse: ETH as the gas token (no native token as of this writing). Users bridge ETH from Ethereum — no need to acquire a new asset.

Ecosystem Maturity:
Solana has a deep ecosystem: Jupiter, Raydium, Magic Eden, Tensor, and hundreds of dApps.
Eclipse ecosystem is growing rapidly but still early-stage.

Finality Speed:
Solana: ~400ms finality.
Eclipse: Slightly slower due to Ethereum settlement overhead, but still faster than most EVM L2s for user-facing interactions.

Gas Fees on Eclipse

Low transaction fees are a major draw of Eclipse, made possible by three factors:

1. ETH as Gas Token: Eclipse uses bridged ETH for gas, so users don't need to acquire a separate token. Just bridge ETH from Ethereum mainnet and you're ready to transact.

2. Celestia Reduces DA Costs: By using Celestia instead of Ethereum calldata for data availability, Eclipse significantly reduces per-transaction costs that would otherwise flow through to users.

3. SVM Efficiency: Parallel execution means each transaction uses fewer compute resources than sequential EVM processing, further lowering costs.

In practice, Eclipse fees are a fraction of Ethereum mainnet costs and competitive with or lower than leading EVM L2s, making microtransactions and gaming use cases economically viable.

To bridge ETH to Eclipse: use the official Eclipse bridge at useclipse.com, or cross-chain aggregators like Relay Finance and Jumper Exchange.

Eclipse Ecosystem: DApps and Protocols

Eclipse's ecosystem has been growing steadily since mainnet launch:

DeFi:
• Invariant Protocol — concentrated liquidity DEX (similar to Uniswap V3)
• Save Finance — lending and borrowing protocol
• Orca (partial) — Solana-native DEX with Eclipse integration
• Multiple perp DEXes leveraging SVM's low latency for on-chain order books

NFT & Gaming:
• On-chain games benefit greatly from sub-second latency
• NFT marketplaces integrating with Eclipse's high throughput

Infrastructure:
• Pyth Network — price oracle deployed on Eclipse
• Wormhole — cross-chain bridge for asset transfers
• QuickNode and Helius — RPC providers supporting Eclipse

Developer Tools:
• Standard Solana CLI and Anchor framework work with Eclipse
• Solana Playground supports Eclipse deployment
• Faucet and testnet available for developers

Celestia and Eclipse: The DA Layer

Choosing Celestia as a dedicated data availability layer is one of Eclipse's most important architectural decisions.

Why Celestia instead of Ethereum?

In traditional optimistic rollups (Arbitrum, Optimism), transaction data is posted directly to Ethereum. Even with EIP-4844 blobs, this remains more expensive than Celestia, which was purpose-built as a modular DA layer.

Celestia's key properties for Eclipse:
• Significantly cheaper storage than Ethereum calldata
• Data availability sampling (DAS) lets light nodes verify data without downloading everything
• Better scalability as transaction volume grows

That said, using Celestia instead of Ethereum for DA carries additional risk: Celestia is a newer blockchain with less battle-testing than Ethereum, which is worth factoring into your risk assessment.

Risks and Considerations

Eclipse is a compelling project, but several risks deserve attention before using it:

1. Smart Contract Risk: Eclipse is relatively new. Smart contracts and bridge contracts, even audited ones, may contain undiscovered vulnerabilities.

2. Sequencer Centralization: Like most L2s, Eclipse currently runs a centralized sequencer — a potential point of censorship and downtime. Decentralization plans are on the roadmap but not yet live.

3. Rust Barrier: Building on Eclipse requires Rust knowledge, which has a steeper learning curve than Solidity. This may slow developer adoption early on.

4. Nascent Ecosystem: Eclipse's ecosystem is much smaller than established EVM L2s. Lower liquidity means higher slippage in DeFi.

5. Celestia Risk: If Celestia experiences issues, Eclipse's data availability could be affected — even though settlement on Ethereum would still hold.

This article is for educational purposes only and does not constitute financial or investment advice.

Frequently Asked Questions

Conclusion

Eclipse represents one of the most architecturally innovative ideas in the Layer 2 landscape in 2026. By combining SVM's parallel execution with Ethereum's settlement security, it opens up a class of high-performance applications that weren't previously possible within the Ethereum ecosystem. For developers with Rust experience looking for high throughput and Ethereum security, Eclipse offers a genuinely compelling option. For end users, low fees and fast transactions are immediate benefits. That said, the ecosystem is still maturing, sequencer centralization remains a concern, and new risks come with being early. Do your own research and size your exposure accordingly.

This article is for educational purposes only and does not constitute financial or investment advice.