Rabby Wallet Custom Network Configuration: Adding Rollups, Sidechains, and Private Testnets

A developer building on Arbitrum needs to test contract interactions before mainnet deployment. A trader wants to monitor positions on Optimism without switching wallets. A protocol team running a private testnet requires team members to connect and verify smart contracts. Each scenario requires adding a network that does not appear in Rabby Wallet’s default list. The wallet’s architecture supports custom network configuration, but the process involves technical decisions—RPC endpoint selection, chain ID validation, and symbol mapping—that directly affect whether transactions succeed, assets display correctly, or funds remain accessible.

Rabby’s multi-chain support includes Ethereum mainnet, major Layer 2 solutions, and a selection of sidechains by default, but the environment of EVM-compatible networks extends far beyond those presets. Custom network addition is not a rare edge case; it is a routine requirement for anyone moving between different execution environments, testing environments, or emerging blockchain infrastructure. Understanding how to configure these networks correctly separates smooth operations from lost funds, failed transactions, and hours debugging transaction history.

The mechanics of adding a custom network to Rabby

Rabby Wallet’s network management interface is accessed through the settings menu, where users can view active networks, toggle between them, and add new ones. The custom network form requires several mandatory fields: a network name (for display only), the RPC endpoint URL, chain ID, currency symbol, and optional block explorer URL. Each field serves a specific purpose in ensuring that the wallet can communicate with the network and display transactions correctly. The network name is arbitrary and helps users distinguish networks locally; the actual connection depends entirely on the RPC endpoint and chain ID pairing.

The chain ID is a numeric identifier that prevents transaction replay attacks between different networks. If a transaction is signed on Ethereum mainnet (chain ID 1) and someone attempts to replay it on Arbitrum (chain ID 42161), the chain ID mismatch invalidates the signature. When adding a custom network, the chain ID must match exactly what the target network expects. A single-digit error—such as entering 42160 instead of 42161—will result in signed transactions that the network rejects as invalid. This is not a case where the wallet can correct the mistake; the transaction fails silently or produces a cryptic error message.

The RPC endpoint is the gateway through which Rabby communicates with the blockchain. It reads balances, constructs transactions, broadcasts them, and retrieves historical data. Public endpoints are typically rate-limited and may become unavailable without notice. Private endpoints, provided by services like Alchemy, Infura, or QuickNode, offer higher reliability and faster response times at a cost. For development and testing, running a full node locally provides maximum control but requires significant disk space and system resources. The choice affects not only transaction speed but also the information the endpoint provider can observe about wallet activity.

Once configured, the custom network appears in the Rabby EVM wallet’s network selector dropdown, accessible alongside Ethereum, Polygon, and other presets. The wallet will automatically use that network’s RPC endpoint for balance queries and transaction submissions whenever the user switches to it. However, the wallet cannot validate whether the endpoint is legitimate, up-to-date, or configured correctly until a transaction is attempted. This creates a window where configuration errors remain hidden until they cause real problems.

RPC endpoint selection and reliability considerations

An RPC endpoint is not merely a connection string; it is a point of observation and a potential single point of failure. When Rabby queries an endpoint for your balance, the endpoint’s operator can log the request, observe your address, and correlate it with your IP address if the connection is not routed through privacy protection. For users concerned with privacy, endpoints provided by centralized companies (Infura, Alchemy, Etherscan) create correlations between queries and the user’s wallet. Decentralized RPC services such as Blast, Ankr, or node-as-a-service offerings from different geographic regions can distribute this observation burden.

Public endpoints are free but unreliable. They have request limits, can go offline without warning, and may lag behind the network’s head block. A wallet querying a lagging endpoint may show outdated balances or fail to detect incoming transactions for several blocks. This is not a security failure; it is a usability failure. A user checking their balance may see incorrect information, or a transaction may appear to fail when it is actually still processing on the network.

Dedicated endpoints require API keys, which introduce an additional attack surface. If an API key is accidentally committed to a public GitHub repository, exposed in a browser’s developer console, or captured by malware, an attacker can impersonate requests from that account, potentially exhausting the quota and degrading service for legitimate users. The API key should be treated as sensitive as a private key in environments where it could be intercepted.

For Rabby Wallet setup on critical networks or high-value accounts, running a full node locally or using a node-as-a-service provider with strong security practices is preferable. Mainnet Ethereum clients such as Geth, Erigon, or Nethermind can run on consumer hardware but require 1–2 terabytes of disk space and several days to synchronize. For rollups and sidechains with lower transaction volume, synchronization is faster. Layer 2 networks like Arbitrum or Optimism provide public RPC endpoints with reasonable reliability because the layer 2 sequencer coordinates all transactions through a single entity.

