A user who holds assets across multiple Ethereum Virtual Machine networks faces a practical question: which chains can Rabby actually manage, and how much manual configuration is required? The wallet’s marketing emphasizes EVM compatibility broadly, but that claim needs specifics. Between major Layer 2 solutions like Arbitrum and Optimism, sidechain networks like Polygon, and dozens of smaller or regional blockchain systems, the distinction between “supported” and “theoretically compatible but rarely tested” matters significantly. Understanding exactly which networks have been integrated, which require custom RPC endpoints, and which present unusual security considerations becomes essential for reliable asset management.

Rabby’s approach to network support differs from wallets that explicitly list every chain they have validated. Instead, the wallet provides automatic network selection for widely recognized EVM chains and allows manual addition of custom networks through RPC endpoints. That flexibility is powerful but requires the user to make informed choices about which networks to enable, which endpoints to trust, and how to verify that a network is genuinely what it claims to be. The security implications run deeper than simple convenience: using an incorrect RPC endpoint, adding a spoofed network, or misreading a chain identifier can result in signing transactions on an unintended blockchain or interacting with an incorrect smart contract. A detailed examination of Rabby’s supported chains, how they are configured, and which ones warrant special caution provides the foundation for safe multi-chain usage.

The foundation: What EVM compatibility actually means

The Ethereum Virtual Machine is a standardized runtime environment that executes smart contracts. An “EVM-compatible” blockchain accepts the same bytecode, implements the same instruction set, and can run contracts written in Solidity or other EVM languages without modification. That compatibility is powerful: a contract deployed on Ethereum will function identically on Polygon, Arbitrum, Optimism, or Avalanche, assuming the necessary liquidity and asset bridges exist. However, EVM compatibility does not mean the networks are interchangeable for wallet purposes. Each chain has its own consensus mechanism, block time, finality model, transaction cost structure, and RPC infrastructure. A wallet that supports EVM-compatible chains must handle those differences explicitly through network selection, fee estimation, and confirmation monitoring.

Rabby’s approach to EVM support is fundamentally different from Bitcoin or Solana wallets, which are chain-specific. Rabby is an EVM wallet that maintains a default list of widely recognized networks and allows the user to add custom chains by specifying an RPC endpoint, chain ID, and network name. This design scales efficiently: rather than the developers needing to maintain separate code for each new EVM chain, users can integrate new networks as they emerge. The trade-off is that users must either rely on Rabby’s default list or take responsibility for verifying custom endpoints.

The distinction between “pre-configured” and “manually added” networks is not merely organizational. Pre-configured networks have been tested by Rabby’s developers, appear in the network switcher prominently, and are backed by known RPC providers. A manually added network depends entirely on the RPC endpoint the user provides. If that endpoint is wrong, unresponsive, or intentionally deceptive, the wallet will display incorrect balances, fail to send transactions, or in extreme cases broadcast transactions to the wrong chain entirely. Understanding which networks fall into which category is the foundation for safe multi-chain usage.

The primary Layer 1 and Layer 2 networks

Ethereum mainnet itself is the base layer for Rabby and the most widely used network in the wallet. All EVM-compatible chains derive their compatibility from Ethereum’s specification, making mainnet the reference point for development and security assumptions. Beyond Ethereum, several Layer 2 solutions have achieved sufficient adoption and maturity to warrant inclusion in Rabby’s default network list.

Arbitrum is a Layer 2 scaling solution using optimistic rollups, with the Arbitrum One chain handling most transaction volume. It has lower fees than Ethereum mainnet, faster confirmation times, and similar security guarantees because transactions are eventually settled on Ethereum. Arbitrum Nova is a separate chain designed for social and gaming applications with even lower fees but weaker security assumptions. Both operate as EVM-compatible networks and are pre-configured in Rabby.

