What Open-Source Servers Are Optimized for Web3 Endpoints?

Short version: If you need high-throughput, low-latency Web3 endpoints you don’t have to buy a black‑box gateway. Today’s best open-source servers—Erigon, Reth, Nethermind, Besu, Geth (EVM); Solana validator with Geyser; Graph Node and Subsquid for GraphQL; Cosmos/CometBFT stacks; Pathfinder/Juno for Starknet; Electrs for Bitcoin—can power production-grade endpoints when deployed with the right architecture, tuning, and safeguards. (docs.erigon.tech)

---

Who this is for

Decision-makers at startups and enterprises evaluating whether to run their own Web3 endpoints (RPC/WS/GraphQL/gRPC) or rely on managed providers.

---

What we mean by “Web3 endpoint”

• Execution endpoints (JSON-RPC over HTTP/WS/IPC) for EVM and other chains. (ethereum.org)
• GraphQL or gRPC data APIs built on top of full nodes or specialized indexers. (besu.hyperledger.org)

---

The short list: open-source servers that actually optimize for Web3 workloads

EVM execution clients (Ethereum and EVM chains)

1. Erigon (Go)
   Why teams choose it

• Separate RPC process (rpcdaemon) that you can scale independently; supports HTTP/WS, GraphQL, and gRPC; batching and read concurrency flags for very high RPS. (github.com)
• Strong disk I/O efficiency via staged sync and MDBX-backed flat state; practical for archive/RPC at lower storage cost. (github.com)
• Clear port model and recommended exposure (P2P public; Engine/DB/RPC private). (docs.erigon.tech)

Operator notes that move the needle

• Run rpcdaemon out-of-process, pin it to local NVMe, and tune:

  --rpc.batch.concurrency

  ,

  --rpc.batch.limit

  ,

  --db.read.concurrency

  ; disable compression when chasing max throughput (

  --http.compression=false

  ,

  --ws.compression=false

  ). (github.com)
• For internal services, use the gRPC KV interface for hot paths (it outperforms JSON-RPC). (docs.erigon.tech)

1. Reth (Rust)
   Why teams choose it

• Modern, modular client with fast RPC stack (jsonrpsee), designed for high-performance RPC, MEV, simulations, and indexing; production-ready as of Reth 1.0. (reth.rs)
• Simple “reth node --http --ws” enablement and granular API control; supports batching and WS subscriptions. (reth.rs)

Operator notes

• Treat it as a performance-first RPC node; keep a conservative rollout plan and blue/green upgrades—alternate clients kept warm—for continuity (a September 2025 bug briefly stalled some mainnet nodes). (cryptotimes.io)

