A user installs Rabby on Chrome, configures their Ethereum wallet, and everything works smoothly for a day. Then the network slows. A transaction hangs mid-approval. The balance display freezes. The extension becomes unresponsive, eventually timing out or showing a generic connection error. The wallet itself functions correctly—the private key remains secure, the contract logic is sound—but the user cannot access their funds because the communication channel to the blockchain has failed. This is not a cryptographic problem. It is an infrastructure problem, and it is entirely fixable through proper RPC node configuration.

Rabby Wallet operates as a self-custodial, open-source browser extension for Chrome, Brave, and Edge, plus native mobile apps and desktop versions, all designed to interact with Ethereum and EVM-compatible blockchain networks. Unlike centralized exchanges, Rabby holds private keys locally and does not custody assets on its servers. That architecture protects users from platform failures, but it also means every transaction, balance check, and smart contract interaction depends on communication with a blockchain node. When that connection is unreliable, the wallet becomes effectively inaccessible—not because of a flaw in Rabby itself, but because the underlying network layer has collapsed. Understanding why these failures occur and how to configure fallback RPC endpoints can mean the difference between a momentary inconvenience and hours of lost access to funds.

How RPC endpoints determine wallet responsiveness

An RPC, or Remote Procedure Call, endpoint is an HTTP or WebSocket address that the wallet uses to communicate with a blockchain node. When a user opens Rabby and clicks a balance, the extension sends a request to an RPC endpoint asking for the account balance on a specific chain. That endpoint is operated by someone—Infura, Alchemy, Ankr, the Ethereum Foundation, or a private operator—and it relays the request to a full node, which returns the data. Rabby caches some information locally, but every balance update, token approval, transaction simulation, and network status check requires at least one RPC call.

The default RPC endpoints Rabby provides are public services with rate limits and finite capacity. During periods of high network traffic, these endpoints become congested. Not congested in the sense that a single request fails, but congested in the sense that response times stretch from milliseconds to seconds, or timeouts occur entirely. A slow internet connection on the user’s end exacerbates this problem because the round-trip time already includes latency from the user’s location to the endpoint’s server. If the endpoint also experiences high load, a request that should complete in 100 milliseconds might take 3 seconds. The browser extension has a timeout, usually between 5 and 30 seconds depending on the operation. When that limit is hit, the request fails, and the user sees an error or watches the interface freeze.

The severity of the problem scales with network congestion. During normal Ethereum activity, a public RPC endpoint may handle tens of thousands of simultaneous requests with acceptable latency. During high-volatility events, competing protocols launching, or major NFT mints, the same endpoints can become overwhelmed. Private RPC services such as Infura, Alchemy, or QuickNode maintain separate infrastructure for paying customers, offering higher rate limits and more reliable performance. Free tiers have sharing, and shared public endpoints are subject to network-wide demand. That is the fundamental trade-off: public RPC endpoints are free and permissionless, but they offer no performance guarantee.

Rabby’s approach is to provide a default set of RPC endpoints and allow users to configure custom endpoints as fallbacks. The wallet also includes automatic network detection, attempting to recognize which blockchain the user intends to interact with based on the dApp they have visited. This is helpful, but automatic detection depends on successful communication with an RPC endpoint. If all endpoints are timing out, the wallet cannot determine which chain is active, and the user is stuck in a state where no transactions can be broadcast and no balances can be refreshed.

Why slow internet amplifies RPC timeout failures

A slow internet connection does not necessarily mean a small bandwidth problem. It can mean high latency, where each request-response cycle takes several seconds even though the actual data transfer is small. A blockchain RPC call transmits kilobytes at most; the delay is usually the round-trip time plus the server’s response time. If a user is on a satellite internet connection, an international VPN, or a congested mobile network, their latency to a US-based RPC endpoint might be 500 milliseconds or more before the server even processes the request.

The extension’s behavior compounds the issue through sequential requests. Rabby typically fetches the account balance, then queries token contract data, then checks for pending transactions, then refreshes the transaction history. If each request has a 1-second latency and the server takes 1 second to respond, the total time for a full balance update can be 5 to 10 seconds. If the user’s connection drops a packet, the request must be retried, adding another full round-trip. If the RPC endpoint itself is overloaded, the server response time climbs from 1 second to 5 or 10 seconds, and the user hits the timeout before the request completes.

