Why Rabby Wallet Uses Automatic Network Selection (and How to Override It)

A user connects their browser to a decentralized application running on Arbitrum, but their wallet is still configured for Ethereum mainnet. Most wallets force a manual network switch—a step that interrupts the flow and creates friction if the user forgets or makes a mistake. Rabby Wallet Extension takes a different approach: it detects the network requirement from the dApp and switches automatically, reducing that friction while maintaining user control. This design choice reflects a broader philosophy about how self-custodial wallets should handle network complexity on EVM-compatible chains.

Understanding why automatic network selection exists, and when it matters to override it manually, requires examining how the wallet interacts with blockchain RPC endpoints, how it identifies the correct network, and what happens when a dApp requests a chain that the wallet does not yet recognize. The mechanism is not magical, and the safeguards are not perfect. A user who understands the underlying logic can use the feature confidently while avoiding common pitfalls that automatic behavior can introduce.

How automatic network detection works in Rabby Wallet Extension

When a user visits a decentralized application, that dApp communicates with the browser using the Ethereum JSON-RPC standard. The dApp sends a request specifying which blockchain network it expects—for instance, chainId 1 for Ethereum mainnet, chainId 42161 for Arbitrum, or chainId 137 for Polygon. Rabby Wallet Extension listens for this request and compares it to the wallet’s current active network.

If the networks match, nothing happens. The transaction or interaction proceeds with the wallet already on the correct chain. If they do not match, the rabby wallet extension initiates a network switch by updating the active RPC endpoint and displaying a confirmation prompt. This happens in milliseconds, faster than a manual network change would take, and without requiring the user to navigate settings menus or remember which RPC URL belongs to which chain.

The automatic behavior is possible because Rabby maintains a curated list of well-known EVM-compatible networks and their corresponding RPC endpoints. Ethereum, Arbitrum, Optimism, Polygon, Base, Avalanche, Gnosis, and dozens of other chains are pre-configured with verified endpoints. When a dApp requests one of these known chains, the wallet can switch to it immediately. The switch is always presented to the user for confirmation before any transaction is signed, so the user retains final approval.

This design reduces the gap between what the dApp expects and what the wallet is doing. Without automatic detection, a user might accidentally sign a transaction on the wrong chain, sending funds to an address on Ethereum when they intended to transact on Arbitrum. Because addresses are the same format across EVM chains, the transaction would complete silently on the wrong blockchain, and recovery would be difficult or impossible. Automatic network selection prevents this category of error by aligning the wallet with the dApp’s expectation.

RPC switching and endpoint selection

An RPC endpoint is the connection point to a blockchain network. When the rabby wallet extension switches networks, it is changing which RPC endpoint the wallet uses to query balances, simulate transactions, and broadcast signed transactions. Rabby uses a combination of strategies to select reliable endpoints: it includes default public RPC nodes, supports custom RPC URLs, and can integrate with services like Ankr and Alchemy that provide redundancy and rate-limiting protection.

The endpoint selection is not random. For each network, Rabby has identified a primary endpoint and fallback endpoints. If the primary endpoint is slow or unresponsive, the wallet can detect that and switch to a fallback. This process happens transparently during transaction simulation and signing, so the user may not notice unless the network is severely degraded. The goal is to maintain responsiveness while keeping the user on a reliable path to the blockchain.

Users who want more control can set custom RPC URLs for any chain. This is useful for users running their own full node, preferring a specific provider for privacy reasons, or testing on testnets with non-standard endpoints. The custom endpoint is stored locally in the wallet, so it persists across browser sessions. If a custom endpoint is set and the wallet switches to that network, it will use the custom URL rather than the default.

However, custom endpoints introduce a responsibility. An incorrect or malicious RPC URL could return false balance information, simulate transactions incorrectly, or broadcast transactions to the wrong network. Rabby provides transaction simulation and pre-signing checks, but these protections are only as good as the endpoint providing the data. For high-value transactions, verifying the network and RPC endpoint before signing is a practical safeguard that complements the wallet’s built-in warnings.

When to manually override automatic network selection

Automatic network switching is convenient, but there are legitimate scenarios where a user should manually verify or override the wallet’s behavior. The first is when navigating an unfamiliar dApp or visiting a network the user has never used before. Even though the Ethereum wallet interface appears the same across chains, the economic stakes are different. A transaction on a low-cost chain like Polygon or Base involves much smaller fees, while a transaction on Ethereum mainnet or Arbitrum carries higher costs. A user can easily intend to test on a low-cost testnet but accidentally approve a mainnet transaction if the network switch happens silently in the background.