1. Nethermind (C#/.NET)
   Why teams choose it

• Proven on mainnet and major L2s; aggressive I/O and RocksDB tuning; new UI and live pruning features in 1.33.x; detailed performance-tuning docs with tested sync profiles. (github.com)

Operator notes

• For fast sync and stable RPC, combine HeavyWrite DB mode with high outbound peer rate and tuned threads; mind SSD sustained write (not just peak). (docs.nethermind.io)

1. Hyperledger Besu (Java)
   Why teams choose it

• Enterprise-friendly: native JWT/RBAC for RPC, liveness/readiness endpoints, and robust batch request controls; performance work continues in recent 25.x releases. (besu.hyperledger.org)

Operator notes

• Enable only required namespaces; set

  --rpc-http-max-batch-size

  for predictable load; front RPC with TLS termination and JWT auth where appropriate. (besu.hyperledger.org)

1. Geth (Go)
   Why teams choose it

• The most battle-tested EL client with straightforward RPC/WS/IPC plus an EIP‑1767 GraphQL endpoint; frequent performance and API updates. (geth.ethereum.org)

Operator notes

• Recent 1.16.x releases add RPC improvements like

  eth_sendRawTransactionSync

  (useful for L2 workflows) and schedule network forks—plan upgrades accordingly; the

  personal

  RPC namespace was removed in late 2024. (chainrelease.info)

When to mix clients

• For RPC fleets, we recommend at least two different clients behind a health-aware proxy. This cushions client-specific bugs and aligns with Ethereum’s client diversity ethos. (ethereum.org)

---

Solana: validator RPC and the Geyser stack

What “optimized” means on Solana

• The core validator exposes a powerful JSON-RPC, but the Geyser plugin framework is what unlocks real-time, high-volume streaming via gRPC or direct sinks (Kafka/Postgres), enabling purpose-built RPC-like services. (github.com)

Production-grade options

• Validator + Geyser gRPC with tuned hardware (operators publishing reference configs target 24+ cores and 384GB RAM for stress-tested streaming). (slv.dev)
• Purpose-built lite RPCs exist (e.g., open-source “solana-lite-account-manager”) that create minimal RPCs atop Geyser streams. (github.com)

Practical guidance

• Use specialized plugins to offload account/slot/tx streams to Kafka/Postgres; scale consumers horizontally; avoid overusing heavy HTTP calls like getProgramAccounts without filters or pagination. (github.com)
• Some public providers rate-limit heavy Solana queries—engineer for filtering and streaming over polling. (quicknode.com)

---

Query layers that serve your app smarter than raw RPC

1. The Graph’s Graph Node (GraphQL)

• Indexes subgraphs and serves them via GraphQL; supports query-only nodes, Postgres sharding/replicas, and Firehose ingestion; needs archive+trace support on the underlying EVM RPC for certain features. (thegraph.com)

Operator notes

• Run dedicated “query nodes,” isolate from indexing nodes, and add Postgres read replicas to absorb traffic spikes. Use Prometheus metrics on port 8040. (thegraph.com)

1. Subsquid (Squid SDK + Network)

• Open-source ETL+GraphQL stack that reads historical data from a decentralized Archive network, often eliminating the need for an archival RPC; squids commonly index tens of thousands of blocks/sec and expose a GraphQL API backed by Postgres. (docs.devsquid.net)

Operator notes

• Use Squid SDK to batch-ingest logs/receipts/traces, write to Postgres, and deploy an API; for real-time, combine Archive ingestion with live RPC tails. (docs.devsquid.net)

When to add a query layer

• If your product issues many expensive historical queries (getLogs over large ranges, traces, decoded events), a query layer will be faster and cheaper than scaling raw RPC. (thegraph.com)

---

Cosmos (Cosmos SDK + CometBFT): gRPC first, REST via gRPC‑gateway

• Cosmos SDK nodes expose gRPC for state queries and gRPC‑gateway REST; CometBFT provides the P2P consensus and a separate RPC (26657) with pubsub and light-client proofs—do not expose it publicly without controls. (docs.cosmos.network)

Operator notes

• Keep gRPC (9090) behind your API gateway with TLS; only expose CometBFT RPC internally or with strict ACLs; prefer gRPC for performance and typed APIs. (docs.cosmos.network)

---

Starknet: Pathfinder (Rust) and Juno (Go)

• Both are open-source full nodes implementing the Starknet JSON‑RPC spec; as of late 2025, RPC 0.8/0.9/0.10 are current, with deprecation notices for older 0.6/0.7—ensure your node and SDKs match the RPC version you serve. (eqlabs.github.io)

Operator notes

• Align Pathfinder/Juno versions with the target RPC and your app libraries (starknet.js, etc.); avoid mixing unsupported RPC versions across environments. (starknetjs.com)

---

Bitcoin: Electrs for wallet-grade endpoints

• Electrs is an efficient Electrum server in Rust used by explorers (and mempool.space variants) to serve wallet queries fast; recent releases focus on concurrency and SSD-friendly indexing. (github.com)

Operator notes

• It’s optimized for lightweight, high-QPS balance/history queries; combine with your bitcoind and a cache-friendly storage plan.

---

Reference architectures that work in 2025

1. EVM RPC for dapps/wallets (multi-client)

• 2× Erigon (archive) + 1× Reth (full) behind a JSON‑RPC aware proxy with health checks and method-aware routing. Favor Erigon for heavy historical reads; use Reth for low‑latency

  eth_call

  /

  trace_*

  workloads.
• Open-source proxies you can adapt: status‑im/eth‑rpc‑proxy for health/failover; LlamaNodes’ web3‑proxy for caching/load‑balancing and private tx fan‑out. (github.com)

1. Solana real‑time analytics/API

• 1× validator with Geyser Postgres/Kafka plugins + horizontally scaled API consumers that serve narrow HTTP endpoints; reserve vanilla JSON‑RPC only for selective queries; stream everything else via gRPC/consumers. (github.com)

1. GraphQL-first product

• Graph Node or Subsquid in front of one or more EVM nodes; Postgres primary + one or more read replicas dedicated to queries; use Prometheus/Grafana dashboards exposed by nodes. (thegraph.com)

1. Cosmos service

• gRPC for state reads + gRPC‑gateway REST for browser clients; CometBFT RPC locked down internally; prefer light-client proofs where needed. (docs.cosmos.network)

---

Tuning that materially improves Web3 endpoints

EVM nodes

• Erigon: place rpcdaemon on the same host and disk as data; tune batch and read concurrency; disable compression for peak throughput; consider GraphQL for multi-field reads to reduce round trips. (github.com)
• Reth: isolate hot RPC from peer traffic; keep WS subscriptions on dedicated instances; treat upgrades as if you were running a managed fleet—stagger nodes. (reth.rs)
• Nethermind: HeavyWrite DB mode for sync; ensure sustained SSD throughput; adjust max peers and outgoing connect rate; modern RocksDB builds help. (docs.nethermind.io)
• Besu: enable JWT auth; set batch size caps; use readiness/liveness endpoints for autoscaling and rollouts. (besu.hyperledger.org)
• Geth: enable GraphQL (

  --graphql

  ) when it simplifies many small RPC calls; keep RPC namespaces minimal and CORS/vhosts strict. (geth.ethereum.org)

Solana

• Favor Geyser streaming over heavy polling (e.g., getProgramAccounts) and always filter/paginate; reserve JSON‑RPC for specific point reads. (solana.com)

Cosmos

• Prefer gRPC for typed, scalable queries; restrict CometBFT RPC exposure and configure CORS/headers carefully if you must expose it. (docs.cosmos.network)

Starknet

• Standardize on current RPC versions across nodes and SDKs to avoid subtle incompatibilities; follow the deprecation timeline. (community.starknet.io)

---

Security and access control checklists

• Don’t expose execution/consensus Engine APIs publicly (e.g., 8551 on EVM); use private networks for EL<->CL comms and JWT secrets. (docs.erigon.tech)
• Enable authentication where available (Besu JWT/username-password); terminate TLS at your ingress and keep node ports private. (besu.hyperledger.org)
• For CometBFT, the project explicitly warns not to expose the RPC server without protections—enforce ACLs, rate limits, and request size caps. (docs.cometbft.com)
• Use role separation: validators/peers on one tier; RPC and query nodes on another; indexers on a third.

---

Practical examples

1. High‑QPS EVM read API (finalized reads)

• 2× Erigon archive with rpcdaemon:

  • erigon --private.api.addr=127.0.0.1:9090 --http=false

  • rpcdaemon --datadir=/data/erigon --http.api=eth,erigon,debug,trace,web3,net --rpc.batch.concurrency=64 --db.read.concurrency=256 --http.compression=false

• 1× Reth full node for “hot” methods:

  • reth node --http --http.api eth,net,web3,debug,trace

• Proxy routes heavy historical calls to Erigon; “live” calls to Reth; health checks and circuit breakers on both. (docs.erigon.tech)

1. Solana account analytics

• Validator with Geyser Postgres/Kafka plugins (20+ threads, batched writes), then a stateless API that reads from Postgres/Kafka topics; use WS/gRPC streams for live updates; filter on-chain at source when possible. (github.com)

1. Query-first product on EVM

• Graph Node with “query-only” nodes and Postgres read replicas; upstream RPC that supports EIP‑1898 and trace_filter (archive+traces). Add Prometheus/Grafana dashboards for operators. (thegraph.com)

---

Emerging best practices (2025)

• Use GraphQL or gRPC to collapse multiple JSON‑RPC calls into one request where supported (Geth GraphQL; Erigon GraphQL/gRPC). (geth.ethereum.org)
• For Solana, migrate heavy polling patterns (getProgramAccounts over large spaces) to streaming indexers or Geyser consumption. (solana.com)
• On Ethereum, stay current with client releases that affect RPC behavior and new methods (e.g., Geth 1.16.x adds

  eth_sendRawTransactionSync

  ; many clients have updated tracing and blob-related behaviors post‑Cancun). Plan maintenance windows. (chainrelease.info)
• For Starknet, standardize RIP (RPC Interface) versions in CI, and audit node/SDK compatibility whenever upgrading. (docs.starknet.io)

---

Decision guide (quick picks)

• I need the fastest, cheapest EVM archive reads at scale → Erigon rpcdaemon, horizontally scaled, or add a query layer (Graph Node/Subsquid) to offload historical queries. (docs.erigon.tech)
• I need low-latency

  eth_call

  /traces under burst → Add Reth nodes to your pool and steer hot paths to them. (reth.rs)
• I’m an enterprise needing stricter auth/observability → Besu with JWT and health endpoints, fronted by your corporate ingress. (besu.hyperledger.org)
• I’m building Solana real‑time analytics → Validator + Geyser (Kafka/Postgres) and stream-first APIs. (github.com)
• I’m shipping multi-chain analytics with complex historical queries → Subsquid or Graph Node over your node fleet. (docs.devsquid.net)
• I need Starknet RPC today → Pathfinder or Juno aligned to RPC 0.9/0.10; avoid deprecated versions. (docs.starknet.io)

---

Final take

Running your own endpoints is no longer exotic—and it can be a strategic advantage for performance, cost, and data control. Start with the right client for the workload, add a query layer when your product needs it, and treat your endpoint fleet like any mission‑critical API: versioned, observable, and upgrade‑disciplined.

If you want a reference deployment or a tune-up for your existing nodes, 7Block Labs can blueprint, implement, and hand over a hardened, autoscaled stack tailored to your traffic profile.