RPC endpoints and nodes

02 September 2026

Every interaction you have with a blockchain - sending a transaction, checking a balance, querying past events - goes through an RPC endpoint. It's the doorway. If that door is slow, broken, or lying to you, nothing else works. This page maps the entire subject: what RPCs are, why they fail in practice, when to run your own node, and which tools, costs, and risks matter for each decision.

What an RPC endpoint actually does

An RPC (Remote Procedure Call) endpoint is a URL where your wallet or dapp sends JSON-formatted requests and receives JSON responses. Under the hood, what is an RPC endpoint and how does it work is a client-server protocol: your software constructs a JSON-RPC payload (method name plus parameters), sends it over HTTP or WebSocket to a node, and the node replies with the result or an error object. The node itself is running an execution client (like Geth or Nethermind) paired with a consensus client (like Prysm or Lighthouse), and together they maintain the blockchain state.

When your wallet says "send 0.1 ETH," it does not magically appear on-chain. The wallet builds a signed transaction, calls eth_sendRawTransaction on the RPC endpoint, and the node broadcasts it to the network. When a dapp displays your balance, it called eth_getBalance. The endpoint is the translator between your application and the blockchain's peer-to-peer network.

Why your RPC endpoint is failing

Errors from RPC endpoints fall into predictable categories. The most common ones have dedicated fixes.

Transaction Submission Errors

"nonce too low" appears when you send a transaction with a nonce that has already been used or is below the current account nonce. This happens most often when you have multiple pending transactions, or when a dapp or wallet cached an old nonce. The full walkthrough is in how to fix nonce too low error on Ethereum RPC.

"insufficient funds for gas * price + value" is not always what it seems. You might have enough ETH in total but not enough after accounting for the gas cost of the transaction itself. The error also appears when you have tokens but no ETH to pay gas, or when the base fee has spiked since you estimated. Step-by-step resolution is in how to fix insufficient funds for gas error on Ethereum.

"execution reverted" with no reason string is the most frustrating error. Your transaction was valid enough to run, but the contract logic rejected it - could be a failed require, a violated invariant, or an overflow. Without a reason string, you need to simulate the call and decode the revert data. That is exactly what how to debug execution reverted error on Ethereum RPC covers: using eth_call with a trace, or tools like Tenderly and Foundry's cast run.

"replacement transaction underpriced" and "transaction underpriced" mean you tried to replace a pending transaction with a new one that has a lower gas price or insufficient tip increase. The replacement must have at least 10% higher gas price (or tip, post-EIP-1559) than the original.

Connection and rate limit errors

"429 Too Many Requests" tells you your application hit the provider's rate limit. This is the most common production failure during NFT mints, token launches, or any high-frequency polling. How to fix 429 Too Many Requests on RPC endpoints explains the strategies: switching to WebSocket subscriptions instead of polling, increasing compute unit budgets on paid plans, distributing load across multiple endpoints, and implementing client-side backoff.

"403 Forbidden" or "project ID is required" (the Infura 401) indicates an authentication or allowlist rejection. Your API key might be invalid, your IP might not be allowlisted, or the request origin might be blocked by CORS policies. How to fix 403 Forbidden error on RPC endpoint walks through each cause and its fix.

"method not found" happens when you call a method the endpoint does not support. Execution client differences matter here: Geth implements nearly everything, while some Nethermind or Erigon configurations omit methods like debug_traceTransaction for performance reasons. Light clients do not support eth_sendTransaction (only eth_sendRawTransaction). How to fix method not found error on Ethereum RPC explains which methods are standard, which are client-specific, and how to test with curl or Postman.

Data Query Errors

"query returned more than 10000 results" from eth_getLogs is a hard limit enforced by most providers to prevent archive-level queries from consuming too many resources. How to fix eth_getLogs query returned more than 10000 results shows how to paginate by block range, use the toBlock and fromBlock parameters, and batch queries across smaller intervals.

"state is not available at the requested block" appears when a full node pruned the state for older blocks. Full nodes only keep recent state - the last 128 blocks for default Geth configurations, though this is configurable. Archive nodes keep all state. The distinction is covered in full node vs archive node what is the difference.

"eth_getBalance returns the balance including pending transactions" is a common misconception. It does not. eth_getBalance returns the balance at a specific block, or at the latest block if you don't specify. Pending transactions that have not been mined are not reflected unless you explicitly use "pending" as the block parameter. This nuance is explained in the spoke on how eth_call and gas estimation work on Ethereum RPC.

Choosing between providers and self-hosting

The single biggest decision you will make about RPC access is whether to use a third-party provider or run your own node.

RPC Provider Options

Infura and Alchemy are the two dominant providers. Both offer free tiers with daily request caps (around 100,000 requests per day for Infura's free tier, Alchemy's is CU-based and roughly equivalent for simple queries). Both have paid tiers that scale to hundreds of millions of requests per month. The differences are in compute unit pricing, archive data support, WebSocket reliability, and tooling. Infura vs Alchemy which RPC provider is better does a detailed comparison across these dimensions.

QuickNode, Chainstack, Ankr, Blast API, and Blockdaemon are alternatives with different pricing models. QuickNode offers dedicated endpoints with predictable pricing. Chainstack specializes in enterprise-grade multi-cloud deployment. Ankr provides a decentralized node network alongside centralized options. Pocket Network and Lava Network are decentralized alternatives where you pay in tokens for relay volume. Each has tradeoffs around latency, reliability, and support.