Configuring rollups and sidechains correctly

Layer 2 rollups (Arbitrum, Optimism, StarkNet), sidechains (Polygon), and alternative Layer 1s (Avalanche, Fantom) each have distinct characteristics that affect how Rabby displays transactions and calculates gas fees. Arbitrum One uses chain ID 42161 and typically displays transaction costs in gwei, denominated in ETH equivalents for bridge interactions. Optimism (chain ID 10) uses a different fee calculation mechanism with base fees and priority fees. Polygon (chain ID 137) operates as a sidechain with its own native MATIC token and lower transaction costs but operates independently of Ethereum’s consensus.

The currency symbol field in Rabby determines what appears next to balances and transaction amounts. For Arbitrum and Optimism, using “ETH” is conventional even though both networks execute EVM code and their native assets represent wrapped or bridged ether. For Polygon, “MATIC” is standard. For private testnets or custom sidechains, the symbol can be arbitrary, but consistency across tools matters. If a testnet uses “TEST” as its symbol, configure that in Rabby; if other tools display “TST,” the mismatch creates confusion about whether different tokens are involved.

Block explorer URLs are optional but highly valuable for debugging. When you include a block explorer URL (such as `https://arbiscan.io/` for Arbitrum), Rabby adds a “View on Explorer” link next to transactions. This allows quick verification of transaction status, input data, and gas usage without manually constructing the URL. For private testnets, block explorers may not exist or may be limited to a private instance. In those cases, leaving the field blank is acceptable, though documenting the explorer URL elsewhere is wise.

A common mistake is copying the block explorer’s general domain instead of the chain-specific RPC endpoint. For example, `https://arbiscan.io/` is a web interface; the actual RPC endpoint is typically `https://arb1.arbitrum.io/rpc/`. Using the wrong URL results in HTTP 405 or 404 errors, which Rabby may display as “Network error” without clearly indicating that the endpoint is unreachable or misconfigured.

Private testnet and development network configuration

Development teams often run private Ethereum or EVM-compatible testnets using tools like Hardhat, Ganache, or Foundry. These local networks typically run on `localhost:8545` or another port on the developer’s machine. To connect Rabby to a local testnet, the RPC endpoint would be `http://localhost:8545`, and the chain ID must match what the local network is configured to use (commonly 31337 for Hardhat, 5777 for Ganache, or custom values for custom chains).

Local networks introduce unique challenges. If Rabby is running in a browser extension on the same machine, `localhost` typically resolves correctly. However, if the extension and testnet are on different machines or in different containers, localhost connections fail. Some developers work around this by exposing the testnet RPC on a network interface (e.g., `http://192.168.1.100:8545`), but this sacrifices isolation and increases security risk. A better approach is to run a tunneling tool like ngrok to expose a local RPC endpoint over HTTPS, though this adds complexity and potential latency.

Another consideration is account availability. A local testnet created with Hardhat includes pre-funded accounts specified in the configuration file. These accounts have known private keys and are intended only for development. If a developer imports one of these pre-funded accounts into Rabby (or any wallet), that account is no longer secure and should not be used for any funds of value. The pre-funded accounts are useful for testing contract interactions; they are not suitable for managing real assets.

State between testnet restarts is lost. If a developer stops and restarts Ganache without a persistent database, all previous transactions, contract deployments, and account state are erased. Rabby will still show the account balance as it was before the restart (cached locally), but the testnet’s state is fresh. This creates a mismatch where the wallet claims funds exist, but the network has no record of them. Restarting or refreshing the network connection in Rabby helps, but it underscores why development is different from production use.

Common configuration errors and troubleshooting

The most frequent error is a typo in the RPC endpoint URL. The wallet will attempt to connect but receive an HTTP error response. Symptoms include “Network is unreachable,” “Failed to fetch,” or “Incorrect RPC URL.” To verify the endpoint, users can test it independently using curl or a tool like Postman, sending a simple JSON-RPC request such as `{“jsonrpc”:”2.0″,”id”:1,”method”:”eth_blockNumber”,”params”:[]}` to the endpoint. If the endpoint responds with a valid block number, the RPC is functioning; if it returns an error or times out, the endpoint is misconfigured or offline.

Chain ID mismatches prevent transaction signing. A user configures a network with chain ID 1 (Ethereum mainnet) but points the RPC to Arbitrum (chain ID 42161). Transactions signed with chain ID 1 are invalid on Arbitrum, and the network rejects them. Rabby does not automatically validate that the RPC’s actual chain ID matches the configured chain ID until a transaction is submitted. The error message is typically “Invalid transaction” or “Transaction reverted” without indicating that the chain ID is the issue. Checking the chain ID can be done using `eth_chainId` JSON-RPC method; the response should be in hexadecimal (0x1 for chain ID 1, 0xa4b1 for chain ID 42161).

