RPC Endpoint

What Is an RPC Endpoint?

An RPC endpoint is a network address (typically a URL) that exposes a blockchain node's functionality to external applications. RPC stands for Remote Procedure Call, a concept dating back to the 1980s that allows a program to execute a function on a remote system as if it were a local call. In blockchain, this means wallets, block explorers, trading bots, and decentralized applications can query chain data and submit transactions by sending structured requests to a node's RPC endpoint.

Rather than running a full node yourself, you can point your application at a hosted RPC endpoint and interact with the blockchain through a simple HTTP or WebSocket connection. This is how most applications interact with blockchains today: they send a JSON-formatted request to the endpoint, the node processes it, and the endpoint returns a JSON-formatted response.

How It Works

Blockchain RPC endpoints use the JSON-RPC 2.0 protocol, a stateless and transport-agnostic standard for remote procedure calls. A client sends a JSON object containing the method to call and any parameters, and the server returns a JSON object with either the result or an error.

JSON-RPC Request and Response

Every JSON-RPC 2.0 request contains four fields:

• jsonrpc: the protocol version, always "2.0"
• method: the name of the function to call (e.g., getblockcount or eth_blockNumber)
• params: an array or object of arguments for the method
• id: a unique identifier that matches the response to its request

The server responds with a JSON object containing either a result field on success or an error field on failure. The two are mutually exclusive: a valid response never contains both. Standard error codes include -32601 for method not found, -32602 for invalid parameters, and -32700 for malformed JSON.

// Request: query the latest block number
{
  "jsonrpc": "2.0",
  "method": "eth_blockNumber",
  "params": [],
  "id": 1
}

// Response
{
  "jsonrpc": "2.0",
  "result": "0x134a7b2",
  "id": 1
}

Bitcoin RPC

Bitcoin Core exposes its RPC interface on port 8332 for mainnet (18332 for testnet, 18443 for regtest). Authentication is handled through a cookie file or static credentials configured in bitcoin.conf. Bitcoin RPC supports both JSON-RPC 1.1 and 2.0, defaulting to 1.1 unless the request explicitly includes "jsonrpc": "2.0".

Common Bitcoin RPC methods include:

• getblockchaininfo: returns the current chain height, difficulty, and verification progress
• getblock: retrieves block data by hash, with configurable verbosity levels
• sendrawtransaction: broadcasts a signed transaction to the mempool
• estimatesmartfee: estimates the fee rate needed for confirmation within a target number of blocks
• listunspent: returns available UTXOs in the node's wallet

# Query blockchain info via curl
curl --user myuser:mypassword \
  --data-binary '{"jsonrpc":"1.0","id":"req","method":"getblockchaininfo","params":[]}' \
  -H 'content-type: text/plain;' \
  http://127.0.0.1:8332/

Ethereum RPC

Ethereum nodes expose JSON-RPC 2.0 on port 8545 by default. Unlike Bitcoin, Ethereum encodes all quantities as hexadecimal strings with a 0x prefix, and method names use a namespaced camelCase convention (e.g., eth_getBalance, net_version).

Key Ethereum RPC methods include:

• eth_getBalance: returns an address's balance in wei
• eth_sendRawTransaction: broadcasts a signed transaction
• eth_call: executes a read-only smart contract call without creating an on-chain transaction
• eth_estimateGas: estimates the gas required for a transaction
• eth_getLogs: retrieves event logs matching a filter (address, topics, block range)

HTTP vs WebSocket Connections

RPC endpoints support two transport protocols. HTTP follows a request-response pattern: the client sends a request and waits for a single response. This works well for discrete queries like checking a balance or fetching a block.

WebSocket connections are persistent and bidirectional, allowing the node to push data to the client in real time. Ethereum nodes support subscriptions over WebSocket via the eth_subscribe method, enabling applications to receive notifications for new blocks, pending transactions, and contract events as they happen. WebSocket connections are roughly 10-15% faster than HTTP for the same requests due to eliminating connection overhead.

// Subscribe to new block headers via WebSocket
{
  "jsonrpc": "2.0",
  "method": "eth_subscribe",
  "params": ["newHeads"],
  "id": 1
}

// The node pushes each new block header automatically
{
  "jsonrpc": "2.0",
  "method": "eth_subscription",
  "params": {
    "subscription": "0x9cef478923ff08bf67fde6c64013158d",
    "result": { "number": "0x134a7b3", "hash": "0xabc...", ... }
  }
}

Public vs Private Endpoints

The choice between public and private RPC endpoints involves tradeoffs across cost, performance, privacy, and reliability.

Public Endpoints

Public RPC endpoints are free and require no authentication. Anyone can send requests without creating an account or obtaining an API key. This makes them useful for getting started quickly, running local development environments, or building tools that need basic chain access.

