What an RPC node does
RPC stands for Remote Procedure Call: a program asks another machine to run a function and return the result. On Ethereum, every client implements a JSON-RPC specification, a stateless and lightweight protocol that uses JSON as its data format.[1]
In practice that means your wallet sends a small text message such as {"method":"eth_getBalance"} to a server, and the server replies with the answer from its copy of the chain. The same interface accepts signed transactions and passes them to the peer-to-peer network. The standard method list, including eth_blockNumber, eth_call and eth_sendRawTransaction, is documented by ethereum.org and formalized in EIP-1474.[2]
The node behind the endpoint is ordinary client software. Ethereum.org describes three node types, light, full and archive, and several sync strategies. An RPC node is usually a full node, or an archive node when apps need historical state at any past block.[3]
See also: Ethereum RPC endpoints · All RPC endpoints by chain
RPC node vs validator
A validator proposes and attests to blocks. An RPC node answers questions. Anza's Agave documentation for Solana states this directly: an RPC node runs the same software as a validator but does not participate in the consensus process, and instead serves requests from users and applications.[4]
The split matters because the workloads differ. A validator needs predictable timing to avoid missed votes. An RPC node gets bursts of reads from wallets, explorers and trading bots, so operators tune it for request throughput and extra indexes rather than for voting.
On Ethereum the separation is similar: an execution client such as Geth or Nethermind serves JSON-RPC, while staking duties run in a separate consensus client and validator client. Ethereum.org's nodes and clients page describes this execution and consensus split.[3]
A worked example: two real JSON-RPC calls
Ethereum.org shows the canonical request format with curl. You POST a JSON body to the node, for example {"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}, to a local client listening on 127.0.0.1:8545.[1]
The reply is a hex string. In the documentation's example the result is "0x4b7", which is 1,207 in decimal: the number of the latest block the node knows about. Quantities in Ethereum JSON-RPC are hex encoded, which is why raw responses look unfamiliar the first time.[1]
Now a write path. A wallet builds a plain ETH transfer, asks the node for fee data, signs locally, and submits it with eth_sendRawTransaction. Ethereum.org's gas page gives the numbers: a simple ETH transfer uses 21,000 gas; with a 10 gwei base fee and a 2 gwei tip the fee is 21,000 x 12 = 252,000 gwei, or 0.000252 ETH.[5]
Notice what the RPC node never sees: your private key. Signing happens in the wallet. The node receives an already signed transaction, checks it is valid, and gossips it to peers. That is why a hostile RPC provider can censor or delay your transaction, or lie about balances, but cannot spend your funds.
| Method | Read or write | Typical wallet use |
|---|---|---|
| eth_blockNumber | Read | Check the node is synced |
| eth_getBalance | Read | Show your ETH balance |
| eth_call | Read | Read a token balance from a contract |
| eth_estimateGas | Read | Estimate the gas a transaction needs |
| eth_sendRawTransaction | Write | Broadcast a signed transaction |
Endpoints, ports and chain IDs
An rpc endpoint is simply the URL of an RPC node. Locally that is often http://127.0.0.1:8545 for Ethereum clients. For Solana, the documentation lists http://localhost:8899 for HTTP and ws://localhost:8900 for WebSocket subscriptions on a local test validator.[6]
Solana's API also uses JSON-RPC, but the method names differ: getBalance, getAccountInfo and sendTransaction instead of the eth_ prefix. A wallet that supports both chains keeps two separate RPC configurations.[6]
When you add a network to an EVM wallet you enter three things: the RPC URL, the chain id, and a currency symbol. The chain ID stops a transaction signed for one network from being replayed on another; the URL decides who answers your requests.
See also: Base RPC endpoints · Arbitrum RPC endpoints · Sepolia testnet RPC
Public, hosted or self-run, and what each sees
Hosted providers, several of which are listed below, run nodes for you so you do not have to. Ethereum.org's run-a-node page names the trade-off: when you send transactions through third-party nodes, personal information can leak to them, and a third-party node could refuse to relay your transactions.[7]
Public endpoints can cap how many requests you send. EIP-1474 reserves error code -32005, "Limit exceeded", for requests over a defined limit. An app that configures a second endpoint can fail over when the first one is limited or down.[2]
Running your own full node removes the middleman. Ethereum.org's run-a-node page lists privacy, security, censorship resistance and reduced reliance on third-party servers as benefits, summed up as: you do not need to trust a third party about the state of the network.[7]
Every request to a hosted node carries your IP address and the addresses you ask about. Put together, that can link a wallet to a person. Ethereum.org names privacy as one of the benefits of running your own node instead of relying on a provider.[7]
An RPC node is also a trust point for reads. A light wallet generally believes whatever balance the node returns. A dishonest or buggy node can show a fake incoming payment that never lands on chain. For large amounts, confirm through a second endpoint or an independent block explorer before you treat a payment as received.
See also: Alchemy · Infura · QuickNode · Chainstack · Helius (Solana)
Full node or archive node: which calls need which
Most wallet traffic only needs recent state, which any full node can answer. Ethereum.org explains that a full node caches only the past few states, for example the state of the last 128 blocks, so it can handle reorgs and serve recent data quickly. Older states are pruned.[8]
That limit shows up in real requests. Ask a full node for the balance of an address at a block from two years ago with eth_getBalance and a block number parameter, and it will typically return an error because it no longer holds that state. An archive node is configured to keep all historical states, so it can answer the same question.[8]
Analytics dashboards, tax tools and block explorers depend on archive data. A simple wallet does not. Ethereum.org notes that archive data runs to terabytes, so a self-hosted full node may not replace a provider for every workload.[3]
The block parameter itself has named options. Besides a hex block number, the ethereum.org specification accepts "earliest" for the genesis block, "latest", "safe" for the latest safe head, "finalized" for the latest finalized block, and "pending". A payment processor that must not act on a reorged block should read at "finalized", not "latest".[1]
Errors you will actually see
EIP-1474 defines standard JSON-RPC error codes for Ethereum. Code -32700 means the node could not parse the request body, usually malformed JSON from a script. Code -32005 means "Limit exceeded": the request exceeded a defined limit, which is what many public endpoints return when you send too many calls.[2]
A rate-limit error is not a chain problem. The same call succeeds against another endpoint a second later. Wallets and bots that handle -32005 with a short backoff and a fallback URL stay usable during traffic spikes such as token launches and airdrop claims.
Stale data is quieter than an error. If eth_blockNumber on your endpoint returns a number far behind a block explorer, the node is out of sync and every balance it reports is old. Checking that one call before trusting a response is the cheapest health check available.[1]
The bottom line
If you only use a wallet, the default RPC endpoint is fine, but you should know how to swap it: that single setting fixes most stuck balances and failed broadcasts. If you build an app, budget for at least two providers from day one and treat RPC as infrastructure, not a free utility. If you care about privacy or verify large payments, run your own execution client and point your wallet at 127.0.0.1:8545.
Educational content, not financial advice. Crypto assets are volatile; do your own research.