Optimism is another Layer 2 using optimistic rollups, positioned as a direct competitor to Arbitrum. Its transaction fees are comparable, its security model is similar, and its ecosystem has developed significant liquidity. Optimism’s network identification and RPC infrastructure are well-established in Rabby’s defaults. The OP Stack, Optimism’s modular framework, has also enabled several other chains to launch using compatible infrastructure, though each operates as a separate network.

Polygon is a sidechain rather than a Layer 2, meaning it is not secured directly by Ethereum but instead maintains its own validator set. Polygon achieves lower costs and faster transactions at the trade-off of weaker direct security guarantees. From a wallet perspective, Polygon functions as a fully EVM-compatible network with its own native token, established bridges, and substantial DeFi liquidity. It is among the most widely used networks in Rabby and appears prominently in network selection. Users who have not yet configured Rabby should verify that the wallet is downloaded directly from get Rabby on Android mobile or the official rabby.io domain to ensure they are working with the authentic application.

Expanding EVM support: 50+ compatible networks

Beyond Ethereum, Arbitrum, Optimism, and Polygon, Rabby supports a substantial roster of EVM-compatible chains. Avalanche is a consensus-independent platform with its own C-Chain (Ethereum-compatible) that has gained significant adoption in the DeFi ecosystem. Base, built on Optimism’s OP Stack, has emerged as a major Layer 2 and is pre-configured in current versions of Rabby. Linea is a Layer 2 developed by ConsenSys using zkEVM technology, offering different security and fee characteristics compared to optimistic rollup solutions.

The list of supported networks extends considerably further. Fantom provides high-speed transactions at low cost with a different consensus mechanism but full EVM compatibility. Gnosis Chain, formerly xDAI, focuses on stable-coin transactions and has lower overall activity but remains fully functional. Moonbeam and Moonriver bring EVM compatibility to the Polkadot ecosystem. Celo is designed for mobile wallets and lower-income users. zkSync is a Layer 2 using zero-knowledge rollups with different security and performance characteristics than optimistic rollups. Blast, a Layer 2 designed for DeFi, supports native ETH on the rollup. Manta is a privacy-focused EVM chain using zero-knowledge technology. Scroll is another zkEVM Layer 2 aiming for high compatibility with Ethereum tools.

Additionally, Rabby integrates support for Sepolia, Holesky, and other Ethereum testnets for development purposes. Aurora is an EVM on the NEAR protocol. Mantle is a Layer 2 combining optimistic rollups with data availability layers. Zora is a Layer 2 built on Optimism’s OP Stack. Fraxtal is designed for stablecoin applications. Mode is another OP Stack-based Layer 2. The complete list of pre-configured networks available in Rabby exceeds 50 distinct EVM-compatible blockchains, though activity, liquidity, and security characteristics vary dramatically across them. A user should not assume that the mere presence of a network in the wallet’s configuration means it has equivalent security or utility to Ethereum or Arbitrum.

How network configuration actually works in Rabby

Rabby presents pre-configured networks in a dropdown menu, with Ethereum mainnet as the default. Selecting a different network automatically updates the wallet’s display to show balances, token holdings, and transaction history on that chain. The network switcher is the primary interface for multi-chain management, and it is typically accessed through a small indicator showing the current network and chain ID. When a user initiates a transaction, Rabby automatically detects the selected network and uses the appropriate RPC endpoint, gas price oracle, and block explorer to provide transaction interpretation and risk warnings.

For networks not appearing in the pre-configured list, Rabby allows manual addition through a “custom network” function. To add a custom network, the user must specify: the network name, chain ID (a unique numerical identifier), RPC endpoint URL, and optionally a block explorer URL and native currency symbol. These details must be accurate. Using an incorrect chain ID can result in transaction signing that appears valid locally but fails or hits the wrong network when broadcast. An RPC endpoint that is not actually connected to the intended network can cause balance inconsistencies or transaction failures. Rabby provides transaction simulation before signing, which catches some errors, but simulation depends on the RPC endpoint providing accurate state information.