The tradeoffs are significant. Rate limits are shared across all users and enforced per-IP, meaning your application competes with every other anonymous caller. During high-traffic events (NFT mints, market volatility), public endpoints degrade first. There are no uptime guarantees, and nodes may lag behind the chain tip, returning stale data.

Privacy is the most underestimated concern: every request you send reveals your IP address, the addresses you query, and the transactions you broadcast to the endpoint operator. A provider can correlate wallet addresses, build activity profiles, and observe transactions before they reach the broader peer-to-peer network.

Private Endpoints

Private endpoints require an API key and provide dedicated capacity for your application. Rate limits are per-key rather than per-IP, scaling with your subscription tier. Providers like Alchemy, QuickNode, and Infura offer dashboards with request analytics, error tracking, and alerting.

Major providers in 2026 include:

The privacy tradeoff does not disappear with a private endpoint: your provider can still observe every request you make. The difference is that a private provider has a business relationship with you and is less likely to share data indiscriminately. For maximum privacy, running your own node remains the gold standard.

Use Cases

Wallet Applications

Every cryptocurrency wallet relies on RPC endpoints to function. When you check your balance, the wallet sends a request to a node's RPC endpoint. When you send a transaction, the wallet constructs and signs it locally, then broadcasts it through the endpoint. Lightweight wallets that don't run their own node (the vast majority of mobile and web wallets) depend entirely on RPC infrastructure.

Block Explorers and Indexers

Block explorers and blockchain indexers use RPC endpoints to ingest every block and transaction on a chain. They call methods like getblock and getrawtransaction continuously to build searchable databases of on-chain activity. The volume of these requests is why most explorers run their own nodes rather than relying on third-party providers.

DeFi and Smart Contract Interaction

DeFi protocols use RPC endpoints to read contract state (eth_call), estimate gas costs, and submit transactions. Frontends for decentralized exchanges, lending protocols, and yield aggregators typically connect to an RPC provider like Alchemy or Infura. The reliability of this connection directly affects user experience: a slow or unavailable endpoint means failed trades and stale price data.

Infrastructure and Monitoring

Node operators, mining pools, and network monitoring services use RPC endpoints to track network health. Methods like getnetworkinfo, getmempoolinfo, and getpeerinfo provide real-time visibility into node status, mempool conditions, and peer connectivity. Services like Electrum servers sit between full nodes and lightweight clients, querying the node via RPC and serving results through a client-optimized protocol.

Risks and Considerations

Centralization Risk

A large percentage of blockchain transactions route through a small number of RPC providers. If a major provider like Alchemy or Infura experiences an outage, thousands of applications lose access to the blockchain simultaneously. This creates a single point of failure that undermines the decentralization that blockchains are designed to provide. Decentralized RPC networks like Ankr and dRPC attempt to address this by routing requests across distributed node operators, though they currently trail managed providers in tooling and reliability.

Privacy Exposure

Every RPC request reveals information to the endpoint operator: which addresses you query, which transactions you broadcast, your IP address, and request timing patterns. A provider can link wallet addresses to IP addresses, build user activity profiles, and observe transactions before they propagate to the wider network. For Bitcoin users, this undermines the privacy benefits of techniques like CoinJoin if the mixed transaction is broadcast through a third-party endpoint that already knows the sender's identity.

Rate Limiting and Throttling

Public endpoints enforce strict rate limits, typically throttling per-IP address. Even private endpoints have capacity limits tied to your plan tier. Applications that make bursty requests (scanning large address ranges, syncing historical data, or running trading bots) can quickly exhaust their allocation. Different methods also have different costs: tracing and debug methods are often charged at 20-40x the rate of simple read calls.

Stale Data and Reliability

Not all RPC endpoints return the same data at the same time. A node may lag behind the chain tip by one or more blocks, returning outdated balances or missing recent transactions. For time-sensitive operations like fee estimation or MEV protection, even a one-block delay can have financial consequences. Applications should implement fallback endpoints and health checks to detect and route around degraded nodes.

Security Best Practices

Exposing an RPC endpoint to the public internet without proper safeguards is a common source of fund loss. Bitcoin Core's RPC interface includes wallet methods that can send funds, and an unsecured endpoint gives anyone access to those methods. Best practices include:

• Never expose RPC ports directly; use a reverse proxy with TLS termination
• Restrict access by IP using firewall rules or the node's built-in allowlist
• Use method-level authorization to disable wallet and administrative methods on public-facing endpoints
• Rotate API keys regularly and monitor for unauthorized usage patterns

For a deeper look at how different node implementations handle RPC, see the research article on Electrum server architecture and the comparison of Bitcoin node implementations.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.