Rabby Wallet Extension: Network Customization, RPC Configuration, and Adding Testnets for Development

Smart contract developers testing on Sepolia, Goerli, or other testnets need reliable tooling for transaction simulation, account management, and network switching. A browser-based wallet that supports multiple EVM chains natively reduces friction compared to managing separate tools or relying on less transparent node providers. Rabby wallet extension addresses this directly: it allows developers to add custom RPC endpoints, configure testnets alongside mainnet networks, and preview transactions before signing—essential capabilities when working with deployments that could fail, consume unexpected gas, or interact with contracts in ways that differ from intention.

The core developer workflow involves creating multiple accounts across different networks, testing contract interactions before mainnet deployment, and needing confidence that transaction parameters are correctly configured. A self-custodial blockchain wallet puts that control in the developer’s hands while introducing the responsibility of securing private keys and recovery phrases across testing and production contexts. Understanding how to configure Rabby properly—setting up custom RPCs, organizing test networks, and interpreting transaction previews—can significantly reduce deployment mistakes and provide clearer visibility into smart contract behavior before it matters.

Why testnet configuration matters for smart contract development

Deploying a contract to mainnet without testing against realistic transaction flows introduces compounded risk. A contract may execute correctly in isolated unit tests but fail when interacting with oracle services, liquidity pools, or other contracts under actual network conditions. Testnets such as Sepolia and Goerli allow developers to run full integration tests, debug failing transactions, and verify gas consumption patterns in an environment where mistakes do not cost real funds.

The traditional approach requires switching between a mainnet wallet for production work and separate test accounts, often managed through command-line tools or services that do not provide transaction previews. This fragmentation creates opportunities for error: accidentally connecting to the wrong network, forgetting which recovery phrase belongs to which context, or approving a transaction without understanding its actual impact on deployed contracts. An EVM wallet designed for multiple networks can consolidate that workflow while maintaining clear separation between test and production accounts.

Rabby wallet extension supports this pattern through its network-switching interface and custom RPC configuration. A developer can maintain a separate test account imported specifically for contract interaction, configure it against Sepolia or Goerli with a dedicated RPC endpoint, and use transaction simulation to verify behavior before signing. The human-readable transaction preview feature becomes particularly valuable when testing interactions with contracts that emit complex events, perform conditional logic, or modify state in non-obvious sequences.

Adding and configuring custom RPC endpoints

By default, Rabby provides public RPC endpoints for major EVM networks, but production testing often benefits from dedicated endpoints. Services such as Alchemy, Infura, QuickNode, or Ankr offer rate-limited free tiers and paid plans with higher reliability, faster response times, and better debugging information. Configuring a custom RPC involves obtaining an endpoint URL, entering it into the wallet’s network settings, and verifying that the connection works by checking the network status or attempting a test transaction.

To add a custom RPC in the rabby wallet extension, navigate to the network settings panel, select “Add Network,” and enter the required details: network name, RPC URL, chain ID, currency symbol, and block explorer URL. The chain ID must match the actual network—Sepolia is 11155111, for example—while the RPC URL should include any API key or authentication token required by your provider. Block explorer URLs enable Rabby to provide direct links to transaction details, making it easier to verify behavior on services such as Etherscan or network-specific explorers.

A best practice is to test the connection immediately after configuration. Send a small transaction or check the account balance to confirm that the RPC responds and that the chain ID is correctly recognized. If connection fails, verify that the endpoint URL is correct, that no firewall rules are blocking access, and that the API key has not reached its rate limit. Some providers require whitelisting of wallet addresses; if that applies, add Rabby’s extension ID or your testing wallet address to the provider’s dashboard before proceeding.

Keep in mind that public endpoints can become congested or rate-limited during high-activity periods. If transactions consistently fail with timeout errors or “too many requests” responses, switching to a more reliable endpoint or upgrading to a paid tier may be necessary. For local development, running your own node—such as Geth for Ethereum or compatible implementations for other networks—provides the most control and eliminates dependency on third-party providers.

Setting up Sepolia and Goerli testnets in Rabby

