A developer working with private Ethereum-compatible chains or testing smart contracts on multiple testnets faces a practical friction point: managing network configurations across wallet applications. Standard wallets come with a fixed list of public networks—Ethereum mainnet, Polygon, Arbitrum, and a few others—but private blockchains, internal staging environments, and testnet variants require manual configuration. Rabby Wallet, being EVM compatible and designed to work seamlessly with Ethereum and its ecosystem, provides the infrastructure for custom RPC network addition, but the process demands understanding what information to gather, where to input it, and how to verify that the configuration actually works.
Unlike some wallets that restrict custom networks or bury the functionality, Rabby Wallet exposes the ability to add arbitrary RPC endpoints directly in the interface. This flexibility serves a legitimate use case: developers testing on Sepolia or Goerli testnets, teams running private Ethereum clones for staging, and users interacting with Layer 2 or sidechain deployments that are not yet included in the default list. However, adding a custom network is not simply a matter of copying an endpoint URL. Chain ID mismatches, incorrect RPC method support, and misconfigured block explorers can create silent failures where transactions appear to succeed locally but never settle, or where balances display incorrectly. Understanding the mechanism prevents those errors.
Understanding what information a custom network requires
Before opening Rabby Wallet to add a network, gather the essential parameters. Every EVM-compatible blockchain has a Chain ID—a unique integer that identifies the network and prevents transaction replay across different chains. Sepolia testnet, for example, uses Chain ID 11155111, while the Polygon mainnet uses 137. If the chain ID is incorrect, the wallet may accept the network but transactions signed for one chain could theoretically be replayed on another if both chains share the same RPC endpoint or if the endpoint is misconfigured.
The RPC endpoint is the HTTP or HTTPS URL through which the wallet communicates with the blockchain. This endpoint must support the standard Ethereum JSON-RPC methods: eth_chainId, eth_accounts, eth_getBalance, eth_sendTransaction, and others. A private network or testnet operator may provide an official RPC URL, or the developer may be running a node locally (in which case the endpoint might be http://localhost:8545 or similar). The critical detail is that the endpoint must actually be reachable and responsive; an incorrect URL or a node that is down or improperly configured will cause the wallet to hang or display a “network error.”
A currency symbol and decimal places parameter tell Rabby how to display balances and transaction amounts. Most EVM chains use 18 decimals, matching Ethereum’s model where 1 token equals 10^18 wei. However, some custom chains may define different precision. The currency symbol (ETH, MATIC, AVAX, or a custom name) is purely for display; it does not affect functionality but helps users recognize which chain they are operating on.
The block explorer URL is optional but valuable. If configured, it allows users to click through from transaction details in Rabby to view the transaction on a public blockchain explorer. For private networks or internal testnets, this may not exist, but for public testnets and new public chains, having a correct explorer link reduces the need to manually copy transaction hashes into a browser. The URL should include a placeholder (often {txHash} or similar) that Rabby will replace with the actual transaction identifier.
Step-by-step process for adding a custom network in Rabby
Open Rabby Wallet in your browser. If you are using a Chromium-based browser such as Chrome, Brave, or Edge, the extension icon should be visible in the toolbar. Click it to open the wallet interface. In the top-left or top-right corner of the interface, there is typically a network selector button displaying the currently active network (e.g., “Ethereum” or “Polygon”). Click that button to open the network list.
At the bottom of the network list, look for an option to add a new network. This is usually labeled “Add Network,” “Custom Network,” or a plus (+) icon. Click it to open the custom network configuration form. Rabby will present fields for network name, RPC endpoint, chain ID, currency symbol, and optionally the block explorer URL. Some versions of Rabby may also ask for the native currency decimal places. Fill in each field with the correct values for your target blockchain. For a private Ethereum clone running locally, the form might look like this: network name “Local Dev,” RPC endpoint “http://localhost:8545,” chain ID “1337” (a common value for local dev chains), currency symbol “ETH,” and decimals “18.”
After entering the details, click the “Add” or “Save” button. Rabby will validate the configuration by attempting to connect to the RPC endpoint and verifying that the chain ID returned by the node matches the value you entered. If the RPC endpoint is unreachable or returns a mismatched chain ID, Rabby will display an error rather than silently accepting the configuration. This validation step is crucial because it prevents a common mistake: copying a chain ID from documentation that applies to a different network or providing an endpoint that is not actually live. Once validation succeeds, the network will appear in your network list and become immediately available for selection.
Working with testnet configurations
Sepolia and Goerli are the most widely used Ethereum testnets, and while Rabby may include default configurations for these networks, developers often need to customize them or add additional testnets. When adding Sepolia, use chain ID 11155111 and an RPC endpoint from a public provider such as Infura, Alchemy, or the Ethereum Foundation’s Sepolia endpoint. The block explorer is typically Sepolia Etherscan (sepolia.etherscan.io), which allows public viewing of transactions and smart contract code.
Private testnets, by contrast, are internal networks that may not have public block explorers or publicly accessible RPC endpoints. If you are running a private testnet for your team or organization, the RPC endpoint will likely be an internal URL or a localhost address, and the chain ID will be a custom value defined by your testnet configuration. Importantly, these networks should never be accessible from the public internet without strong authentication, as exposing a testnet RPC endpoint can allow attackers to simulate transactions or conduct denial-of-service attacks against your infrastructure. If your custom network endpoint requires authentication (some enterprise RPC providers do), you may need to include the API key or authentication token in the endpoint URL itself, such as https://rpc.yournetwork.com?key=your-api-key. Be cautious with this approach, as the key will be visible in the wallet’s configuration; more secure methods involve using environment variables or authenticated HTTP headers, which may require a proxy layer.
When testing smart contracts on a custom testnet, verify that the network is actually accessible from the wallet before deploying funds or creating contracts. A simple test is to check the wallet’s balance display; if it shows “0” with no errors, the RPC endpoint is likely working correctly. If it displays “–” or a loading spinner indefinitely, the endpoint may be slow, overloaded, or misconfigured. After successful configuration, you can import test accounts (using private keys or wallet imports) and begin interacting with smart contracts on that network.
Verifying custom network configuration and avoiding common mistakes
The most common mistake when adding a custom network is providing a chain ID that does not match the actual blockchain. For instance, if you copy a configuration from a tutorial but the tutorial describes a different chain, or if a private network operator changed the chain ID during a migration without notifying users, the mismatch will cause transactions to fail silently. To verify chain ID accuracy, use a simple test: after adding the network, open the Rabby extension, ensure the custom network is selected, and check whether a transaction can be simulated successfully. Rabby includes a transaction simulation feature that previews what will happen before you sign; if simulation fails with a message about chain ID mismatch, the configuration is incorrect.
Another frequent error is providing an RPC endpoint that supports only a subset of Ethereum JSON-RPC methods. Some endpoints are optimized for read-only operations (balance checking, contract calls) and do not support eth_sendTransaction or eth_signTransaction. If you attempt to send a transaction through such an endpoint, Rabby will either hang indefinitely or return an error. To test an RPC endpoint’s capabilities, you can use a simple curl command or an RPC testing tool, or you can simply attempt a small transaction in Rabby and observe the result. If transactions consistently fail, try a different RPC provider or verify that your node is configured to accept transaction submissions.
A third issue arises when the block explorer URL is incorrect. This does not prevent the wallet from functioning, but it can create confusion: users will click the “view on explorer” link and receive a 404 error or be taken to an unrelated website. Verify the explorer URL format by manually constructing a test URL with a known transaction hash and checking that it resolves correctly. For public testnet and mainnet configurations, this is rarely a problem because explorers are well-documented, but for private networks, the explorer URL (if one exists) must be correct or omitted entirely.
Finally, ensure that the RPC endpoint has sufficient rate limits and uptime for your use case. A public endpoint shared by thousands of users may experience throttling or brief outages. For production or high-frequency use, consider running your own node or subscribing to a dedicated RPC service. For development and testing, a public endpoint is usually adequate as long as you understand the potential limitations.
Hardware wallets and imported accounts on custom networks
Rabby supports hardware wallet integration, allowing users to connect Ledger or Trezor devices and sign transactions without exposing private keys to the wallet application. When you add a custom network and then use a hardware wallet account, the signing flow remains the same: Rabby constructs the transaction, displays a preview, and sends it to the hardware device for approval. The hardware device itself does not “know” about the custom network; it only signs the transaction after verifying the chain ID and transaction details. This means that custom networks work seamlessly with hardware wallets, provided the chain ID is correct and the RPC endpoint is reachable.
Similarly, you can import accounts from other wallets (such as MetaMask or a private key export) and use them on custom networks immediately after adding the network configuration. Rabby does not impose any special restrictions on which accounts can access which networks; the only requirement is that the account has funds or permissions on that network. If you import an account that was created on Ethereum mainnet and then try to use it on a private testnet, the account will exist (same address) but will likely have zero balance unless the testnet operator has explicitly funded it.
One practical consideration: if you frequently switch between many custom networks and imported accounts, keep detailed notes about which account holds funds on which network and what the RPC endpoint actually is. Rabby’s interface makes it easy to create multiple custom networks, but it is equally easy to lose track of whether a particular network configuration is correct or outdated. Consider using a consistent naming convention (e.g., “Testnet-Staging-v2.1” or “PrivateChain-Internal”) and periodically removing unused configurations to reduce clutter and confusion.
Security considerations for custom RPC endpoints
Using a custom RPC endpoint introduces a trust relationship with the endpoint provider. The RPC endpoint sees every transaction you broadcast, every balance check you perform, and every contract call you make. In the case of a public testnet like Sepolia, this is generally acceptable because testnet activity is not sensitive and balances consist of free test tokens. However, for private networks or production systems, you should ensure that the RPC endpoint is controlled by a trusted party and that communications are encrypted (HTTPS, not HTTP).
An untrusted or compromised RPC endpoint could potentially return false balance information, inject malicious contract code, or fail to broadcast transactions you intended to send. Rabby provides some protection through its transaction preview and pre-sign security checking features, which display warnings if a transaction appears to interact with suspicious contracts or if the transaction details seem unusual. However, these checks rely on the endpoint providing accurate contract code and state information, so they are not completely robust against a malicious endpoint.
For high-value transactions or sensitive operations, consider using a custom RPC endpoint that you control (by running your own node) or one provided by a reputable, well-established service with transparent infrastructure and security policies. For casual development and testing, a public endpoint or a service like those described in the Rabby crypto wallet documentation is sufficient. Never use an RPC endpoint obtained from an untrusted source or one that requires sharing sensitive credentials over unencrypted channels.
Troubleshooting failed custom network configurations
If you add a custom network and it does not appear to work, follow this diagnostic sequence. First, verify that the RPC endpoint is actually reachable by opening it in a browser or using curl. If the endpoint returns a response (even an error), it is online. If it times out or refuses the connection, the endpoint may be down or blocked by a firewall. Second, confirm that the chain ID in Rabby matches the actual chain ID of the network. Use an RPC tool to call eth_chainId against the endpoint and compare the result to the value in Rabby’s configuration; they must match exactly.
Third, test a simple balance check. Select the custom network in Rabby and verify that the interface displays a balance (or zero balance, if the account has no funds). If the balance displays as “–” indefinitely, the RPC endpoint may not be supporting the eth_getBalance method or may be severely overloaded. Fourth, if you have access to the underlying blockchain logs or node software, check whether your custom network is actually accepting transactions. Sometimes a configuration appears correct in Rabby, but transactions fail silently because the network consensus is broken, the node is out of sync, or the RPC endpoint is not properly connected to the network’s peers.
Finally, consult the network operator’s documentation or support channels. If you are using a private network, the team running it can provide the correct RPC endpoint, chain ID, and any special requirements. If you are using a public testnet or sidechain, the official documentation and community forums will have configurations that are known to work. Copying a working configuration from a trusted source and verifying it step-by-step is often faster than debugging a misconfigured endpoint from first principles.
Future considerations and moving beyond custom networks
As blockchain ecosystems continue to fragment into numerous Layer 2 networks, sidechains, and private chains, wallet usability will increasingly depend on clear, accessible network management. Rabby Wallet’s support for custom RPC endpoints is a practical step toward that goal, allowing developers and testers to work with emerging or internal blockchains without waiting for wallet developers to manually add them to a fixed list. However, this flexibility comes with responsibility: each custom network configuration is a potential source of user error, and incorrect configurations can lead to lost transactions, misrouted funds, or security exposure.
Looking forward, expect tooling improvements around network configuration: standardized configuration files (similar to Hardhat’s networks.config.js) that Rabby or other wallets can import directly, or network registries that allow communities to publish and maintain verified configurations. These improvements would reduce manual entry and the associated error rate. In the near term, users and developers should treat custom network configuration as a critical step that requires careful verification, not a convenience feature to set up casually. The complexity is worth it, because the alternative—being locked to a fixed set of networks—severely limits the wallets’ usefulness in an increasingly diverse blockchain landscape.
Frequently asked questions
What information do I absolutely need to add a custom blockchain to Rabby Wallet?
You need the chain ID (an integer that uniquely identifies the network), the RPC endpoint (a URL where the wallet can communicate with the blockchain), and optionally the currency symbol and block explorer URL. The chain ID and RPC endpoint must match exactly; a mismatch will cause transaction failures or silent errors. Verify this information with the blockchain operator or official documentation before adding it.
Can I use Rabby Wallet with a private Ethereum-compatible blockchain that only my team has access to?
Yes. Rabby supports any EVM-compatible blockchain as long as you have the RPC endpoint, chain ID, and appropriate account credentials. However, ensure that the RPC endpoint is not exposed to the public internet without strong authentication, and use HTTPS for all communications. If the private network requires credentials, they will need to be included in the endpoint URL or handled through a proxy layer.
What should I do if my custom network appears correctly configured but transactions fail or hang?
First, verify that the RPC endpoint is actually online and responsive by testing it in a browser or with a curl command. Second, confirm that the chain ID in Rabby matches the actual chain ID by calling eth_chainId against the endpoint. Third, test a simple balance check to see if the endpoint supports read operations. If configuration appears correct but transactions still fail, consult the network operator or check whether the RPC endpoint supports all necessary Ethereum JSON-RPC methods.
