Rabby Wallet: How to Set Up Custom RPC Endpoints for Private or Testnet Nodes

A development team running a private Ethereum-compatible blockchain, or a trader testing strategies on a testnet before mainnet deployment, faces a practical constraint: public RPC endpoints have rate limits, shared infrastructure can be unreliable, and sensitive transactions should not broadcast through third-party nodes. Rabby Wallet, the non-custodial EVM wallet built by DeBank, supports over 141 EVM chains out of the box, but the real power for advanced users lies in the ability to configure custom RPC endpoints—whether pointing to a private node, a testnet validator, or an enterprise infrastructure service. Understanding how to add, verify, and manage those endpoints is essential for anyone moving beyond simple token transfers into serious development, testing, or high-volume trading workflows.

The process of adding a custom RPC endpoint in Rabby Wallet is straightforward for basic cases, but the implications are substantial. An incorrect endpoint URL, a node that is offline or misconfigured, or an RPC that does not implement the correct JSON-RPC specification can silently fail or produce misleading transaction simulations. Rabby’s transaction simulation feature, which displays potential risks and token changes before signing, depends entirely on the accuracy and reliability of the RPC endpoint backing that chain. A compromised or malicious RPC could theoretically serve incorrect data, though Rabby’s architecture keeps private keys locally encrypted and does not depend on server-side key storage for core security. The distinction between convenience and trust becomes sharper when the node is yours, because misconfiguration becomes your responsibility rather than a third party’s negligence.

Understanding RPC endpoints and why custom configuration matters

An RPC endpoint is a network address that implements the Ethereum JSON-RPC specification, allowing a wallet or application to query blockchain state, send transactions, and monitor events. Public endpoints operated by services like Infura, Alchemy, or QuickNode are convenient because they are managed, load-balanced, and maintained by companies with economic incentive to keep them running. That convenience comes with trade-offs: rate limiting, shared infrastructure vulnerability, and the fact that the endpoint operator can observe every request your wallet makes, including addresses you are checking, transaction patterns, and balances you hold.

A private RPC endpoint, by contrast, runs on infrastructure you control or trust. This might be a full Ethereum node on your local machine, a dedicated server in a data center, a testnet validator, or an endpoint leased from an enterprise RPC provider. The operational burden increases—node synchronization, storage, and maintenance require attention—but so does the control and privacy. For development teams, a private endpoint eliminates rate limits and allows for testing scenarios that public infrastructure would block. For organizations handling significant transaction volumes or sensitive operations, the reduced exposure of request metadata becomes material.

Rabby Wallet makes this flexibility practical by allowing users to add custom chains and endpoints without requiring a new wallet or complex configuration files. The wallet’s architecture stores chains and endpoints locally in the browser extension or mobile app, encrypted at rest, so adding a testnet or private network does not expose that configuration to third parties or centralize it on Rabby’s servers. When Rabby connects to an RPC, it is making standard JSON-RPC calls—getting the chain ID, fetching transaction histories, simulating contract interactions—and the reliability of those calls depends directly on the RPC’s availability and correctness.

Step-by-step: Adding a custom RPC endpoint in Rabby Wallet

The process begins in the wallet’s settings. Open Rabby Wallet, navigate to Settings, then select Networks. If you are setting up a new chain not listed in the default 141 supported networks, you will need to click “Add Custom Network.” For an existing supported chain where you want to switch the RPC endpoint, you can modify the default by selecting that chain and editing the RPC URL field. The distinction matters because modifying a known chain’s RPC only changes the endpoint, whereas adding a custom network requires entering the chain ID, network name, block explorer URL, and native currency details.

Begin with the RPC URL itself. This should be the full HTTP or HTTPS endpoint address—for example, http://localhost:8545 for a local Ethereum node, or https://your-testnet-rpc.example.com/v1/your-api-key for a managed service. Verify that the URL is correct, that the node is actually running and accepting connections, and that any authentication tokens or API keys are included if required. Do not use ws:// or wss:// WebSocket URLs in the standard RPC field; Rabby supports WebSocket connections in some configurations, but the primary field expects HTTP endpoints.

Next, provide the chain ID. This is a numeric identifier that must match the actual network your RPC is connected to. Ethereum mainnet is 1, Sepolia testnet is 11155111, Polygon is 137, Arbitrum is 42161, and so forth. If you are adding a private or custom network, the chain ID is whatever you configured when setting up that network. Entering an incorrect chain ID will cause Rabby to reject transactions or route them to the wrong network. You can verify the chain ID by making a simple RPC call to your endpoint: send a POST request with {“jsonrpc”: “2.0”, “method”: “eth_chainId”, “params”: [], “id”: 1}, and the response’s result field will contain the correct chain ID in hexadecimal format.