Currency symbol mismatches do not prevent transactions but create confusion. If a network’s native currency is configured with the wrong symbol, balances display with the incorrect label. This is cosmetic but can lead to errors if the user believes they are looking at the wrong asset. Correcting the symbol in the network configuration immediately updates the display.

RPC rate limits and quota exhaustion cause intermittent failures. A public endpoint or a dedicated endpoint with a low quota may start rejecting requests after a certain threshold. The wallet will display errors like “Too many requests” or “Rate limit exceeded.” Switching to a different RPC provider or upgrading to a higher-tier plan resolves this. Some users maintain a list of alternative endpoints and manually switch if the primary one becomes unreliable.

Security considerations when adding custom networks

Adding a custom network requires trust in the RPC provider and the information provided about the network. If a malicious actor provides a fake RPC endpoint and convinces users to add it, they can intercept transactions, display incorrect balances, or simulate failed transactions to capture retry attempts. The network name and symbol fields can also be misleading—a network named “Ethereum” with symbol “ETH” connected to a fake RPC endpoint appears legitimate but is entirely under the attacker’s control.

The primary defense is to verify information through multiple independent sources. Before adding a custom network, confirm the chain ID, official RPC endpoint, and block explorer URL from the blockchain’s official documentation or GitHub repository. For well-established networks like Arbitrum and Optimism, Rabby includes them by default; users should rarely need to add custom RPC endpoints for these networks unless they have specific reasons (like running a personal node).

For development and private testnets, the risk is lower because the networks are typically controlled by the development team and operate in isolated environments. However, the security principle remains: only connect to networks you control or explicitly trust. If a third party provides network configuration details (especially in email or chat), verify them independently before entering them into Rabby.

Once a network is added, Rabby will remember it in the browser extension’s local storage. If the browser or extension is compromised, an attacker could modify the stored network configuration, changing RPC endpoints or chain IDs without the user’s knowledge. The download link for the Rabby Wallet app is exclusive to rabby.io and verified app stores to prevent installation of compromised versions, but users must still protect their device and browser from malware.

Testing and validating custom network configurations

After adding a custom network, validation involves a series of checks before moving significant funds. First, switch to the network in Rabby and observe whether the balance displays correctly. If the balance shows “0” when funds should be present, the RPC endpoint may be wrong, the chain ID may be incorrect, or the account simply has no balance on that network. A test transaction with a small amount provides concrete confirmation that the configuration works. Send a minimal amount (such as 0.001 of the network’s native currency) to another address under your control and observe whether it appears on the network and in Rabby within the expected block time.

Check the block explorer (if available) to verify that the transaction was submitted to the correct network and includes the expected data. The transaction hash displayed in Rabby should match the transaction hash shown in the block explorer. If they differ, the wallet and network are out of sync, indicating a configuration problem. Viewing transaction details in the explorer also reveals the actual chain ID and RPC endpoint the network is using, which you can cross-reference with your configuration.

For networks using custom currencies or wrapped assets, verify that Rabby displays the correct token balance. If you hold wrapped tokens (such as wrapped ETH on Polygon), ensure that Rabby recognizes them and can display their balances. This often requires adding the token manually to Rabby’s token list by contract address.

Gas estimation is another useful test. Before submitting a real transaction, observe what gas fee Rabby estimates for a simple transfer. Compare this estimate to other sources (such as a block explorer’s gas tracker) to verify that the RPC is providing accurate data. If gas estimates are wildly inaccurate, the RPC may be misconfigured or the network may have unusual fee mechanisms that Rabby does not fully understand.

Advanced configuration: Multi-RPC setup and fallback endpoints

For high-reliability scenarios, some users configure multiple RPC endpoints for the same network, rotating between them if one becomes unavailable. Rabby does not currently support automatic fallback or RPC rotation within a single network configuration, but users can manually switch between different custom configurations if needed. This requires discipline and is primarily useful for power users managing significant assets or running bots that require uninterrupted connectivity.

An alternative approach is to use a service like Ankr or Blast that aggregates RPC requests across multiple node operators, providing built-in redundancy without requiring the user to manage multiple endpoints. These services typically offer free tiers with reasonable rate limits, making them suitable for most use cases.

For organizations or development teams, setting up a dedicated node infrastructure with load balancing and failover ensures consistent performance. This approach is expensive and overkill for individual users but necessary for production systems where downtime creates direct costs.