What is an Ethereum RPC?

In Q1 2026, the Ethereum network processed 200.4 million transactions — a 43% increase from the previous quarter. Every balance query, every smart contract call, every transaction submitted by every wallet and DeFi protocol ran through an RPC endpoint. That's what Ethereum RPC actually is at scale: the interface between applications and the chain.

RPC stands for Remote Procedure Call. In Ethereum's context, it's the mechanism that lets an application — a wallet, an exchange, a DeFi protocol — communicate with an Ethereum node and get back results, without the application needing to run its own node. The protocol that structures this communication is JSON-RPC, a lightweight standard that formats requests and responses as JSON objects sent over HTTP or WebSocket.

For developers building on Ethereum, RPC isn't a detail you can skip. It's the lowest level at which your application touches the blockchain — every library, every framework, every tool you use to interact with Ethereum is making JSON-RPC calls under the hood.

How Ethereum RPC Works

Ethereum RPC runs on the JSON-RPC 2.0 specification — a stateless, transport-agnostic protocol maintained and documented at ethereum.org. Your application sends a JSON object describing what it wants to do. The node processes it and sends back a JSON response.

Every request follows the same structure: a method name (the operation you're calling), params (the inputs), a jsonrpc version field, and an id you assign so you can match responses to requests.

Here's a minimal example — querying the latest block number:

{
"jsonrpc": "2.0",
"method": "eth_blockNumber",
"params": [],
"id": 1
}

The node returns:

{
"jsonrpc": "2.0",
"id": 1,
"result": "0x13f8a4c"
}

Results are hex-encoded. 0x13f8a4c is block 20,939,852 in decimal. The pattern is consistent across every method: you describe the call, the node executes it against current blockchain state, and you get a result back.

What makes JSON-RPC well-suited to Ethereum is its simplicity. The protocol is stateless — no persistent session, no ongoing negotiation between client and server. Each request is self-contained. This makes it easy to implement, easy to cache, and straightforward to debug. A developer can reproduce any RPC call with nothing more than curl.

The Ethereum Execution API specification defines the full set of standardised methods across all compliant execution clients. The methods are the same whether you're connected to a node running Geth, Nethermind, Besu, or Erigon — and the same regardless of which RPC provider you use.

Common Ethereum RPC Methods

These are the methods you'll reach for most often. They cover the core operations any Ethereum application needs: reading state, submitting transactions, querying events, and inspecting blocks.

• eth_blockNumber — Returns the most recent block number. Use for chain sync status and block polling.
• eth_getBalance — Returns the ETH balance of an address at a given block. Use for wallet balance display.
• eth_call — Executes a read-only contract call without creating a transaction. Use for reading contract state — no gas cost.
• eth_sendRawTransaction — Broadcasts a signed, serialised transaction. Use for sending ETH, ERC-20 transfers, and contract writes.
• eth_getTransactionByHash — Returns transaction details by hash. Use for tracking submitted transactions.
• eth_getTransactionReceipt — Returns the receipt for a confirmed transaction. Use for confirming success and reading emitted logs.
• eth_getLogs — Returns logs matching a filter by address, topic, and block range. Use for listening to contract events.
• eth_getBlockByNumber — Returns block details by block number or tag. Use for indexing and chain analytics.
• eth_estimateGas — Estimates the gas a transaction will require. Use for pre-flight checks before submission.
• net_version — Returns the current network ID. Use for distinguishing mainnet from testnets.

eth_call is how you read contract data. It simulates the call against the node's current state and returns the result without broadcasting anything to the network. No signature required, no gas consumed. Whenever you're querying a view function — token balances, pool reserves, price data — eth_call is what's happening.

eth_sendRawTransaction is for writes. You construct and sign the transaction client-side, serialise it, and submit the signed bytes. The node validates the signature and broadcasts the transaction to the mempool. The split between client-side signing and broadcast is intentional: your private key never leaves your application.

eth_getLogs is powerful but requires some discipline. Wide block range queries against a busy contract can be expensive on public endpoints and may hit rate limits. Filter by contract address and specific event topics, and query in bounded ranges.

How to Connect to an Ethereum RPC Endpoint

Connecting to Ethereum RPC comes down to a URL. Every provider gives you one when you register:

https://rpc.yourprovider.com/YOUR_API_KEY

You can send raw HTTP POST requests directly to that URL, or pass it into a library. Here's the straightforward version using ethers.js:

const { ethers } = require("ethers");

const provider = new ethers.JsonRpcProvider("https://rpc.yourprovider.com/YOUR_API_KEY");

async function getBalance(address) {
const balance = await provider.getBalance(address);
console.log(ethers.formatEther(balance), "ETH");
}

getBalance("0xYourAddressHere");

If you want minimal dependencies and maximum transparency, a raw fetch works just as well:

const response = await fetch("https://rpc.yourprovider.com/YOUR_API_KEY", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
jsonrpc: "2.0",
method: "eth_blockNumber",
params: [],
id: 1
})
});

const data = await response.json();
console.log(parseInt(data.result, 16)); // current block number as decimal

No node to install, no sync to wait for. Point your application at the endpoint URL and you have full access to Ethereum mainnet — or any testnet the provider supports.

Public vs. Private Ethereum RPC Endpoints