The choice between public vs private RPC endpoint which one for your dapp depends on your traffic patterns. Shared public endpoints (like the free Infura tier or public ankr endpoints) are fine for development and low-traffic apps. Private dedicated endpoints are necessary for production dapps with consistent traffic, because shared endpoints are subject to rate limits that other users' traffic can exhaust.

When to run your own node

Running your own Ethereum node eliminates reliance on any third party. You control the data, there are no rate limits, no API keys to leak, and no provider that can censor your transactions. But the costs and operational burden are significant.

A Geth full node requires roughly 1-2 TB of SSD storage, 8-16 GB of RAM, and a solid internet connection. Initial syncing via snap sync takes 8-24 hours. Archive nodes require 12+ TB of SSD and weeks of syncing. The monthly cost for a cloud VM with those specs (DigitalOcean, AWS, Hetzner) runs $50-200/month, not counting egress bandwidth. Running it at home means bearing your own electricity and bandwidth costs, plus dealing with uptime.

Should you run your own Ethereum node or use an RPC provider breaks down the total cost of ownership: the $50-200/month for a cloud node versus the $0 (with rate limits) to $50-500/month for provider plans. The break-even point lands around 5-10 million requests per month, after which a self-hosted node becomes cheaper - but only if you factor in your own time for maintenance, monitoring, and troubleshooting.

Execution and consensus client choices

If you do run a node, you must choose an execution client (Geth, Nethermind, Erigon, Reth, Besu) and a consensus client (Prysm, Lighthouse, Teku, Nimbus). The execution client handles the EVM and state, the consensus client handles the consensus chain and finality.

Geth is the most widely used, best tested, and most compatible execution client. It is the safe choice. Nethermind is written in C#, has strong archive node performance, and good tooling. Erigon focuses on efficiency: it syncs faster, uses less disk space per block, and has excellent archive node support. Reth is a newer Rust-based client that aims to be the fastest for syncing and execution. Geth vs Erigon which Ethereum execution client to run compares sync times, disk usage, and method support across these clients.

The choice matters because different execution clients support different RPC methods. Erigon enables trace_ and debug_ APIs by default with lower performance overhead than Geth. Nethermind has its own implementation of eth_getLogs that can be faster on archive nodes. Geth is the most likely to have every standard method implemented and working.

Transport: HTTP vs websocket

Your RPC endpoint can be HTTP or WebSocket. HTTP is simpler, stateless, and works everywhere. WebSocket supports subscriptions via eth_subscribe, which lets you receive new block headers, pending transactions, and log events as they happen without polling.

HTTP vs WebSocket RPC which transport should you use addresses the real tradeoffs. WebSocket is not inherently faster than HTTP for individual requests - the latency difference is negligible. The advantage of WebSocket is for real-time data: if you need to react to new blocks or pending transactions within seconds, WebSocket subscriptions are the efficient choice. For everything else - balance checks, transaction sending, contract reads - HTTP is simpler and more reliable. WebSocket connections can drop, require reconnection logic, and are harder to load-balance.

Security risks you must know

Using a third-party RPC endpoint means trusting that provider with your transaction data. That has concrete risks.

Leaking your private key via eth_sendTransaction is the most dangerous. Some wallets and dapps send raw signed transactions (safe) but some use eth_sendTransaction which requires the node to hold your key. If you use eth_sendTransaction on an untrusted endpoint, the provider can steal your funds. Always use eth_sendRawTransaction where you sign locally.

RPC provider logging and storing transaction metadata means the provider sees every transaction you send, every contract you call, every balance you check. They know your IP address, your wallet addresses, and your usage patterns. This is not a hypothetical - some providers have publicly stated they log transaction data for analytics.

MEV extraction by node operators is real. If you send a transaction through a provider that runs its own validators, they can frontrun or sandwich your transactions. This is more common with smaller providers and less common with Infura and Alchemy, but it is a risk.

RPC endpoint returning falsified chain data is possible if the provider serves you data from a forked or unsynced node. This happened in practice with some defunct providers. Always verify against multiple sources for critical operations.

RPC endpoint security risks you need to know covers all of these in detail, including how to mitigate them: using separate endpoints for different chains, encrypting API keys, running your own node for sensitive operations, and using decentralized RPC networks that provide cryptographic verification.

Putting it all together: A practical decision tree

Here is how the pieces fit together for a typical project:

1. Start with a free tier provider (Infura or Alchemy) for development and low-traffic MVP testing. Use Chainlist to verify the RPC URL is correct - but be aware that is Chainlist safe for finding RPC endpoints has a critical discussion about the risks of trusting unverified community-sourced URLs.

2. When you hit rate limits (429 errors), either upgrade to a paid tier or implement how to set up multi-provider RPC failover for Ethereum - a configuration where your dapp tries a second provider when the first one fails or returns errors.

3. For production dapps with predictable traffic, get a dedicated private endpoint from a provider. The cost is $50-500/month depending on request volume and whether you need archive data.

4. If you need archive-level historical queries or are exceeding 5-10 million requests per month, consider running your own node. Start with Geth on a cloud VM with snap sync. Upgrade to Erigon if you need archive node performance.

5. For real-time applications (DEX aggregators, liquidations, monitoring), use WebSocket subscriptions from your provider or node. For everything else, stick with HTTP.

6. Always test your RPC setup under load before launch. Use Foundry's cast rpc commands, curl, or Postman to verify each method your dapp uses works with your chosen endpoint - including eth_getLogs with wide block ranges, eth_call simulations, and transaction submission.

The spoke pages under this pillar go deep into every error, comparison, and decision listed here. You do not need to learn all of this at once. Start with the error that is blocking you, or the decision you are currently facing. The rest will make sense as you need it.