The second scenario involves dApps that request networks not in Rabby’s curated list. If a decentralized application is deployed on an obscure or newly created EVM chain, the wallet may not recognize it. The dApp will send the chainId, but if it is not pre-configured, the wallet will prompt the user to add the network manually. At this point, the user must enter the RPC endpoint details. This is where caution matters: an incorrect endpoint URL, or one provided by an untrustworthy source, could redirect transactions or return misleading information. Verifying the RPC URL through independent sources—such as the official documentation of the chain or a community resource—is a practical check before confirming the network addition.

The third scenario is when the user suspects the wallet’s automatic behavior may be interfering with their intent. For example, if a user is managing multiple wallets or testing trading strategies across chains, they might want to keep the wallet on a specific network even if a dApp requests otherwise. Rabby allows users to tap the network selector and manually choose the active network. Once manually set, the wallet will still show a prompt if a dApp requests a different chain, but the user can decline the automatic switch and remain on their chosen network.

Lastly, users who prefer to remain on a specific EVM network—perhaps to minimize slippage or manage gas costs—can override automatic switching by simply declining the network change prompt when it appears. Rabby will then show a warning that the dApp is requesting a different network than the wallet’s current selection, and the user can decide whether to switch, proceed anyway, or leave the page. This approach gives the user full control while preserving the convenience of automatic detection for ordinary interactions.

Transaction simulation and pre-signing checks

Before a user signs any transaction, Rabby performs a simulation on the chosen network to estimate gas costs, expected balance changes, and any warnings about unusual behavior. This simulation runs on the RPC endpoint associated with the current network, so the accuracy depends on that endpoint being correct and up-to-date. If automatic network switching has happened without the user’s awareness, the simulation could be running on the wrong chain entirely.

The transaction preview in Rabby shows the expected balance change clearly: if a user is sending 1 Ether, they will see “–1 ETH” and the approximate USD value if token prices are available. If a user is swapping tokens through a dApp, the preview will attempt to show the expected output token amount. These previews are estimates based on the current network state, so the actual result may differ slightly due to slippage, price movement, or additional contract logic. However, they should match the network where the transaction will actually settle.

If the wallet has automatically switched to a network that the user did not intend, the preview will show balances and gas costs for the wrong chain. A user might see “Insufficient balance” for a token that they actually hold on a different network. Or they might see low gas costs associated with a cheaper chain and approve a transaction expecting to pay that amount, only to discover later that they are actually on Ethereum mainnet paying 10 times as much. The automatic network selection is supposed to prevent this, but a user’s awareness of which network is active at the moment of signing remains the most reliable safeguard.

Avoiding the fake extension and ensuring proper configuration

One of the highest-impact security measures with any blockchain wallet extension is downloading from the correct source. Rabby Wallet Extension is available only through official channels: the Chrome Web Store, the official site rabby.io, and verified app stores for mobile. Counterfeit extensions with similar names exist and are designed to steal recovery phrases or private keys. If a user downloads a fake version, no amount of automatic network switching will protect their funds.

The authentic rabby wallet extension can be verified by checking the publisher name in the browser’s extension management page, confirming it is published by Rabby, and comparing the extension ID to official documentation. The wallet requires only a password for local use—no email or account sign-up. If a user is prompted to create an online account or provide credentials to a third party, they are likely using a fraudulent version.

Once installed correctly, the wallet’s configuration should reflect the user’s intended usage. If the user primarily interacts with Ethereum, the wallet’s default network should be Ethereum mainnet. If the user frequently uses Polygon or Arbitrum, setting a different default network in the wallet settings can reduce the number of automatic switches they encounter. These preferences are stored locally, so the user’s network history and default selection persist across browser sessions and device restarts.

Users should also verify that only trusted dApps are installed and that browser permissions are correctly scoped. A malicious webpage cannot access Rabby Wallet’s private keys directly, but if a user approves a malicious transaction through the wallet’s interface, the transaction will execute normally. The automatic network switching feature does not change this fundamental rule: the user’s approval is the decisive gate. If a user has connected the wallet to a compromised dApp and that dApp requests a network switch, the automatic behavior might even make the attack faster.

Testing and validating network switches on testnets