The network name is arbitrary but should be clear—”My Private Mainnet,” “Sepolia Testnet,” or “Enterprise Chain A.” This label appears in Rabby’s network selector and in transaction confirmations, so descriptive naming prevents mistakes like accidentally signing a transaction on the wrong network. The block explorer URL is optional but recommended; providing it allows Rabby to generate clickable links to transaction details, making it easier to verify what actually happened on-chain after signing. For a private network with no public explorer, you can leave this blank or provide an internal tool URL if one exists.

Verifying endpoint health and JSON-RPC compatibility

Adding the endpoint is not the same as validating it. Before relying on a custom RPC for real transactions, test its basic functionality. Within Rabby or using an external tool like curl, send a simple JSON-RPC query to confirm the node is responding and returns sensible data. The test_eth_chainId call, described above, is a read-only, low-cost way to verify connectivity. If the RPC responds with an error, responds too slowly, or does not respond at all, it will not work reliably in Rabby.

Next, verify that the RPC implements the methods Rabby actually needs. At minimum, the wallet requires eth_chainId, eth_blockNumber, eth_call, eth_sendRawTransaction, eth_getTransactionReceipt, eth_estimateGas, and several account-related methods like eth_getBalance and eth_getCode. Most Ethereum-compatible nodes implement these out of the box, but some pruned or specialized nodes, or certain testnet configurations, might disable some methods. If a required method is not available, Rabby will report an error when you try to use that network, rather than silently failing.

For transaction simulation—the feature that shows you what tokens will move and what risks a transaction carries—Rabby also uses eth_call with state override parameters, which is a more advanced RPC method. If your custom node does not support this, transaction previews may not appear, and you lose one of Rabby’s key safety features for that network. Verify this capability if you are relying on Rabby’s risk labeling and token change detection, especially when testing or executing complex contract interactions.

Rate limiting is another practical consideration. Even a private node can have internal rate limits, especially if it is shared across a team or accessed remotely. If Rabby makes many rapid requests—checking multiple token balances, simulating a transaction, fetching transaction history—and the RPC rate-limits aggressively, the wallet might appear to hang or report errors. For testnet or development use, this is usually acceptable and can be addressed by tuning the node’s RPC configuration. For production use with high transaction frequency, you may need to arrange higher rate limits or use a load-balanced setup with multiple RPC instances.

Enterprise and private network considerations

Organizations deploying a rabby wallet across a team often face questions about centralization and control. Rabby Wallet’s non-custodial design means each team member controls their own keys; the wallet does not hold funds on their behalf. However, pointing all team members at the same RPC endpoint creates a single point of failure and a centralized observation point. If the RPC is compromised, an attacker could serve incorrect transaction data, monitor all team activity, or blacklist addresses. For sensitive workflows, consider using multiple RPC endpoints, load-balancing, or a setup where developers and traders use different endpoints to reduce correlation.

Private Ethereum-compatible networks, such as those run on Quorum, Hyperledger Besu, or other enterprise implementations, can be added to Rabby as custom networks. The process is identical: provide the RPC endpoint, chain ID, network name, and optionally an explorer URL. One difference is that custom networks often run without public consensus or with different security models, so Rabby’s transaction simulation and risk detection will reflect the actual state of that private network, not mainnet behavior. This is usually correct, but teams should understand that Rabby’s scam filter and token detection are calibrated for public EVM networks; a private network’s contracts may not be recognized in the same way.

Testnet configuration is another common use case. Sepolia, Holesky, and other public testnets are already included in Rabby’s default network list, so you do not need to add them manually unless you want to use a custom RPC endpoint rather than Rabby’s default. However, if your organization runs a private testnet or a staging environment with an EVM-compatible chain, adding it as a custom network in Rabby allows developers and QA to test transactions locally without affecting public networks. This is especially useful for testing upgrade scenarios, contract migrations, or transaction patterns that should not touch mainnet.

Security implications of custom RPC endpoints

A custom RPC endpoint, by definition, is a point where you are trusting information about blockchain state. If the RPC lies, Rabby’s transaction simulation could show incorrect results. For example, a malicious RPC could report that a token balance is higher than it actually is, or that a smart contract call will succeed when it will actually fail. Since Rabby signs transactions locally and only uses the RPC for state queries and broadcasting, a bad RPC cannot directly steal keys or forge signatures. However, it can deceive the user into signing a transaction they did not intend.

The practical defense is to verify critical information against multiple independent sources. Before signing a large transaction, especially on a custom or private network, confirm the transaction details against a block explorer or a second RPC endpoint. Rabby’s address whitelisting feature helps prevent mistakes: you can mark addresses as trusted and receive warnings before sending to an unknown address, regardless of what the RPC reports about that address’s balance or history. These controls are most valuable when the RPC is under your control or operated by a trusted party, because they reduce the impact of misconfiguration or temporary inconsistencies.