The browser extension environment also limits how Rabby can recover from these failures. A web application can implement aggressive retry logic with exponential backoff, progressively increasing the delay between attempts. An extension has constraints on memory, CPU, and the number of concurrent background processes it can maintain. If too many retry loops start in the background, the browser may throttle or kill them. The extension’s UI thread can also become unresponsive if network requests block it, making the wallet appear frozen even though the timeout is expected behavior rather than a bug.

Configuring fallback RPC endpoints for chain redundancy

The solution is to configure multiple RPC endpoints so Rabby can attempt a second or third provider if the primary endpoint times out. To access this setting, open the Rabby extension, click the menu icon, select «Settings,» then navigate to «Network.» The interface shows a list of chains with their associated RPC endpoints. For Ethereum mainnet, Rabby provides a default public RPC, but a user can add additional endpoints by clicking «Add Custom RPC» or editing the existing chain configuration.

A practical setup includes at least two public RPC providers with geographically distributed infrastructure. If one provider is experiencing US-region congestion, the second provider, located in Europe or Asia, may have lower latency and available capacity. Good options include Infura, Alchemy, Ankr, QuickNode, and Llama RPC. Many of these offer free tiers that provide thousands of requests per day, sufficient for ordinary wallet use. The key is to select providers with different underlying infrastructure so they do not fail simultaneously. Infura uses AWS, while Alchemy uses a custom cloud setup, and Ankr uses a decentralized node network. Using one provider from each category reduces the likelihood that a single outage affects all endpoints.

After adding a custom RPC endpoint, Rabby may allow configuration of which endpoint is primary and which are fallback. If the wallet does not explicitly manage fallback order, it will try each endpoint sequentially. The first successful response wins, and that endpoint is used for the duration of the session. If a user’s primary endpoint becomes unresponsive halfway through a transaction approval, the next transaction may automatically try the fallback endpoint. This is transparent to the user but can be the difference between a successful transaction and an apparent hang.

Transaction simulation and preview robustness

One of Rabby’s distinguishing features is transaction simulation, where the wallet previews the expected outcome of a transaction before the user signs it. This shows the actual token amounts the user will receive, any slippage on a swap, fees, and whether the transaction is likely to fail. The simulation itself requires multiple RPC calls: one to retrieve the current state of the smart contracts involved, another to simulate the transaction execution, and sometimes a third to fetch historical data for price estimation.

If the primary RPC endpoint times out during simulation, the user sees a warning that the preview could not be generated. This can be frustrating because the user may not realize they have added a fallback endpoint, and they may think the transaction is too risky to approve without a preview. In reality, a properly configured wallet should attempt the fallback RPC and generate the preview from the second provider. If Rabby’s fallback logic is slow or the timeout is too aggressive, the simulation may fail even though a successful backup endpoint exists.

To improve reliability, users should verify that their fallback RPC is actually being tried. One method is to temporarily disable the primary RPC in Rabby’s settings, then attempt a transaction simulation. If it succeeds, the fallback is working. If it times out, the fallback endpoint itself may be overloaded or misconfigured. This testing should be done with a small transaction or a read-only operation, not a large transfer. After confirming that the fallback works, re-enable the primary RPC. The wallet should now recover gracefully when the primary endpoint becomes slow.

Network detection and chain-switching delays

Rabby includes a feature called automatic network selection, which attempts to detect which blockchain the user intends to interact with based on the current web page or dApp. When a user visits a dApp like Uniswap, Rabby queries the dApp’s expected chain ID and switches the extension’s active network accordingly. This is convenient but it also depends on successful RPC communication. If the RPC endpoint for Ethereum is timing out, the network detection cannot complete, and the user may see an error or the extension may remain stuck on the previous chain.

The extension’s behavior can be further complicated if the user manually switches chains while the RPC is degraded. If Rabby is attempting to fetch chain data for Ethereum and simultaneously receives a manual switch command to Polygon, the extension may queue both requests or cancel the first one. If the cancellation logic is incomplete, the extension might be left in an inconsistent state, showing a chain it is not actually connected to. This is rare but can happen during high-latency conditions when multiple requests overlap.

Users can avoid this issue by ensuring their RPC endpoints include common EVM chains where they hold assets or interact with dApps. If a user primarily trades on Ethereum and Arbitrum, they should configure fallback RPC endpoints for both chains. download rabby wallet from the official rabby.io source and then immediately check Settings to add these custom endpoints before making transactions. The initial setup takes five minutes and can prevent hours of frustration later.

