A developer working with a private Solana validator or an Ethereum-compatible sidechain can set up Phantom to connect to a custom RPC endpoint—a remote procedure call server that broadcasts transactions and retrieves blockchain state without relying on public endpoints. Yet after adding the network and attempting the first transaction, the wallet reports a connection error, times out, or silently fails to broadcast. The symptom appears identical whether the issue lies in the wallet’s request format, the RPC server’s configuration, network filtering, or a mismatch between the wallet’s expectations and what the endpoint actually supports.

This problem is common enough to affect production deployments, yet the root causes remain opaque to users because the phantom wallet extension gives few clues beyond “Failed to send transaction” or “Network request timeout.” Understanding the mechanics of how Phantom constructs RPC calls, validates responses, and handles errors can narrow the diagnosis from “something is broken” to a specific misconfiguration. That distinction is critical for developers running validators, operators managing internal blockchain infrastructure, and power users needing to route transactions through privacy layers or non-standard networks.

How the Phantom wallet extension communicates with RPC endpoints

The phantom wallet extension is a browser application that runs in a sandboxed JavaScript environment. When a user approves a transaction or requests account data, the wallet constructs a JSON-RPC 2.0 request and sends it to the configured endpoint via HTTPS POST. The endpoint receives the request, executes the specified method (such as sendTransaction, getBalance, or getLatestBlockhash), and returns a response. This exchange happens invisibly to the user; all they see is a delay and then either a transaction signature or an error message.

The crucial detail is that not all RPC servers implement the same methods or return responses in the format Phantom expects. Ethereum Foundation documentation describes the Ethereum JSON-RPC specification, which defines standard method signatures and response structures for Ethereum-compatible chains. Solana has its own RPC API specification. Polygon, Base, and other layer-2 solutions extend Ethereum’s specification but may add network-specific methods or rate-limit requests differently. When a custom RPC endpoint does not fully implement the expected specification, Phantom’s request may succeed at the network level but fail when the wallet tries to parse or validate the response.

A second layer of complexity involves CORS (Cross-Origin Resource Sharing) headers. The phantom wallet extension runs in a browser, which enforces strict cross-origin policies. When the wallet’s JavaScript makes an HTTP request to an RPC endpoint on a different domain, the endpoint must include CORS headers that explicitly permit requests from the wallet’s origin (the browser extension itself). If those headers are missing or misconfigured, the browser’s security model blocks the response, and the wallet receives an opaque error message that often hides the real problem: the RPC server rejected the request before it even reached the application layer.

Understanding this two-stage failure mode—network-level CORS rejection versus application-level method mismatch—is the first step in systematic troubleshooting. Both produce symptoms that look like “the connection failed,” but the fixes are completely different. A CORS problem requires server configuration changes, while a method mismatch may require choosing a different endpoint or accepting that the wallet cannot use that particular network.

Why connection timeouts occur and how they differ from outright failures

A timeout is not the same as a refused connection. If Phantom never reaches the endpoint, the browser usually returns an error within seconds. A timeout occurs when the wallet sends a request and then waits—sometimes indefinitely—for a response that never arrives. This can happen because the endpoint is overloaded, because the network path is slow or unreliable, or because the endpoint’s reverse proxy or load balancer is dropping requests without responding.

The phantom wallet extension does not expose timeout configuration to users, so the waiting period is built into the wallet itself. Different Phantom versions may have different default timeout values, typically ranging from 30 to 60 seconds. During that wait, the wallet’s UI often stays frozen or shows a “connecting” state. If the user becomes impatient and closes the wallet or navigates away, the request is abandoned, and the transaction is never broadcast.

Power users sometimes interpret a persistent timeout as a sign that the endpoint is offline. In reality, the endpoint may be online but not reachable from the wallet’s network location. A corporate firewall, a geo-blocking rule on the RPC provider’s edge network, or an intermediate proxy server can all cause requests to hang mid-flight. Testing whether the endpoint is reachable requires a tool outside the wallet: `curl`, Postman, or a command-line JSON-RPC client. If those tools can reach the endpoint and receive responses, but Phantom times out, the problem is not the endpoint itself but how the wallet reaches it.

In some cases, timeout behavior has changed across Phantom versions. Older releases might fail quickly and clearly; newer ones might be more tolerant of slow endpoints. If you are running an older version of the phantom wallet extension, upgrading to the latest build can sometimes resolve timeouts caused by stricter request handling or improved error reporting in newer code.

Common misconfigurations when adding a custom RPC network

Adding a custom network to Phantom requires entering the RPC URL, a chain ID, and often a network name and currency symbol. Each of these fields has specific formatting requirements, and a small mistake in any one of them can cause the wallet to reject the endpoint or misinterpret responses.

