Skip to content
Financial Context Wiki

RPC node

An RPC node gives wallets and applications a request-and-response interface to blockchain data and transaction broadcast. Learn what changing an endpoint can fix, what it cannot fix, and how to reduce availability, privacy, and security risks.

Updated

For educational purposes only; not investment advice. An incorrect or malicious RPC endpoint can expose activity, return misleading data, or disrupt transaction submission, and digital-asset transactions can cause irreversible loss.

Direct answer

An RPC node is a blockchain node, or a service in front of one or more nodes, that accepts remote procedure call requests from wallets, explorers, and applications. On Ethereum-compatible networks, the common interface is JSON-RPC. It lets software read node data, simulate calls, estimate gas, and submit signed transaction bytes for broadcast without the software maintaining its own node.

The URL configured in a wallet is an RPC endpoint, not the blockchain itself. Switching endpoints can bypass a provider outage, stale node, rate limit, unsupported method, or connection problem. It cannot change contract rules, restore a reverted transaction, reverse a confirmed transfer, or fix a network-wide halt. The new endpoint must serve the intended network and chain ID.

How it works

A client sends a request over a supported transport such as HTTP or WebSocket. A JSON-RPC request names a method, supplies parameters, and includes an identifier that the response repeats. The node executes the method against its local view of the chain and returns either a result or an error. WebSocket connections can also support subscriptions when the client and endpoint expose them.

Read methods have different meanings and data requirements. For example, eth_blockNumber reports the latest block known to that node, while eth_getBalance reads an address balance at a specified block tag or number. Results can differ temporarily between healthy nodes because their heads, pending transaction pools, pruning modes, or supported extensions differ. A hosted provider may also impose authentication, quotas, request-size limits, or method restrictions that are not blockchain consensus rules.

For a typical wallet transaction, the wallet constructs and signs the transaction locally, then sends the signed bytes with eth_sendRawTransaction. The RPC node checks the request and attempts to propagate the transaction to peers. A returned transaction hash means the node accepted the bytes for submission; it does not prove that the transaction will be included, succeed, or become final. Inclusion and status should be checked independently on the correct chain.

An endpoint is therefore a trust and availability dependency. It can observe requested addresses, IP information, timing, and submitted transactions; it can omit or delay data; and it can present a stale or incomplete view. Cryptographic signatures prevent an endpoint from silently changing a properly signed transaction, but they do not make read responses truthful or protect unsigned metadata and privacy.

Example

A wallet can ask an Ethereum execution client for the block number with this request:

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

A valid response may look like this:

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

The hexadecimal result is the latest block number known to that endpoint. If the wallet’s usual provider times out but a second reputable endpoint returns a newer block and the expected chain ID, switching may restore balance queries and transaction submission. If both endpoints show the same reverted transaction receipt, changing RPC does not alter that on-chain outcome.

Risks and controls

  • Wrong network: a copied endpoint may serve a different chain or fork. Verify the chain ID, network name, native asset, and a recent block against an independent source before signing.
  • False or stale reads: a faulty or malicious endpoint can return old balances, omit logs, or misreport simulation results. Compare important reads through another provider or a self-operated node, and pin an explicit block when reproducibility matters.
  • Privacy leakage: address and transaction queries can link wallet activity to network metadata. Avoid sending unnecessary addresses, review provider retention policies, and consider a trusted self-hosted endpoint when the privacy tradeoff justifies the operational cost.
  • Transaction censorship or delay: an endpoint can refuse or delay broadcast. Save the signed transaction hash, check independent explorers or nodes, and use a second reputable broadcast path if the transaction is absent. Do not sign a replacement without checking the nonce and fee implications.
  • Exposed credentials: API keys embedded in public code can be stolen and exhaust quotas. Restrict keys by origin or service where supported, keep privileged credentials off clients, and rotate leaked keys.
  • Dangerous node exposure: publishing an administrative or broadly enabled RPC interface increases attack surface. Bind self-hosted RPC locally by default, expose only required namespaces, add authentication and network controls, and never expose unlocked accounts.
  • Wallet deception: an endpoint URL does not need a seed phrase or private key. Reject any service that asks for either, inspect transaction fields in the wallet, and never rely on an RPC response alone to identify a destination contract.

Common misconceptions

  • “RPC is the blockchain.” It is an interface to a node’s view of the blockchain.
  • “A transaction hash means confirmation.” It normally proves only that an endpoint accepted the signed bytes; execution and finality are separate stages.
  • “Changing RPC changes fees or contract behavior.” It may change fee estimates or access quality, but the transaction and protocol rules determine actual execution.
  • “All endpoints return identical data.” Sync status, pending pools, retained history, client extensions, and provider policies can differ.
  • “HTTPS makes every response trustworthy.” HTTPS protects the connection to the named server; it does not prove that the server’s blockchain data is complete or correct.

Sources

Navigation

Search the wiki...