Adding custom networks is intended for users who understand their implications. If a network has relatively low adoption or lacks well-known public RPC endpoints, the user may need to source an endpoint from the network’s official documentation or a community resource. This introduces a verification burden: is the endpoint operated by a trustworthy provider, or could it be a point of interception or misdirection? For most users, relying on Rabby’s pre-configured networks is the simpler and safer approach. For those managing assets on newer or niche EVM chains, custom network addition becomes necessary but requires careful verification of network parameters.

Layer 2 solutions and their distinct characteristics within Rabby

While Arbitrum, Optimism, and their derivatives are all EVM-compatible, they are not identical from a user perspective. Optimistic rollups, used by Arbitrum and Optimism, assume transactions are valid by default and require a challenge period before finality is assured. This design keeps costs low but means that withdrawals back to Ethereum require a 7-day waiting period on Optimism (and varying periods on other chains). Arbitrum’s Nitro upgrade improved withdrawal speed, but users should verify the current withdrawal timeline in the relevant network’s documentation rather than assuming instant movement between layers.

Zero-knowledge rollups, such as zkSync, Linea, and Scroll, use cryptographic proofs to validate transactions on-chain immediately. This eliminates the challenge period and enables faster withdrawals but comes with different gas cost structures and occasionally different EVM compatibility details. Some advanced features or low-level operations that work identically on Ethereum and optimistic rollups may not function the same way on zkEVM chains. Rabby’s transaction simulation helps catch obvious incompatibilities, but users deploying custom contracts should verify them on the specific Layer 2 before production use.

From Rabby’s wallet perspective, the most important practical difference is the bridge mechanism and withdrawal timeline. Moving funds from Ethereum to Arbitrum, Optimism, or another Layer 2 requires using an official bridge or a cross-chain service like Across or Li.Fi. Rabby does not provide integrated bridge functionality, so users must complete the bridging step in a separate application or through a DEX aggregator. The wallet simply displays the resulting balances once funds arrive. Similarly, withdrawing to Ethereum requires understanding the specific Layer 2’s withdrawal process, which differs between Arbitrum, Optimism, and others. A user who deposits to the wrong Layer 2 or attempts to withdraw using an incompatible method may find their funds temporarily or permanently inaccessible.

Sidechain networks and their role in Rabby’s ecosystem

Polygon remains the most widely used sidechain in the Rabby ecosystem, with substantial liquidity in DeFi, NFT marketplaces, and staking protocols. Unlike Layer 2 solutions, Polygon is not directly secured by Ethereum’s validators. Instead, it maintains its own Proof-of-Stake validator set, with Ethereum serving as an exit mechanism rather than a security guarantee. This trade-off makes Polygon faster and cheaper, but a user withdrawing from Polygon to Ethereum still incurs a withdrawal delay and must wait for the Polygon validator set to confirm the transaction on Ethereum. From Rabby’s perspective, Polygon functions like any other EVM network: the wallet manages keys, displays balances, and interprets transactions identically to Ethereum or Arbitrum.

Gnosis Chain operates with a similar sidechain architecture but with particular focus on stablecoin transactions and lower overall volatility. Its validator set, native token, and economics differ from Polygon, but EVM compatibility is complete. For a user primarily holding stablecoins or conducting payments rather than speculative trading, Gnosis Chain offers low fees and straightforward functionality within Rabby.

Moonbeam and Moonriver bring EVM capabilities to the Polkadot ecosystem but are not directly connected to Ethereum. A user moving funds to Moonbeam must use a bridge from Ethereum, Polygon, or another EVM chain. Once on Moonbeam, the funds operate on a separate network with its own validator set and security assumptions. Rabby treats Moonbeam as a standard EVM network, but the bridge mechanics and withdrawal process differ from Arbitrum or Polygon. Users who are not familiar with Moonbeam’s bridge infrastructure should confirm the bridging process before moving substantial amounts.

Emerging and niche EVM chains: When to use custom network configuration