Chain ID mismatches are among the most common culprits. Every blockchain has a numeric chain identifier used to prevent transaction replay attacks across networks. If you configure Phantom with a chain ID that does not match what the RPC endpoint actually serves, the endpoint may reject transactions as invalid, or the wallet may sign transactions intended for one network and broadcast them to another. For Ethereum, the chain ID is 1; for Ethereum Sepolia testnet, it is 11155111. Base Layer 2 documentation specifies that the chain ID is 8453. Polygon’s mainnet uses chain ID 137. Entering the wrong number is easy and has severe consequences. Always verify the exact chain ID from the network’s official documentation before adding it to Phantom.

RPC URL formatting matters as well. The URL must be a complete HTTP or HTTPS endpoint, not a hostname or IP address alone. If the endpoint requires an authentication key, it should be included in the URL (for example, `https://rpc.example.com/?key=YOUR_API_KEY`). Some RPC providers embed the key in a subdomain instead (`https://key.rpc.example.com`). The phantom wallet extension will not guess the correct format; if you provide a malformed URL, the wallet may appear to add the network successfully but fail when trying to connect. Test the URL directly using `curl` before adding it to Phantom: curl -X POST https://your-rpc-url -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'. If the endpoint responds with a valid JSON-RPC result, the URL is correctly formatted and reachable from your machine.

HTTP versus HTTPS deserves special mention. Some RPC providers offer both; some offer only one. The phantom wallet extension running in a modern browser can only connect to HTTPS endpoints if the wallet itself is served over HTTPS (which it is, because it is a published browser extension). If you try to connect to an HTTP endpoint from an HTTPS context, the browser blocks the request for security reasons. This is a browser feature, not a Phantom bug. If an RPC provider offers only HTTP, you cannot use it directly with the Phantom browser extension; you would need to proxy the connection through an HTTPS server under your control.

CORS configuration and server-side requirements

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that prevents malicious websites from making requests to your bank, email, or other sensitive services on your behalf. When a JavaScript application in a browser makes a request to a different domain, the browser sends a “preflight” OPTIONS request asking the server for permission. The server must respond with specific headers indicating which origins (websites or browser extensions) are allowed to make requests.

For the phantom wallet extension to communicate with a custom RPC endpoint, the server must include the header Access-Control-Allow-Origin: chrome-extension://* or, more permissively, Access-Control-Allow-Origin: *. Many RPC providers restrict CORS for security or traffic-shaping reasons. If you are running your own endpoint, you must explicitly allow requests from the Phantom extension’s origin.

Configuring CORS correctly depends on your RPC server software. For a Geth node (Ethereum-compatible), this might involve setting the `–http.corsdomain` flag. For Solana, the Solana RPC server binary accepts `–rpc-cors` parameters. If you are running an RPC server behind a reverse proxy such as Nginx or Apache, you must configure CORS at the proxy level, not only at the application level. A proxy without proper CORS headers will block Phantom’s requests even if the underlying RPC server is configured correctly.

If you add a custom network to Phantom and the wallet appears to hang or report a CORS error (sometimes shown in the browser’s console rather than in the wallet’s UI), the server’s CORS headers are likely misconfigured. Open the browser’s developer tools (F12 in most browsers), navigate to the Console tab, and attempt a transaction. You will often see an error message such as “No ‘Access-Control-Allow-Origin’ header is present on the requested resource.” That message confirms a server-side CORS problem and points you toward the solution: adjust the server’s configuration, not Phantom.

Validating network parameters and RPC method support

Even after CORS and URL format are correct, a custom RPC endpoint may not support every method that Phantom expects. The wallet relies on specific JSON-RPC methods to retrieve balances, transaction histories, and network parameters. If an endpoint supports only a subset of those methods, Phantom’s requests for unsupported operations will fail.

Start by confirming that the endpoint implements the basic methods required for wallet operation. For Ethereum-compatible networks, these include eth_chainId, eth_getBalance, eth_getTransactionCount, and eth_sendRawTransaction. For Solana, equivalents include getBalance, sendTransaction, and getRecentBlockhash. You can test these manually using curl or Postman. For example, to check if an Ethereum endpoint supports eth_chainId:

curl -X POST https://your-rpc-endpoint -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

A successful response will be something like {"jsonrpc":"2.0","result":"0x1","id":1} (where “0x1” is the hex-encoded chain ID 1). If the endpoint returns an error such as {"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found"},"id":1}, the endpoint does not support that method, and it may not be suitable for use with Phantom. Some reduced endpoints designed for specific use cases (such as archival or indexing-only nodes) intentionally disable certain methods. If you are integrating with such an endpoint, you may need to add it as a network in Phantom but understand that certain features (like balance checking or transaction broadcasting) may not work.

