Multi-Chain Support

AstralBeam connects Casper Network to multiple EVM chains simultaneously. This page explains how the multi-chain architecture works and how chains are isolated from each other.

Overview

flowchart TB
    subgraph EVMChains[EVM Chains]
        Sepolia[Ethereum Sepolia]
        Base[Base Sepolia]
        Polygon[Polygon Amoy]
        Robinhood[Robinhood Chain Testnet]
    end

    subgraph Casper[Casper Network]
        TokenFactory[TokenFactory - Single Instance]
        EthClient[EthClient - Multi-Chain Storage]
    end

    Sepolia <--> TokenFactory
    Base <--> TokenFactory
    Polygon <--> TokenFactory
    Robinhood <--> TokenFactory
    TokenFactory <--> EthClient

Each EVM chain is uniquely identified by its chain ID (e.g. Ethereum Sepolia is 11155111). The chain ID is woven through every layer of the bridge - contracts, approvals, and storage - so that activity on one chain can never affect another. See Supported Networks for the current chain list.

Finality Per Chain

Different chains finalize transactions at different speeds. The bridge reads each chain's protocol-level finalized marker and additionally enforces a per-chain minimum confirmation depth. Transfers are only processed once both conditions are met; if finality information is unavailable, the bridge waits rather than guessing.

Per-Chain Contracts

EVM Side: Separate Lockers

Each EVM chain has its own locker contract deployment. This means:

• Tokens on different chains are never co-mingled
• Liquidity is isolated per chain
• A problem on one chain cannot affect another
• Chains can be upgraded and maintained independently

Casper Side: Unified Entry Point

A single TokenFactory on Casper serves all EVM chains. Token mappings always include the source chain ID, so the same token symbol arriving from two different chains is tracked separately.

Block Header Storage

The EthClient contract on Casper stores EVM block information keyed by chain ID and block number, so headers from different chains can never be confused - block 1,000,000 on Sepolia and block 1,000,000 on Base are entirely separate records.

Cross-Chain Replay Protection

Without chain isolation, an attacker could take a valid approval for a deposit on one chain and replay it against another - receiving tokens twice. AstralBeam prevents this by including the chain ID in every approval:

• An approval generated for one chain is cryptographically invalid on every other chain
• Contracts validate the chain ID before accepting anything
• Each chain requires its own independent set of relayer approvals

Token Return Rules

Bridged tokens remember where they came from. A token bridged from Ethereum Sepolia can only be bridged back to Ethereum Sepolia - never to a different chain. This keeps each chain's locked liquidity exactly matched to the bridged supply that came from it.

Adding New Chains

AstralBeam can be extended to any EVM-compatible chain. At a high level, onboarding a new chain involves:

1. Deploying the locker contract on the new chain
2. Registering the authorized relayer set on that locker
3. Registering the chain and its token mappings on Casper
4. Enabling the chain in the relayer network

New chains go through testnet certification - including complete round-trip transfer verification - before they are activated.

Security Considerations

Related Pages

• Architecture Overview
• Bridge Flows
• Supported Networks