Detecting whether the problem is RPC or device-level

Not every wallet freeze is an RPC problem. If Rabby is unresponsive and network diagnostics show normal internet connectivity, the issue could be the browser itself, the extension’s local database, or a conflict with another extension. To diagnose, open the browser’s developer tools (F12 on Windows, Option-Command-I on Mac) and check the Console tab. If Rabby is experiencing RPC timeouts, the Console may show network errors like «failed to fetch» or «timeout waiting for response from [endpoint URL].» These messages confirm the RPC endpoint is the bottleneck.

If the Console shows no network errors but the extension is still frozen, the problem is likely local. Possible causes include the extension’s local database becoming corrupted, browser cache exhaustion, or conflicts with other security extensions. The first troubleshooting step is to clear the extension’s data. In Rabby’s settings, look for «Clear Cache» or «Reset Wallet.» This deletes the cached blockchain data but does not affect the wallet’s private keys or balances. After clearing, close and reopen the extension. If the wallet becomes responsive, the issue was database-related.

If clearing the cache does not help, temporarily disable other browser extensions and test Rabby in isolation. Chrome’s Extension Management page (chrome://extensions/) allows disabling extensions without removing them. If Rabby becomes responsive when other extensions are disabled, one of them was interfering. Re-enable them one at a time to identify the culprit. Common conflicts occur with VPN extensions that intercept all network traffic, or password managers that attempt to auto-fill wallet data fields.

Optimizing RPC configuration for mobile and desktop environments

Rabby’s mobile apps and desktop versions face similar RPC challenges as the Chrome extension, but the configuration process differs slightly. On mobile, the wallet is typically available for iOS and Android through their respective app stores, and the RPC configuration is accessed through the wallet’s settings menu rather than a browser interface. The same principle applies: add multiple RPC endpoints to create redundancy.

Mobile networks present unique challenges because connectivity can shift rapidly. A user might start a transaction on 4G with good latency, then move and drop to 3G with 2-second latency. During this transition, a transaction could timeout midway. To mitigate this, users should configure RPC endpoints operated by services with global CDN infrastructure, such as Alchemy or Ankr, which have nodes in multiple regions and automatically route requests to the nearest server. These services are faster for mobile users because the endpoint’s nearest server might be closer than a single geographically fixed node.

Desktop versions of Rabby offer the same configuration options as the browser extension. However, desktop applications can implement more sophisticated fallback logic because they are not constrained by the browser’s extension environment. A desktop version can maintain persistent connections to multiple RPC providers, pinging them in the background and automatically routing traffic to the fastest responder. This is more reliable than sequential fallback attempts, but it also requires more configuration upfront. Users should review the documentation for their specific version to understand how RPC endpoints are prioritized.

When to use private RPC services versus public endpoints

For most users, public RPC endpoints with one or two fallbacks are sufficient. However, users who frequently interact with smart contracts, mint NFTs, or participate in time-sensitive DeFi activities should consider a private RPC service. Private RPC providers such as Infura Pro, Alchemy Growth Tier, or QuickNode’s professional plans offer dedicated infrastructure with guaranteed uptime, prioritized response times, and MEV protection. These services cost money—typically $10 to $100 per month depending on usage—but they eliminate the shared-resource problem entirely.

The choice between public and private RPC depends on three factors: transaction frequency, asset value at risk, and tolerance for downtime. A user who checks their balance once a week can use public endpoints. A user who executes 20 transactions per day and holds significant value should evaluate a private RPC. A user who is actively participating in time-sensitive activities like liquidations or arbitrage should have a private RPC plus public fallbacks. The cost of a private RPC service is trivial compared to the cost of missing a transaction or experiencing days of wallet inaccessibility.

For maximum reliability, a power user should configure at least three RPC endpoints: one private paid service as primary, one public endpoint from a different provider as secondary fallback, and a third public endpoint from yet another provider as tertiary fallback. This setup is resilient to single-provider outages and can handle congestion periods gracefully. Rabby’s extension does not yet provide a formal prioritization UI for multiple endpoints on a single chain, but the wallet will iterate through configured endpoints and use the first one that responds successfully, which effectively implements a fallback mechanism.