A practical way to become comfortable with automatic network switching is to test it on blockchain testnets such as Sepolia, Goerli, or Mumbai. These networks use test Ether or test tokens that have no real value, so mistakes are consequence-free. A user can set up a test wallet, request testnet funds from a faucet, and visit dApps on different testnets to observe how Rabby switches networks, displays previews, and prompts for confirmation.

During testing, pay attention to the balance display before and after each network switch. The wallet should show only the tokens available on the current network, and the token symbols should remain consistent even as the underlying network changes. The gas price estimates should also shift noticeably between networks—testnet fees are typically much lower than mainnet, so switching from Ethereum Goerli to Arbitrum Sepolia should show a significant reduction in estimated transaction costs.

If a test transaction fails or behaves unexpectedly, the user can investigate by checking the transaction hash on the correct testnet’s block explorer. This teaches the user where to look when something goes wrong on mainnet, and it builds confidence in the wallet’s behavior before real funds are at stake. Testing also reveals whether custom RPC endpoints, if the user is using them, are working correctly. A failed testnet transaction might indicate a slow or unreliable endpoint that should be replaced.

Users who plan to frequently interact with multiple networks should also test the manual override workflow. Set the wallet to a specific network, then visit a dApp on a different chain and decline the automatic switch prompt. Confirm that the wallet remains on the manually selected network and that the dApp displays an appropriate warning. This practice ensures that the user knows how to stay on a specific network if automatic switching ever interferes with their intended behavior.

Advanced network management and custom configurations

For users managing complex portfolios or integrating the Ethereum wallet into automated workflows, custom network management becomes important. Rabby allows users to add entirely new networks beyond the pre-configured list. This requires providing the network name, chain ID, RPC URL, block explorer URL, and native token details. Incorrect information at this step can create significant problems, so users should verify each detail against authoritative sources.

Custom networks are useful for private blockchain deployments, Layer 2 rollups that are not yet widely integrated, or sidechains specific to a particular ecosystem. However, each custom network introduces a new potential point of failure. If the RPC endpoint is compromised or misconfigured, the wallet could sign transactions on an incorrect or forked version of the intended chain. If the chain ID is wrong, transactions might not replicate correctly across network forks.

Users managing multiple custom networks should document their RPC endpoints and configuration separately, outside the wallet. If the browser is reset or the wallet is reinstalled, having a record of the custom network details allows the user to reconfigure them quickly and verify that the new configuration matches the previous one. This is a form of resilience against data loss or browser issues that could otherwise require reconstructing the network setup from memory.

For users who want even tighter control, Rabby supports hardware wallet integration. Connecting a hardware device like a Ledger or Trezor does not change how automatic network switching works, but it does add a physical confirmation step. The hardware device will display the transaction details and network information before the user approves the signature, providing an additional checkpoint before any transaction is finalized. This approach is appropriate for users holding significant assets and willing to accept the slower approval process.

Reconciling convenience with security awareness

The fundamental tension in automatic network switching is that convenience and security often pull in opposite directions. A feature that reduces friction can also reduce awareness. A user who never manually selects a network might not develop a mental model of how networks work or feel confident recognizing when something is amiss. On the other hand, a wallet that constantly interrupts the user with network confirmation prompts drives users toward less secure alternatives that automate away the friction entirely without the safety checks.

Rabby Wallet Extension attempts to balance this by automating the routine case—switching to a known, pre-configured network—while still requiring confirmation and providing clear previews. This is a reasonable middle ground. However, it relies on the user paying attention to the network confirmation prompt and the transaction preview. If a user habitually clicks “confirm” without reading, the automatic behavior becomes a liability.

The most sustainable security posture is for users to develop habits that work with the wallet’s design rather than against it. Before signing any transaction, take a moment to verify the active network displayed in the wallet interface. Check that it matches the dApp’s expectation. Confirm that the transaction preview shows the correct expected balance change. And if anything seems off—if the network is unexpected, the balance is wrong, or the preview is unclear—decline the transaction and investigate before proceeding.

As the blockchain wallet ecosystem becomes more complex, with dozens of EVM-compatible chains and constant new deployments, automatic network selection will likely become more common rather than less. Understanding how Rabby implements this feature, and knowing when to override it manually, prepares users to make informed decisions whether they are interacting with a simple dApp or managing assets across multiple chains. The wallet’s job is to provide the tools and information. The user’s job is to remain attentive and aware.