Eclipse: SVM execution on an Ethereum L2

Eclipse is a layer-2 that settles to Ethereum but executes with the Solana Virtual Machine. It uses Celestia for data availability, posts state roots to Ethereum, and accepts ETH as the native gas token. If you already write Anchor programs, almost nothing changes in your development workflow — you target a different RPC endpoint and bridge ETH instead of SOL for fees.

The stack at a glance

Eclipse stacks four layers:

• Execution — SVM (Solana runtime, RBPF bytecode, same compute model, same account model)
• Settlement — Ethereum mainnet (fraud proofs / ZK proofs anchored to L1)
• Data availability — Celestia (blobs, not calldata, so DA costs stay low)
• Gas token — ETH (bridged via the canonical Eclipse bridge; SOL is not used)

The result: Solana throughput + Ethereum security + cheap DA. Programs that run on Solana mainnet compile and deploy unchanged — what differs is the RPC URL, the bridging step, and the fact that your users hold ETH, not SOL.

Environment setup

# Same Solana CLI you already use
sh -c "$(curl -sSfL https://release.anza.xyz/stable/install)"

# Point the CLI at Eclipse mainnet
solana config set --url https://mainnetbeta-rpc.eclipse.xyz

# Or testnet
solana config set --url https://testnet.dev2.eclipsenetwork.xyz

Your keypair works as-is. Fund it by bridging ETH through the Eclipse bridge, or use the testnet faucet at faucet.eclipse.xyz.

Writing an Anchor program for Eclipse

The program is identical to Solana mainnet. Here's a minimal counter to prove the point:

use anchor_lang::prelude::*;

declare_id!("YourProgramIdHere11111111111111111111111111111");

#[program]
pub mod counter {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        ctx.accounts.counter.count = 0;
        Ok(())
    }

    pub fn increment(ctx: Context<Increment>) -> Result<()> {
        ctx.accounts.counter.count += 1;
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(init, payer = user, space = 8 + 8)]
    pub counter: Account<'info, Counter>,
    #[account(mut)]
    pub user: Signer<'info>,
    pub system_program: Program<'info, System>,
}

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(mut)]
    pub counter: Account<'info, Counter>,
}

#[account]
pub struct Counter {
    pub count: u64,
}

Zero changes. Build and deploy the same way you would on Solana mainnet:

anchor build

# Deploy to Eclipse mainnet
anchor deploy --provider.cluster https://mainnetbeta-rpc.eclipse.xyz

# Or pass the keypair explicitly
solana program deploy   target/deploy/counter.so   --url https://mainnetbeta-rpc.eclipse.xyz   --keypair ~/.config/solana/id.json

What actually breaks

The account model, BPF bytecode, and instruction layout are identical. What isn't:

• Native token is ETH. Any program that hard-codes SOL mint addresses or assumes the native mint is SOL will be wrong. Wrap ETH for SPL-compatible flows.
• Solana-specific programs may not be deployed. Token program, System program, Compute Budget — all present. But some SPL helpers or third-party programs that exist on Solana mainnet may not exist at the same address on Eclipse. Check before assuming.
• Wallets need Eclipse awareness. Phantom and Backpack support Eclipse mainnet; MetaMask does not (it's not EVM). Users need to switch their wallet to the Eclipse network.
• Bridges take time. Bridging ETH in from Ethereum L1 has standard optimistic/ZK withdrawal windows. Fast bridges exist but add a trust assumption.
• Block explorers differ. explorer.eclipse.xyz for transactions; Etherscan for settlement proofs.

Client-side: calling your program

The TypeScript client is the same @solana/web3.js you already use — just point the connection at Eclipse:

import { Connection, PublicKey, Transaction } from "@solana/web3.js";
import { AnchorProvider, Program, web3 } from "@coral-xyz/anchor";

const connection = new Connection(
  "https://mainnetbeta-rpc.eclipse.xyz",
  "confirmed"
);

// Everything else is unchanged: IDL, accounts, instructions
const provider = new AnchorProvider(connection, wallet, {});
const program = new Program(idl, provider);

const tx = await program.methods
  .increment()
  .accounts({ counter: counterPda })
  .rpc();

console.log("tx:", tx);

Why choose Eclipse over Solana mainnet?

The honest answer is: your users hold ETH. If you're building for an Ethereum-native audience and don't want to ask them to buy SOL, Eclipse lets you keep the SVM's throughput and fee predictability while meeting users where their assets already are. The tradeoff is a smaller ecosystem — fewer composable protocols, fewer wallet integrations, and a bridging UX that adds friction for new users.

For Solana-native teams, mainnet is still the right default. For teams targeting DeFi users who are already on Ethereum, Eclipse is worth evaluating seriously.

Resources

• Eclipse docs
• Eclipse bridge
• Eclipse explorer
• Testnet faucet