For a private RPC that you are running, ensure the node itself is not compromised. A node running untrusted or modified Ethereum client software, or one that has been breached, could serve incorrect data. Use standard security practices: keep the node behind a firewall, restrict access to the RPC port, use TLS/HTTPS for any remote endpoints, and implement authentication (API keys) if multiple users access the same node. If the RPC is provided by a third party, verify their infrastructure claims and understand their security model before routing significant transaction volume through them.

Private keys in Rabby remain locally encrypted regardless of which RPC endpoint you use, so that layer of security is unaffected. Hardware wallet integration—supporting Ledger, Trezor, and OneKey devices—is also independent of the RPC endpoint. The RPC only sees the signed transaction after you have approved it; it cannot request or intercept the actual signing process. That architectural separation is essential: it means that Rabby Wallet’s core security model holds even if the RPC endpoint is untrusted or misconfigured, as long as you verify transaction details carefully before signing.

Troubleshooting common custom RPC issues

The most frequent problem is a typo or incorrect URL. Double-check the endpoint address, including the protocol (http vs. https), any ports, and any authentication tokens. If the RPC requires an API key or Bearer token, some services require including it in the URL itself (https://your-endpoint.com?apikey=abc123), while others require it in request headers. Rabby’s standard RPC field expects the full URL with any query parameters; if authentication is header-based, you may need to use a different approach or layer a proxy in front of the endpoint.

A second common issue is network connectivity. If the RPC is on a private network or behind a firewall, the machine running Rabby must be able to reach it. For local nodes on localhost:8545, verify that the node is running and accepting connections. For remote nodes, check that any VPN, firewall rules, or proxy configuration allows outbound connections to the RPC address and port. Some corporate networks block outbound RPC traffic; in those cases, you may need to tunnel through a proxy or use a managed RPC service instead.

Slow responses are often a sign that the RPC node is under high load or out of sync with the rest of the network. If you are running your own node, check its logs and system resources. If the RPC is provided externally, contact the provider to confirm its status. Temporarily slow responses may resolve on their own; consistently slow responses indicate a need to either optimize the RPC configuration or switch endpoints. Rabby will generally timeout and report an error after several seconds, rather than hanging indefinitely, but the user experience is degraded.

Finally, if Rabby reports that the chain ID does not match, you have likely provided an incorrect chain ID or the RPC is actually connected to a different chain than you intended. Verify the chain ID by making a direct JSON-RPC call to the endpoint, comparing it to the value you entered in Rabby, and update whichever one is wrong. This is a common mistake when switching between testnets or when different team members set up the same network with different chain IDs.

Best practices for managing multiple custom networks

As you add more custom networks—testnets, private chains, staging environments—Rabby’s network selector can become crowded. Organize them systematically: use consistent naming conventions (prefix with “Private” or “Testnet”), group them logically in your mind, and disable or remove networks you are no longer using. The wallet supports hiding networks you do not actively use, reducing clutter in the selector.

Maintain documentation of each custom RPC endpoint, its purpose, and any authentication details. This is especially important in a team environment, where multiple users might need to configure the same network. A shared document listing the chain ID, RPC URL, and any known quirks reduces the chance that someone will misconfigure a network and send funds to the wrong place. For sensitive networks, also document who is responsible for maintaining the RPC infrastructure and how to escalate issues if the endpoint becomes unreachable.

Periodically verify that custom RPC endpoints are still operational and in sync with the network they serve. A node that falls behind the network’s tip will return stale blockchain state, potentially deceiving Rabby about account balances or contract state. For private or testnet networks, this is less critical, but for any network carrying real transaction volume, ensure that the node is healthy before assuming that transaction simulations and balance queries are accurate.

When configuring Rabby Wallet on multiple devices or browsers, you will need to re-add custom networks on each one, since they are stored locally. This is by design—it keeps sensitive configuration local and avoids centralizing network topology information—but it requires manual setup. Automating this through configuration files or team-wide documentation can save time and reduce setup errors.

Advanced: Load balancing and failover strategies

For teams where Rabby Wallet is part of a production or semi-production workflow, a single custom RPC endpoint becomes a single point of failure. If that RPC goes down, all transactions are blocked until it comes back online. For critical operations, consider running multiple RPC nodes and using a load balancer or failover proxy in front of them. Rabby does not natively support configuring multiple RPC endpoints with automatic failover, but you can achieve this at the infrastructure level: set up a reverse proxy that distributes requests across multiple nodes, monitors their health, and removes unhealthy nodes from rotation.

Another approach is to use a managed RPC service that offers redundancy. Services like Alchemy, Infura, or Quicknode operate multiple nodes and handle failover internally; you pay for the convenience and reliability, accepting the trade-off that these services can observe your traffic. For some organizations, that trade-off is acceptable given the operational burden of running private infrastructure.

For testnet and development use, resilience is less critical, and a single private RPC is often sufficient. The focus should be on correctness and compatibility rather than availability. Ensure the testnet RPC is running the correct client version and network configuration, and use it consistently so that developers are testing against the same environment.