There are two ways to get an Ethereum RPC endpoint: use one provided by a third-party service, or operate your own.

Public endpoints are hosted by providers who run and maintain the node infrastructure on your behalf. You register, receive an API key, and connect. The operational burden stays with the provider. For most development work and a wide range of production deployments, this is the practical option: you're live in minutes, you don't need to manage a local node, and the provider handles upgrades as the Ethereum client software evolves.

The trade-off is rate limits. Public endpoints are shared infrastructure, so high-volume queries — wide eth_getLogs calls, burst traffic from a popular application — can get throttled. Most providers offer tiered plans with higher rate limits as you scale.

Private endpoints mean running your own Ethereum node. The payoff is complete control: no rate limits, no dependency on a third party's uptime, full access to archive data, and the ability to configure the node precisely for your requirements. The cost is operational. A full Ethereum node requires significant storage (multiple terabytes for an archive node, which retains all historical state), consistent memory and compute, and ongoing maintenance as the client software evolves.

The architecture choice isn't permanent. Many teams start with a public endpoint, validate their product, and move to private infrastructure once the scale and specific requirements justify it.

Ethereum RPC vs. WebSocket: Which Should You Use?

HTTP and WebSocket are both transport options for JSON-RPC. They're suited to different use cases, and it's worth understanding the distinction before you commit to one.

HTTP RPC is request-response. Your application sends a request, receives the result, and the connection closes. Stateless by design. It works well for the majority of Ethereum interactions: balance lookups, transaction submissions, contract reads, block queries. If your application initiates calls and processes responses, HTTP is the right default — it's simpler to work with and easier to cache and debug.

WebSocket keeps a persistent, bidirectional connection open between your application and the node. This enables subscriptions: your application can tell the node "notify me when a new block arrives" or "notify me when this contract emits this event," and the node pushes updates as they happen without your application needing to poll. The relevant method is eth_subscribe, which is only available over WebSocket. [VERIFY: confirm eth_subscribe availability on CoinsDo WebSocket endpoints]

The practical guidance: start with HTTP. If you find yourself polling eth_blockNumber repeatedly to detect new blocks, or polling for transaction receipts in a loop, that's the signal to move that interaction to a WebSocket subscription. You can run both in parallel — HTTP for on-demand queries, WebSocket for event listening.

Free Ethereum RPC Endpoints — What to Look For

Most production-grade providers offer a free tier. Here's where they sit:

• Infura — backed by ConsenSys, direct MetaMask integration, free tier available, 400,000+ registered developers.
• Alchemy — generous free tier (approximately 30 million compute units per month), enhanced developer APIs including transaction simulation.
• QuickNode — lowest publicly-benchmarked latency among major providers (~86ms global average), strong compliance posture.
• CoinsDo — free Ethereum RPC endpoints with no upfront cost, no credit card to start. Built for developers who want to test and iterate without worrying about billing before the product is proven.

Free tiers are real and usable. What varies is where the ceiling is: requests per second, daily request limits, whether archive data is included, and what WebSocket support looks like.

Before choosing a provider for production, check three things: rate limits relative to your expected request volume, archive data availability if your application needs historical queries, and SLA terms for uptime guarantees. Latency matters too if your application is latency-sensitive — benchmarks vary between providers, and geography affects results.

For early-stage development, CoinsDo's free RPC endpoint is a clean option: no friction to get started, and no pressure to commit to a paid tier while you're still figuring out what your production architecture looks like.

Frequently Asked Questions

What is the difference between an Ethereum RPC node and an RPC endpoint?

A node is the Ethereum client software — Geth, Nethermind, Besu, or Erigon — running the blockchain: syncing blocks, validating transactions, maintaining state. An RPC endpoint is the network address you use to communicate with that node. When you use a public provider like CoinsDo, Infura, or Alchemy, they operate the nodes. You get the endpoint URL.

Is Ethereum RPC free?

Through public providers, yes. Most major providers offer free tiers with enough throughput for development and moderate production use. CoinsDo offers free endpoints with no credit card required. Paid plans add higher rate limits and additional features as your application scales.

What is the default Ethereum mainnet RPC URL?

There isn't a universal default. Ethereum doesn't ship with a built-in public endpoint. You connect to an endpoint operated by a provider (Infura, Alchemy, QuickNode, CoinsDo) or to a node you run yourself. The URL format is provider-specific and includes your API key.

What is the difference between Ethereum RPC and WebSocket?

HTTP RPC is stateless request-response: your application sends a request and receives a result. WebSocket keeps a persistent connection open and supports subscriptions via eth_subscribe, so the node can push real-time updates to your application — new blocks, contract events — without polling. Use HTTP for on-demand queries; use WebSocket when you need real-time event notifications.

Can I use Ethereum RPC without running a node?

Yes. That's the core function of public RPC endpoints. Providers run the node infrastructure; your application connects to their endpoint URL. You get full access to Ethereum mainnet without installing a client, waiting for chain sync, or managing local storage.

What does eth_call do?

eth_call executes a read-only call against a smart contract. It runs the contract code against the node's current state and returns the result without creating a transaction or broadcasting anything to the network. No gas cost, no on-chain state change. Use it whenever you need to read data from a contract — token balances, pool prices, governance state, anything exposed through a view or pure function.