Summary
An Ethereum RPC node is a server running Ethereum execution and consensus clients that exposes the JSON-RPC API. Applications use it to query live and historical data—blocks, balances, transaction receipts, logs, and contract state—and to broadcast signed transactions. The choice between full, archive, managed, and dedicated nodes depends on data depth, consistency, and operational capacity. Full nodes serve current chain state and recent history; archive nodes preserve historical state for queries at past blocks and advanced Trace/Debug methods. Managed RPC infrastructure removes sync, storage, client updates, and high-availability engineering. Dedicated nodes add isolated capacity and predictable performance for high-throughput or latency-sensitive workloads but require planning, monitoring, and failover. OnFinality provides Ethereum mainnet and Sepolia RPC access through HTTPS and WebSocket, with plan-dependent rate limits, archive/Trace/Debug availability, and regional endpoints documented on the network page. This guide explains node types, hardware and sync requirements, client and monitoring operations, managed versus self-hosted tradeoffs, and when to choose a dedicated Ethereum RPC node. For developers, the key distinction is whether you need recent state only or historical state depth, and whether you can manage infrastructure or prefer a managed service.
Key Takeaways
- An Ethereum RPC node exposes JSON-RPC over HTTPS and WebSocket, enabling reads and transaction submission.
- Full nodes serve recent state; archive nodes retain historical state for deep queries and Trace/Debug methods.
- Running a node requires commitment to storage, sync, client updates, and monitoring; managed RPC reduces operational burden.
- Choose a dedicated node when you need isolated throughput, predictable latency, or heavy data access not suited to shared plans.
What an Ethereum RPC Node Does for Applications
An Ethereum RPC node is a server running Ethereum execution-layer client software that exposes the JSON-RPC API over HTTPS and WebSocket. Applications use this API to read current and historical blockchain data, such as account balances, block headers, transaction receipts, logs, and contract state. Wallets, dApps, indexers, and analysis tools all depend on RPC nodes to interact with Ethereum without running a node themselves.
Common JSON-RPC methods include eth_blockNumber, eth_getBalance, eth_call, eth_sendRawTransaction, eth_getLogs, and eth_subscribe (WebSocket only). Execution-layer RPC is distinct from the Beacon/consensus API used for validator duties and chain finality. For a broader view of Ethereum API patterns, see /rpc-assistant/ethereum-blockchain-api-2.
- Read methods: balances, blocks, receipts, logs, contract state
- Write path: broadcast signed transactions via
eth_sendRawTransaction - Real-time: WebSocket subscriptions for new heads and logs
- Testnet: Sepolia supports the same JSON-RPC pattern for development
Full vs Archive Nodes and Historical State Requirements
An Ethereum full node stores the current state and recent blocks, pruning older state data that is no longer needed for block validation. It can answer queries about the latest block, recent transactions, and current account balances. An archive node retains every historical state and transaction index, allowing queries at any past block height and enabling Trace and Debug methods that depend on historical state.
Archive nodes require significantly more storage and operational cost. They are typically used by block explorers, analytics platforms, auditing tools, and applications that need to reconstruct historical balances or call contracts at a specific old block. If your workload only needs recent data, a full node is often sufficient. For method-level API coverage, see /rpc-assistant/best-ethereum-rpc-api.
| Criterion | What to check | Why it matters |
|---|---|---|
| Data retention | Full Node: Recent state; prunes old state | Archive Node: All state since genesis |
| Storage | Lower; typically fits on a single NVMe drive | Much higher; requires large NVMe arrays and growth planning |
| Historical state queries | Limited to recent blocks unless the node retains them | Available for any historical block |
| Trace/Debug methods | May not be available; verify with provider | Usually required for historical Trace/Debug |
| Typical workloads | Live balances, transaction monitoring, dApp reads | Block explorers, analytics, auditing, contract debugging |
Mainnet and Sepolia RPC Endpoints and Chain Settings
When configuring a wallet or SDK, use the correct chain ID and endpoint. Ethereum Mainnet uses chain ID 1 and Sepolia uses chain ID 11155111. Sepolia is a testnet for development and staging, not for production traffic. The OnFinality network page for Ethereum (/networks/eth) documents the current HTTPS and WebSocket endpoints, supported methods, rate limits by plan, and regional access. OnFinality also provides a Sepolia network page with similar details.
Execution-layer RPC endpoints are separate from Beacon/consensus API endpoints; verify which one your workload needs. Never mix execution RPC with consensus endpoints in client configuration.
| Criterion | What to check | Why it matters |
|---|---|---|
| Network | Ethereum Mainnet | Chain ID: 1 | Purpose: Production network | Endpoint: Obtain HTTPS/WebSocket URL from /networks/eth |
| Network | Sepolia | Chain ID: 11155111 | Purpose: Testnet for development | Endpoint: Obtain testnet endpoint from OnFinality Sepolia page |
Hardware, Storage, Sync, Client, Monitoring, and Upgrade Considerations
Running your own Ethereum RPC node means operating both an execution client and a consensus client. Execution clients such as Geth, Nethermind, Besu, Erigon, or Reth expose the JSON-RPC API; consensus clients such as Lighthouse, Prysm, Teku, Nimbus, or Lodestar handle proof-of-stake finality. The two clients must be run together and kept in sync with the network.
- Hardware: Use a fast multi-core CPU, at least 16–32 GB RAM, and NVMe SSD storage. Archive nodes need much larger disk capacity; plan for growth.
- Sync: Choose snap or checkpoint sync for faster initial sync. Full sync is slower but verifies all history.
- Storage: Monitor disk usage closely; pruning can reclaim space but reduces historical state availability.
- Client diversity: Use current stable releases; subscribe to client security advisories.
- Monitoring: Track sync status, peer count, block height lag, disk I/O, memory, and RPC error rates.
- Upgrades: Schedule client updates during maintenance windows; test on Sepolia first.
- Security: Restrict RPC access with firewall rules, TLS, and authentication if exposed publicly; never expose private keys.
Running a Node vs Managed RPC Infrastructure
Self-hosting gives you full control, privacy, and no third-party rate limits, but it requires significant ongoing engineering: initial sync, storage, bandwidth, patching, monitoring, failover, and client diversity. Managed RPC infrastructure removes most of that burden and provides endpoints that are already maintained, monitored, and load-balanced. The tradeoff is that you rely on the provider's availability, data retention policies, and rate limits.
OnFinality offers shared and dedicated Ethereum RPC options; current plan features, rate limits, archive/Trace/Debug availability, and regional access are documented on the /networks/eth page. For a broader comparison of managed provider categories, see /rpc-assistant/leading-ethereum-rpc-solutions-guide.
- Self-hosted best for: teams with security or compliance constraints, custom client configurations, or the ability to manage infrastructure.
- Managed RPC best for: teams that want faster time-to-production, predictable endpoints, and less operational overhead.
When a Dedicated Ethereum RPC Node Is Justified
Shared RPC plans are suitable for development, low-traffic applications, and intermittent workloads. A dedicated node becomes justified when you have sustained or bursty request volume, strict latency targets, or need guaranteed isolation from other tenants. Dedicated nodes also give you control over client configuration, geographic placement, and resource allocation. OnFinality's dedicated node offering is described at /dedicated-node; verify current specifications and setup process there.
- Sustained RPC traffic above shared plan limits (check current plan details)
- Latency-sensitive applications such as trading, auctions, or gaming
- Heavy archive/Trace/Debug usage that consumes significant resources
- Privacy or compliance requirements needing isolated infrastructure
- Custom client requirements or long-running indexing jobs
- Contract testing or replay that benefits from a stable, private endpoint
Planning and Operating a Dedicated Node
Before provisioning a dedicated node, estimate worst-case RPC throughput, storage growth, and CPU/memory needs. Define monitoring and alerting for block height, sync lag, peer count, disk usage, and RPC latency. Plan failover to a second node or region if high availability is required. Keep execution and consensus clients updated according to a documented change management process.
- Capacity planning: Benchmark with representative workload; include burst headroom.
- Redundancy: Consider active-passive or active-active across availability zones.
- Backups: Archive nodes may require snapshot strategy; full nodes can often re-sync.
- Security: Use API keys, TLS, and IP allowlists; restrict admin APIs.
- Maintenance: Rolling updates, canary testing on Sepolia, rollback plan.
Example JSON-RPC Calls and Client Configuration
The examples below use a placeholder endpoint. Replace https://your-endpoint.onfinality.io with the endpoint from the OnFinality Ethereum network page. Most production endpoints require an API key or authentication header; check your plan details.
Frequently Asked Questions
What is the difference between an execution client and a consensus client?
Execution clients process transactions, manage state, and expose JSON-RPC; consensus clients handle proof-of-stake, block attestations, and finality. An Ethereum RPC node runs both, but your application communicates with the execution client.
Do I need an archive node for regular transaction data?
No. A full node is sufficient for recent blocks, balances, and transaction receipts. Archive nodes are needed only for historical state queries, old-block eth_call, or historical Trace/Debug methods.
Can I use Sepolia for production?
Sepolia is a testnet with chain ID 11155111 and should only be used for development, staging, and integration testing. Production applications must use Ethereum Mainnet (chain ID 1).
How do I connect to OnFinality Ethereum RPC?
Choose a plan, then retrieve the HTTPS or WebSocket endpoint from the /networks/eth page. Configure your client with the endpoint and any required authentication. Current rate limits and supported methods are plan-dependent.
What hardware do I need to run my own Ethereum RPC node?
At minimum, a fast multi-core CPU, 16–32 GB RAM, and NVMe SSD. Full nodes need about 1 TB or more; archive nodes need substantially more. Specific requirements depend on client and sync mode.
What is the difference between shared and dedicated RPC nodes?
Shared nodes serve multiple customers with rate limits and noisy neighbor risk. Dedicated nodes provide isolated capacity, predictable performance, and control over configuration, but require more operational planning and cost.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