As new EVM-compatible blockchains launch, they often begin outside Rabby’s pre-configured list. Newer OP Stack-based chains like Zora, Mode, and Fraxtal are examples of networks that have been added to Rabby’s defaults as they gained adoption, but when they first launched, users had to add them manually. The decision to add a niche or emerging chain should be based on genuine need and careful verification of network parameters.

For a user who receives funds on a new EVM chain or wants to interact with a specific application, manually adding the network is straightforward if the chain’s documentation provides accurate RPC endpoints and chain ID. However, the verification step is critical. A malicious or incorrectly configured RPC endpoint can display false balances or fail to broadcast transactions correctly. Users should prefer RPC endpoints operated by reputable providers or the network’s official infrastructure. Some chains provide multiple public endpoints specifically to reduce dependence on any single provider.

Privacy-focused and specialized EVM chains present additional considerations. Manta, for instance, integrates zero-knowledge proofs for privacy; using it through a standard RPC endpoint may reduce privacy benefits if the endpoint operator can observe transaction patterns. Similarly, chains designed for specific use cases such as gaming or NFT transactions may have different security assumptions or user bases compared to general-purpose networks. Rabby’s transaction interpretation and risk alerts are calibrated primarily for general-purpose chains and major Layer 2s; unusual smart contract patterns or application-specific risks may not be flagged on niche chains.

Critical setup considerations for multi-chain security

Using Rabby across multiple EVM networks requires consistent attention to network selection and transaction verification. The most frequent user error is selecting the wrong network, either inadvertently or through phishing or social engineering. A malicious website could prompt the user to switch networks, or a compromised application could request transaction signatures on an unexpected chain. Rabby’s transaction interpretation displays the network name and chain ID before signing, providing a verification point, but users must develop the habit of pausing to confirm these details.

Network RPC endpoint reliability also affects usability across multiple chains. If a pre-configured network’s public RPC endpoints are congested or frequently unavailable, users may experience delayed balance updates or transaction failures. Some users prefer adding backup RPC endpoints or switching to alternative providers if they encounter persistent issues. Rabby allows modification of network settings, enabling users to add or replace RPC endpoints as needed.

Recovery and security remain unchanged across all networks. Rabby is self-custodial, meaning the recovery phrase controls the same addresses on every EVM-compatible chain. This is convenient: one recovery phrase regenerates all balances across all configured networks. However, it also means that if the recovery phrase is compromised, all assets on all networks are at risk simultaneously. Protecting the recovery phrase offline, never entering it into online systems, and testing recovery procedures on a testnet before relying on them should be non-negotiable practices for multi-chain users holding significant amounts.

The practical limits of EVM wallet flexibility

Rabby’s support for 50+ EVM chains provides genuine flexibility for users who need to operate across multiple blockchains. However, that flexibility comes with complexity. Each network has different liquidity, different fee structures, different security assumptions, and different bridge mechanisms. A user who fragments assets across many networks may face higher total costs and slower withdrawals compared to someone who concentrates on fewer, more established chains.

The wallet also does not provide integrated cross-chain functionality. Moving funds between networks requires using external bridges, DEX aggregators, or native bridge interfaces. This separation of concerns is intentional: Rabby remains a wallet and account manager rather than attempting to abstract away the distinct characteristics of each network. A user who understands the trade-offs and takes time to verify networks and RPC endpoints gains flexibility; a user who treats all EVM chains as identical risks confusion and mistakes.

For most users, a practical approach is to maintain primary holdings on Ethereum mainnet and one or two Layer 2 solutions that match their usage patterns. If frequent small transactions are needed, Arbitrum or Optimism reduce costs. If NFT trading is primary, Polygon may be relevant. Testnet networks should be kept separate from mainnet configuration to prevent accidental transactions on test chains. Over time, as comfort with multi-chain management increases, adding additional networks becomes more feasible. But starting with a clear understanding of how each network differs—and verifying network parameters carefully—remains the foundation for secure multi-chain wallet management.