Sepolia and Goerli are the two primary long-lived testnets for Ethereum development. Goerli has been around longer and has more historical data, but Sepolia is now the recommended testnet for new projects and is more closely aligned with Ethereum’s current roadmap. Both testnets require test ETH to pay for transactions; faucets distributed by the Ethereum Foundation, Alchemy, and other services provide free test tokens on a regular or request-based schedule.

To add Sepolia to the rabby wallet extension, use the network details: name “Sepolia,” RPC URL from your provider (e.g., `https://sepolia.infura.io/v3/YOUR_API_KEY`), chain ID 11155111, currency symbol ETH, and a block explorer URL such as `https://sepolia.etherscan.io`. After adding the network, switch to it from the network selector, and your account balances will display in Sepolia context. Obtain test ETH from a faucet, then verify that the transaction appears in your wallet and on the block explorer.

Goerli configuration follows the same pattern, with chain ID 5 and the RPC URL pointing to a Goerli endpoint. The block explorer is `https://goerli.etherscan.io`. Because Goerli is older and no longer receiving consensus layer updates, Sepolia is generally preferable for new development work. However, some projects and test data may still be primarily on Goerli, so maintaining both networks in Rabby can be practical for developers working across multiple projects.

Once testnets are configured, you can import a dedicated test account by creating a new account or importing a recovery phrase used only for development. This separation prevents accidental mixing of development wallets with production accounts. Use the same test account across multiple networks by switching between Sepolia, Goerli, and mainnet in the network selector; Rabby will display the account’s balance on each network separately.

Transaction simulation and human-readable previews

The distinction between an unsigned transaction preview and actual on-chain behavior is critical when testing contracts. A preview shows what the wallet interprets the transaction to be—the recipient, amount, function call, and state changes—but does not guarantee that the transaction will succeed once broadcast. The preview relies on simulating the transaction against the current network state, which can change between preview time and actual execution if other transactions affect relevant contracts or balances.

Rabby’s transaction simulation feature decodes contract function calls into human-readable format, showing which function is being called and what parameters are being passed. For an ERC-20 transfer, the preview displays the recipient address, token symbol, and amount rather than raw encoded data. For more complex interactions—such as calling a Uniswap router or providing liquidity to a protocol—the preview breaks down the action into its components, making it easier to spot errors before signing.

When testing a smart contract with Rabby, review the transaction preview carefully before approving. Look for unexpected recipients, gas limits that seem unusually high, state changes to contracts you did not intend to modify, or token approvals that grant excessive allowances. If the preview shows blank or encoded fields, the function may not be standard or the block explorer may not have contract ABI information available. In that case, manually verify the function signature and parameters by consulting the contract source code or deployment documentation.

One limitation of transaction simulation is that it runs against a snapshot of the network state at the time of preview. If you wait several minutes between previewing and signing a transaction—particularly during volatile market conditions or when the contract is part of a multi-step process—the actual execution may produce different results due to state changes. This is not a flaw in Rabby itself but a fundamental property of blockchain execution. For critical transactions, previewing immediately before signing reduces this risk.

Organizing multiple accounts and avoiding confusion

A developer testing smart contracts often maintains separate accounts for different purposes: one for mainnet interaction, one for Sepolia testing, one for local node testing, and possibly one for contract deployment operations. Without careful organization, mistakes become likely. Accidentally using a mainnet account when connected to Sepolia, or vice versa, can send test ETH to a real address or attempt to deploy to the wrong network.

Rabby allows creating multiple accounts within a single wallet, each with its own private key derived from the recovery phrase using a different derivation path. You can label each account clearly—for example, “Mainnet Prod,” “Sepolia Dev,” “Local Testing”—to make the distinction obvious when switching. Some developers prefer importing completely separate recovery phrases for test and production contexts, which provides stronger isolation but requires managing multiple backup documents.

Before performing any significant transaction, verify three things: the correct account is selected (shown in the top of the wallet interface), the correct network is selected (clearly labeled in the network dropdown), and the transaction preview matches your intention. These simple checks take seconds but prevent the class of errors that cannot be recovered once the transaction is broadcast. If you find yourself uncertain, pause, close the transaction, and review the contract interaction or documentation again.