You can also consult the official Phantom documentation or use a service such as phantom wallet extension to review the specific methods required for each supported network and verify that your chosen endpoint implements them all. Some community-run or low-cost RPC providers intentionally limit functionality to reduce resource consumption; if you encounter repeated failures on a particular endpoint, switching to a major provider (Infura, Alchemy, QuickNode) often resolves the issue.

Network-level connectivity and firewalls

Not all connection failures are caused by misconfiguration. Network topology, firewalls, and intermediate proxies can block legitimate requests. If you are behind a corporate firewall, your company’s proxy may filter requests to external RPC endpoints. Some organizations block all cryptocurrency-related traffic as a policy matter. If you are connecting from a country with strict internet controls, certain RPC providers may be unavailable or heavily rate-limited.

Testing connectivity to an RPC endpoint from the same network as your browser can help isolate whether the problem is firewall-related. If you can reach the endpoint using `curl` from your machine but the phantom wallet extension cannot, the firewall may be inspecting encrypted traffic or applying additional rules to browser requests. In such cases, you might need to configure your firewall rules to allow HTTPS traffic to the specific RPC endpoint, or you might need to use a VPN or proxy service that can bypass the restrictions.

If you are a developer running a private RPC endpoint and want to connect to it using Phantom, ensure that the endpoint is accessible from the network where Phantom runs. If Phantom runs in a browser on a home computer and the endpoint is on a private company network without a public IP, they cannot communicate directly. You would need to expose the endpoint through a reverse proxy, VPN tunnel, or other network bridge. This is not a Phantom issue but a fundamental constraint of network connectivity that Phantom cannot bypass.

Troubleshooting specific error messages

Different error messages point toward different root causes. “Network request timeout” usually indicates that the endpoint exists but is slow or overloaded. Try again after a few minutes, or add a different endpoint for the same network to distribute load. “Failed to send transaction” is generic and could mean the endpoint rejected the transaction, the network is congested, or the wallet did not construct a valid transaction in the first place. Checking the transaction’s structure and gas parameters (if applicable) can help narrow this down.

“Invalid chain ID” or similar errors indicate a mismatch between the chain ID configured in Phantom and the actual chain ID served by the endpoint. Double-check the configured value. “Method not found” means the endpoint does not support a particular JSON-RPC method that Phantom is trying to use. Check whether your endpoint supports the required methods or whether you need to use a different provider.

Some endpoints also return HTTP status codes that differ from the typical success (200) or authentication failure (401) codes. A 429 status code indicates rate limiting; if you see this repeatedly, you may need to upgrade your account with the RPC provider, wait longer between requests, or switch to an endpoint with higher rate limits. A 502 or 503 status code indicates the server is temporarily unavailable. These errors are temporary and usually resolve within minutes.

The phantom wallet extension itself rarely logs detailed error information to the browser console, so you may need to inspect network traffic using your browser’s Network tab to see exactly what the endpoint returned. Right-click on a failed transaction attempt, select “Inspect,” navigate to the Network tab, and look for requests to your RPC endpoint. The response body often contains more specific error messages than what Phantom displays to the user.

Hardware wallet integration and custom networks

Users connecting a hardware wallet such as Ledger hardware wallets to Phantom should be aware that custom RPC endpoints do not change the security of the hardware-signed transaction itself. The hardware wallet signs the transaction locally, and Phantom broadcasts the signed transaction to the RPC endpoint. However, the endpoint can still cause failures if it does not support the method for broadcasting or if it modifies the transaction before broadcasting.

Test a hardware-wallet-based custom network carefully with a small amount before moving significant funds. The combination of a custom RPC endpoint and a hardware wallet introduces more points of failure than a simple software wallet and a public endpoint. If something goes wrong, the transaction may already be signed and broadcast before you can cancel it.

Prevention and best practices going forward

For reliability, use well-known RPC providers unless you have a specific reason to run a custom endpoint. Phantom is optimized for public providers, which are battle-tested and widely used. If you must use a custom endpoint, test it thoroughly outside of Phantom first using command-line tools, ensure that CORS headers are correct, verify the chain ID and URL format, and confirm that all necessary JSON-RPC methods are supported. Add the endpoint to Phantom with a small test balance, perform a test transaction, and only scale up to larger amounts after confirming that everything works.

Keep Phantom updated. Bug fixes and improvements to RPC handling are regularly released in new versions. If you have been running an old version and encounter persistent connection issues, updating the phantom wallet extension may resolve them. Enable security features like hardware wallet integration if you are managing substantial assets, and never disable wallet security features to work around connection issues—the real solution is fixing the network configuration, not weakening security.

Document your custom network configuration, including the RPC URL, chain ID, and any special authentication requirements. This helps you troubleshoot later and makes it easier to reproduce the setup on another device. If you are a developer deploying applications on custom networks, test against Phantom early in your development cycle to identify incompatibilities before users encounter them in production.