For developers working with multiple test networks beyond Sepolia and Goerli—such as Arbitrum Sepolia, Optimism Sepolia, Polygon Mumbai, or custom networks—the same configuration process applies. Each network requires its own RPC endpoint and chain ID. Documenting your network configuration alongside your development documentation helps teammates and future versions of yourself quickly recreate the setup.

RPC reliability and failover considerations

A public or third-party RPC endpoint can become unavailable, rate-limited, or slow to respond. When this happens during contract testing, you may receive errors such as “network request failed,” “too many requests,” or timeouts. The issue is not necessarily with your contract code but with the RPC provider’s availability. To diagnose this, check the provider’s status page, attempt the transaction from a different tool or environment, and try an alternative RPC endpoint if available.

For production testing or time-sensitive contract verification, running a personal node eliminates dependency on third-party providers. Ethereum Beacon chain clients such as Lighthouse or Prysm, combined with execution clients such as Geth, allow you to run a full node locally. Configuration is more complex than using a public endpoint, but you gain complete control, no rate limits, and faster response times. Rabby can connect to a local node by using `http://localhost:8545` as the RPC URL (or the appropriate port if configured differently).

If you choose to use public endpoints, consider implementing simple redundancy: document multiple providers for the same testnet and switch providers if one becomes unreliable. Some services such as Ankr allow configuring multiple endpoints and will automatically retry against alternative providers if the primary fails. This adds complexity but can make development smoother when testing across many transactions or working in an environment with intermittent connectivity.

Importing contract ABIs and improving transaction visibility

When you deploy a contract, Rabby initially has no knowledge of its functions or parameters. Transaction previews will show the encoded data rather than human-readable function names and arguments. To improve visibility, you can provide the contract’s ABI (Application Binary Interface) to the wallet through the block explorer. Most explorers, such as Etherscan or network-specific equivalents, allow uploading or verifying a contract’s ABI when you publish the source code.

Once a contract is verified on an explorer with its ABI, Rabby automatically fetches that ABI and uses it to decode future transactions to that contract. This means when you call a function on your verified contract, the transaction preview will display the function name and parameters clearly instead of raw encoded bytes. For development work, verifying even test deployments on Sepolia Etherscan or similar explorers makes debugging significantly easier.

If you are working with a contract that is not yet verified, you can manually provide the ABI to Rabby through supported integrations or by using more advanced tools such as Tenderly for simulation and debugging. Tenderly allows uploading contract code, simulating transactions with detailed state inspection, and comparing actual execution behavior against expectations. This is particularly valuable when troubleshooting complex multi-step transactions or contracts with non-obvious state changes.

Security considerations for development wallets

A wallet used for smart contract testing still holds private keys and can sign transactions. Even though test networks do not cost real money, the principles of key security remain important. Never share your recovery phrase with anyone, do not store it in cloud documents or email, and do not use the same recovery phrase for both testing and production accounts. If a test account’s recovery phrase is accidentally exposed, rotate the account and create a new one rather than continuing to use potentially compromised credentials.

Some developers create test wallets through online tools or less secure methods because “it is only for testing.” This creates bad habits and introduces unnecessary risk. Use the same security practices for test accounts as you would for production: create the wallet through Rabby itself, securely back up the recovery phrase offline, verify the backup by attempting to restore it on a test browser before relying on it, and keep the phrase completely separate from your regular computer or devices.

When you need to obtain test ETH from a faucet, research the faucet’s legitimacy before connecting your wallet. Malicious faucets can simulate transaction previews and trick users into approving transactions that drain real tokens or grant unlimited approvals to contracts. The risk is small but real, so verify that you are using official faucets recommended by the Ethereum Foundation, the test network’s documentation, or your RPC provider.

Once you have finished testing and no longer need a test account, you can delete it from Rabby or simply not import it on your production environment. The recovery phrase still grants access, so if you ever reactivated the account or used it elsewhere, ensure the phrase is no longer accessible. Treat abandoned test wallets the same way you would treat retired production accounts: secure the recovery phrase or destroy it clearly rather than leaving it in plain sight.